[Bf-cycles] Volume Rendering for GSoC

[Rafael Campos]

Hi Brecht,

I went ahead and read the VDB paper
here<http://www.museth.org/Ken/Publications_files/Museth-VDB_TOG13.pdf>,
and was rather impressed.

Of all ideas, I'm going with OpenVDB integration, and adding Voxel Data
texture to Cycles.
I feel that leaving Point Density texture out of the proposal is a bit of a
shame since the texturing part of volume rendering will be only partially
satisfied, but I'm all worked up with OpenVDB now, and there is a lot to be
gained in the future by supporting it.



On Tue, Apr 30, 2013 at 2:13 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> 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.
>
>
 True. Since there isn't much time before the submission deadline, I'll
come up with ideas for the design and interaction of these new nodes so we
can discuss, but probably after submitting the proposal. Is creating a page
on the wiki for the proposal a good idea or is it better to wait ?


> * 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.
>
>
Creating the material and then setting up the voxel data texture really
wasn't intuitive when I first tried it - but I'll have to look more into
it. If approachable, I'd like to include such a change in the project.


> * 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.
>
>
>From my understanding, this is one of the major advantages of using OpenVDB
- only the grid topology must be kept in memory at all times.


> * 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?
>
>
There are a few suggestions to optimize the traversal of empty spaces in
the grid - one of them is obtaining the min/max values for the populated
region (a tile) and integrating using the disjoint intervals obtained. I'll
include this survey as part of the project, to come up with a good design
and then implement it - this will probably be the last bit.


> * Maybe voxel data and point density textures could support motion blur?
>
>
I was thinking of trying to add motion blur support to voxel data, but I'm
not sure the time frame will be enough, especially since there will be a
lot of design-discuss-code iterations for most of the tasks, and that can
take time. I might add this as a tentative feature, and if all goes well,
then great.


> 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.
>

I'm thinking import/export operations for the OpenVDB format, and using the
data structure during rendering. Did I miss something or is that it?

Again, thanks a lot for pointing me in the right direction.

Regards,
Rafael.


>
> It all depends on how experienced you are as a developer or what you
> think is interesting.
>
> Brecht.
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130501/83e5adf7/attachment.htm