Dan Wood

I haven't got Houdini access at the moment, so can't check the file right now or tell you specific instructions, but the key thing with VDBs is, they have their own inner and outer sign sense, that may be independent of the mesh you used to generate it.

"Inside" is negative numbers and "Outside" is positive numbers... so to have an enclosed object be a container rather than a collider, you need to flip the signs of the entire volume. Outside needs to be negative and inside positive - ie. just multiply the whole thing by -1.

For anything remotely realistic-space-scale, you'll have to use 64-bit precision position data to avoid precision issues.

You can convert an object's P attribute to 64-bit using the Attribute Cast SOP.

It's possible that won't help with camera-jitter issues though, as I presume Houdini's camera handling is hardwired to 32-bit. Not sure about that.
(And those issues might follow you into rendering, etc... depending on if the renderer supports 64-bit precision or not)

Been getting to grips with OpenCL in Houdini recently, and it's got me wondering - unless you're doing 1000s of iterations on a data set between copy-backs, or some very complex calculations, generally the lion's share of time seems to end up loading data to/from the GPU (even when being careful only to transfer the minimum amount necessary).

So what in a typical modern highish-end-desktop system is the principle bottleneck there? Say, in a dual-channel DDR5 system with a PCIE 5.0 x16 interface to the GPU, would it be the RAM bandwidth or the PCI bus, or some other factor?