Operations using voxelization fail on large (volume) files

[ayamflow]

When generating a voxel, or using the --filter-floaters flag, splat-transform fails during the voxelization step with files covering a large area. You can see below my example scene is parsed as 896m x 427m x 789m requiring 2.42 trillion voxels.

I'm sure I could play with the voxel/floaters settings to not have so many voxels, until it fails again.
My expectation would be that the tool caps to a maximum non-failing number of voxels - or another suggestion ?

Possibly related to #217

dev: splat-transform v2.1.0 (e1c8619)
dev: ▸ [1/2] Input temp.ply
dev:   ▸ Reading
dev:     ▸ decoding [####################] 0.513s
dev:   · 1.92M gaussians · 0 SH bands · 102.5MB
dev:   ▸ Filter floaters
dev:     · scene: 896m x 427m x 789m, grid: 17920 x 8552 x 15780 voxels (2.42T) @ 5cm
dev:     ▸ Voxelizing [####################] 5m52.574s
dev:     ✗ RangeError: Set maximum size exceeded
dev:     at Set.add (<anonymous>)
dev:     at buildBlockLookup (file://<workingDir>/node_modules/.pnpm/@playcanvas+splat-transform@2.1.0_playcanvas@2.18.1/node_modules/@playcanvas/splat-transform/dist/cli.mjs:26990:18)
dev:     at filterFloaters (file://workingDir/node_modules/.pnpm/@playcanvas+splat-transform@2.1.0_playcanvas@2.18.1/node_modules/@playcanvas/splat-transform/dist/cli.mjs:27408:24)
dev:     at async processDataTable (file://workingDir/node_modules/.pnpm/@playcanvas+splat-transform@2.1.0_playcanvas@2.18.1/node_modules/@playcanvas/splat-transform/dist/cli.mjs:29019:26)
dev:     at async main (file://workingDir/node_modules/.pnpm/@playcanvas+splat-transform@2.1.0_playcanvas@2.18.1/node_modules/@playcanvas/splat-transform/dist/cli.mjs:30136:37)
dev:     at async file://workingDir/node_modules/.pnpm/@playcanvas+splat-transform@2.1.0_playcanvas@2.18.1/node_modules/@playcanvas/splat-transform/bin/cli.mjs:5:1
dev:     failed in 6m9.507s
dev:   failed in 6m10.034s
dev: ✗ failed in 6m10.041s  [peak 8.65GB]
dev:
dev:     at genericNodeError (node:internal/errors:983:15)
dev:     at wrappedFn (node:internal/errors:537:14)
dev:     at ChildProcess.exithandler (node:child_process:417:12)
dev:     at ChildProcess.emit (node:events:519:28)
dev:     at maybeClose (node:internal/child_process:1101:16)
dev:     at ChildProcess._handle.onexit (node:internal/child_process:304:5) {
dev:   code: 1,
dev:   killed: false,
dev:   signal: null,
dev:   cmd: 'splat-transform temp.ply --filter-floaters --filter-cluster 1,0.1,0.1 temp_filtered.ply'

[slimbuck]

Hi @ayamflow ,

Yes this is a known issue on my side and I'm really sorry you're encountering it.

Up until now, I haven't wanted to implement hard voxel restrictions before understanding how best to do this. And since different machines have different memory limits, it can be difficult to judge when something might fail or not ahead of time.

I actually plan a deep change to splat-transform which to manage memory much more efficiently. I will also implement some sort of limits so we don't just crash the way you're seeing it.

Till then, can you limit the scene yourself (using --filter-box, say) or increase the voxel size?

Thanks!

[ayamflow]

Got it, thanks for the quick answer!
It's hard for me to use --filter-box as my pipeline runs on user-uploaded files, but for now I'll try to pass a voxel size based on the gsplat file boundingBox

[ayamflow]

Here's what works for me currently:

• parse splats dimensions with splat-transform input -m null + grep to extract the x/y/z (computed from min/max)
• compute a voxel size from these dimensions (something like Math.max(x, y, z) * factor, and an optional clamp to not have a too small/too big voxel size)
• pass the computed voxel size to each function (with --voxel-params ${voxelSize},0.1 or dedicated function params like --filter-floaters ${voxelSize},0.1,0.004)