Page 1 of 1

Feature request - VolumeFog improvements

PostPosted: Wed Mar 30, 2016 7:55 am
by Theodor Groeneboom
-

Re: Feature request - VolumeFog improvements

PostPosted: Thu Mar 31, 2016 12:58 am
by Chad Capeland
You'll need Studio, yada, yada, yada, but I have a plugin that has a volume datatype. So instead of passing images, you pass whole volumes, which makes animated volumes much easier to manage. As for OpenVDB, hope to have reading done eventually. Writing is already implemented as a saver.

Re: Feature request - VolumeFog improvements

PostPosted: Thu Mar 31, 2016 11:09 am
by Theodor Groeneboom
-

Re: Feature request - VolumeFog improvements

PostPosted: Tue Apr 05, 2016 3:42 pm
by Chad Capeland
Theodor Groeneboom wrote:Hows the datatype stored ? I do actually like the idea of storing volumes as images as it lends itself to some fairly interesting 2d manipulation possibilities. I'm already pushing stuff around in houdini and volume vops, but you can achieve some really interesting stuff when its stored as images.

I wouldnt mind testing them if possible, I have a studio lic.


It's stored as an XYZT array of voxels (so no tree, just flat) with a 3D/T DoD/RoI. Tools can convert to images for compatibility with existing Fusion tools, but if the input accepts voxels, then no conversion to image takes place. So for instance if you wanted to apply a BC to it, you could, but you would have to do it over all the empty voxels, and you'd have to multiplex over time. And you'd have to manage potentially huge images which can be problematic. Like if you output XYZ per time sample, you could only handle 1024^3 out to an image before Fusion gets cranky/crashy. But if you used a tool that accepted the voxels, like BilateralFilter or SignedDistance, then you wouldn't have to convert anything and it would be more efficient. And with say, Texture3D, you could create a OpenGL texture from the voxels and raymarch in the OpenGL renderer. This helps a lot for visualizing your data as you use it, especially in space. And with 12GB and now 24GB cards, it's not crazy to do that. Like you can cache a second or three of animated 512^3 data for realtime playback.

Ideally, though, you'd want to have a system where the data isn't passed at all, just the functions, and have a compiler when you actually need to see the state at a point in the flow. Basically the way the Cg shaders work. That way you don't have to push so much data around and cache it. Don't have that, that's just what I would rather have. :)

What's more likely to happen, though, is just switch from voxels to OpenVDB.