[Bf-cycles] Volume Rendering for GSoC

Brecht Van Lommel brechtvanlommel at pandora.be
Tue Apr 30 07:13:04 CEST 2013


Hi Rafael,

On Tue, Apr 30, 2013 at 5:03 AM, Rafael Campos <rafaelcdn at gmail.com> wrote:
>> The other part is texturing, which can be developed independently.
>> Basically we need equivalents of the blender internal point density
>> and voxel data textures in cycles. For the point density texture the
>> points come from particle systems or object vertices, and for the
>> voxel data they come either from smoke or some voxel file format.
>>
>
> This is very interesting too - really like the idea. I'm thinking that
> simply coding blender internal counterparts on cycles won't cut it - are we
> looking for improvements, or are there any known problems or limitations
> with the existing code that we would like to address?

I don't have much experience working with these textures, maybe others
have more ideas, but here are some things to consider.

* One is that because cycles is node based, not all features need to
be in a single big node, rather some things like point density
turbulence settings or color source do not need to be built in, they
could be node inputs that you plug other nodes in. Generally just
trying to design a texture node that can be combined well with other
nodes.

* I also remember quite a bit of confusion about the right way to set
up a smoke material and texture in blender internal, to get the smoke
data properly mapped, probably some things could be made more
intuitive for cycles. Not sure if this requires any bigger changes or
if it's easily fixable but worth looking into.

* Another thing that we can improve is that the entire volume data
needs to be in memory, with a library like OpenVDB we might be able to
render massive datasets because it can do disk caching and skip
storage of empty space.

* If we support a library like OpenVDB that does not store empty
space, is there a way we can render that efficiently? Normally a
texture just outputs an interpolated value at a given location, but
can we somehow inform the integrator that it needs to skip a certain
amount of empty space instead of stepping over all voxels?

* Maybe voxel data and point density textures could support motion blur?

Further the Production Volume Rendering book and notes show all kinds
of interesting effects. I didn't have time yet to read it all but
maybe there's things that can be done at render time that wouldn't be
automatically possible with existing nodes, for which a new node or
node option could be added.

>> Field3D, OpenVDB and Partio are all interesting libraries to look into
>> as this would give us some support for more standard file formats than
>> just Blender specific ones. Also interesting would be adding support
>> for smoke to export to such file formats, as we can then add support
>> for rendering such volume data without the entire thing being in
>> memory at once.
>>
>
> This alone is very cool by itself, but a more in-depth survey of the pros
> and cons of supporting each of these might be needed (or not?). I'm just not
> sure how open ended I should leave this, ie, how much of each I should
> evaluate prior to submitting the proposal, or if evaluating each of these
> might be part of the summer activities.

Personally I think OpenVDB support would be most interesting. It's
being adopted by Houdini, Renderman and Arnold. It's better than
Field3D in that it supports also sparse volume data sets instead of
just dense ones, which makes it possible to render massive scene (at
least for CPU rendering). Also seems to have some interesting features
like level sets, filters, transformations, .. though not sure if we
can do anything with those immediately.

Anyway, for such a file format to be useful we'd need to be able to
export Blender smoke data to it, so you'd probably spend time
integrating it into various parts of Blender and wouldn't have much
time left for a point density textures. So some variations could be:

* Integrate OpenVDB with smoke, add new cycles voxel data texture, and
maybe support it in blender internal voxel data texture too.
* Add cycles voxel data texture + point density texture to cycles.
* Add cycles voxel data texture + some extra interesting render time
volume effects.

It all depends on how experienced you are as a developer or what you
think is interesting.

Brecht.


More information about the Bf-cycles mailing list