Page MenuHome

Cycles Voxel Data Node Mockup
Closed, InvalidPublicDESIGN


Here is a mockup of a Cycles Voxel Data Node

It is very similar to the voxel data texture from BI, in fact behind the drop-down there should hide the same options as in BI. The key difference is that there should be the possibility to offset smoke data just like you would offset image sequences. This would make the option to chose the domain from where the actual data is loaded more useful. For example if you have multiple chimneys in a scene one would need to bake only one simulation. By offsetting the data for each chimney a little each column of smoke would look a little different.

Event Timeline

Gottfried Hofmann (gottfried) raised the priority of this task from to Normal.
Gottfried Hofmann (gottfried) updated the task description. (Show Details)
Gottfried Hofmann (gottfried) edited a custom field.

Note: To be able to chose the interpolation mode is really really important, for example to counter blocky smoke artefacts...

Voxel Data texture was created with BI in mind.
In Blender Internal UI, there are labels to explain pull down lists.
In mock-up, first "smoke" item is refering to file format ( 8 Bit Raw, Blender Voxel, Image Sequence and Smoke) and second "smoke" item is refering to smoke source (smoke, fire, velocity, heat).

In BI texture tab, Voxel Data panel adapts itself to file format.
In Cycles, instead of a node that have a changeable UI, several nodes could be created to correspond to each file format.

A Voxel Data Image Sequence could be avoided. We could use current Image Texture node for same result.
I don't know if someboby is still using Blender Voxel file format.
I think it was used at beginning of smoke development in blender 2.48 and kept for compatibility with old files. Genscher should be able to confirm.

So, in practice, it could correspond to only two new nodes.
A Smoke Texture node which would have same look that this mock-up except file source format pulldown list that would be removed.
And a 8 bit Raw Texture to keep ability to render scientific data from other apps.
(I don't know if it is still use a lot. Maybe, now, it exists other commonly used file formats for Voxel Data exchange.)

What can we do to push this along? 1. How can we demonstrate user utility to devs 2. How big of a problem is this to tackle and is it worth the gained utility to users. 3. Funding

With no personal knowledge of the internal smoke data structure, my instinct says that if Cycles has the machinery to render these textures already, and all we need to do is plug in existing data into the right Blender format, that it should not be too difficult. Perhaps that assessment is inaccurate.

Patrick Moore

Whats the status on this? is this the same thing as point density?

It is not same thing as point density texture.
Point Density texture uses as source : particles or meshes vertices.
Voxel Data texture uses as source : smoke voxels or Image Sequence frames as volume slices.

Kevin Dietrich has done an OpenVDB Volume node that uses smoke voxels in OpenVDB branch.
But it does not solve the lack of node for images of slices.

Brecht Van Lommel (brecht) changed the task status from Unknown Status to Unknown Status.Feb 21 2016, 2:53 PM
Brecht Van Lommel (brecht) claimed this task.

I think overall we want to use a different approach here, based on getting voxel data as attributes in the same way UVs, vertex colors, etc. work. Particularly when Blender gets a native volume object type this will start making even more sense. Treating voxel data as a texture is not the right approach I think.

I could really use an image sequence based voxel data texture in Cycles right now. But in the mean time, if anyone has a workaround that doesn't kill performance, I would love to know about it.

I'm also interested in generating a volume based on an image sequence. It seems that a number of people are interested in this, with several questions over at the blender stackexchange relating to this:

Is there a solution currently?

@Dan Hickstein (danhickstein) Still not, apart from the workarounds proposed in Stackexchange. That said, I wonder if the Everything Nodes project can address this even though it's a Cycles feature.

Okay, thank's for the info @ChameleonScales (Caetano)! That's too bad that it's not a feature yet.

@ChameleonScales (Caetano) is this still pending? Hey @Brecht Van Lommel (brecht) I see this is assigned to you. If you are busy I can try to give it a shot next month but I don't have any experience with blender code base so I'll need some help with this.

@haaput (haaput) no further work that I've heard of, although if you have a particular use case you'd like to solve, I might be of help to find a workaround. Feel free to PM me on (

As I explained earlier in this task, I don't think this is the right approach. It makes optimizations and some features difficult, volumes should be a type of object rather than a shader. I expect a native volume object type will be added in one of the releases after 2.80.

Thanks @ChameleonScales (Caetano). I managed to get it working using blender renderer. So now half of my project is rendered using blender renderer and other half using cycles! Its not ideal, but works for now.

@Brecht Van Lommel (brecht) OK thanks. I guess that is at least a few years.. btw I am still up for working on in May.

I'd also be very interested in direct volume rendering in Blender and would be willing to contribute some work toward it (I've done quite a lot of image processing and sci viz over the years). I'm specifically interested in high-quality renders of large semi-transparent volumes with Cycles.