<div dir="ltr">Hi Brecht,<div><br></div><div>I went ahead and read the VDB paper <a href="http://www.museth.org/Ken/Publications_files/Museth-VDB_TOG13.pdf">here</a>, and was rather impressed.</div><div><br></div><div>Of all ideas, I'm going with OpenVDB integration, and adding Voxel Data texture to Cycles. </div>
<div>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.</div>
<div><br></div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 30, 2013 at 2:13 AM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rafael,<br>
<div class="im"><br>
On Tue, Apr 30, 2013 at 5:03 AM, Rafael Campos <<a href="mailto:rafaelcdn@gmail.com">rafaelcdn@gmail.com</a>> wrote:<br>
>> The other part is texturing, which can be developed independently.<br>
>> Basically we need equivalents of the blender internal point density<br>
>> and voxel data textures in cycles. For the point density texture the<br>
>> points come from particle systems or object vertices, and for the<br>
>> voxel data they come either from smoke or some voxel file format.<br>
>><br>
><br>
> This is very interesting too - really like the idea. I'm thinking that<br>
> simply coding blender internal counterparts on cycles won't cut it - are we<br>
> looking for improvements, or are there any known problems or limitations<br>
> with the existing code that we would like to address?<br>
<br>
</div>I don't have much experience working with these textures, maybe others<br>
have more ideas, but here are some things to consider.<br>
<br>
* One is that because cycles is node based, not all features need to<br>
be in a single big node, rather some things like point density<br>
turbulence settings or color source do not need to be built in, they<br>
could be node inputs that you plug other nodes in. Generally just<br>
trying to design a texture node that can be combined well with other<br>
nodes.<br>
<br></blockquote><div><br></div><div style> 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 ?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* I also remember quite a bit of confusion about the right way to set<br>
up a smoke material and texture in blender internal, to get the smoke<br>
data properly mapped, probably some things could be made more<br>
intuitive for cycles. Not sure if this requires any bigger changes or<br>
if it's easily fixable but worth looking into.<br>
<br></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Another thing that we can improve is that the entire volume data<br>
needs to be in memory, with a library like OpenVDB we might be able to<br>
render massive datasets because it can do disk caching and skip<br>
storage of empty space.<br>
<br></blockquote><div><br></div><div style>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* If we support a library like OpenVDB that does not store empty<br>
space, is there a way we can render that efficiently? Normally a<br>
texture just outputs an interpolated value at a given location, but<br>
can we somehow inform the integrator that it needs to skip a certain<br>
amount of empty space instead of stepping over all voxels?<br>
<br></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Maybe voxel data and point density textures could support motion blur?<br>
<br></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Further the Production Volume Rendering book and notes show all kinds<br>
of interesting effects. I didn't have time yet to read it all but<br>
maybe there's things that can be done at render time that wouldn't be<br>
automatically possible with existing nodes, for which a new node or<br>
node option could be added.<br>
<div class="im"><br>
>> Field3D, OpenVDB and Partio are all interesting libraries to look into<br>
>> as this would give us some support for more standard file formats than<br>
>> just Blender specific ones. Also interesting would be adding support<br>
>> for smoke to export to such file formats, as we can then add support<br>
>> for rendering such volume data without the entire thing being in<br>
>> memory at once.<br>
>><br>
><br>
> This alone is very cool by itself, but a more in-depth survey of the pros<br>
> and cons of supporting each of these might be needed (or not?). I'm just not<br>
> sure how open ended I should leave this, ie, how much of each I should<br>
> evaluate prior to submitting the proposal, or if evaluating each of these<br>
> might be part of the summer activities.<br>
<br>
</div>Personally I think OpenVDB support would be most interesting. It's<br>
being adopted by Houdini, Renderman and Arnold. It's better than<br>
Field3D in that it supports also sparse volume data sets instead of<br>
just dense ones, which makes it possible to render massive scene (at<br>
least for CPU rendering). Also seems to have some interesting features<br>
like level sets, filters, transformations, .. though not sure if we<br>
can do anything with those immediately.<br>
<br>
Anyway, for such a file format to be useful we'd need to be able to<br>
export Blender smoke data to it, so you'd probably spend time<br>
integrating it into various parts of Blender and wouldn't have much<br>
time left for a point density textures. So some variations could be:<br>
<br>
* Integrate OpenVDB with smoke, add new cycles voxel data texture, and<br>
maybe support it in blender internal voxel data texture too.<br>
* Add cycles voxel data texture + point density texture to cycles.<br>
* Add cycles voxel data texture + some extra interesting render time<br>
volume effects.<br></blockquote><div><br></div><div style>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?</div><div style>
<br></div><div style>Again, thanks a lot for pointing me in the right direction.</div><div style><br></div><div style>Regards,</div><div style>Rafael.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It all depends on how experienced you are as a developer or what you<br>
think is interesting.<br>
<span class="HOEnZb"><font color="#888888"><br>
Brecht.<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br></div></div></div>