<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&#39;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&#39;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">&lt;<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>&gt;</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 &lt;<a href="mailto:rafaelcdn@gmail.com">rafaelcdn@gmail.com</a>&gt; wrote:<br>
&gt;&gt; The other part is texturing, which can be developed independently.<br>
&gt;&gt; Basically we need equivalents of the blender internal point density<br>
&gt;&gt; and voxel data textures in cycles. For the point density texture the<br>
&gt;&gt; points come from particle systems or object vertices, and for the<br>
&gt;&gt; voxel data they come either from smoke or some voxel file format.<br>
&gt;&gt;<br>
&gt;<br>
&gt; This is very interesting too - really like the idea. I&#39;m thinking that<br>
&gt; simply coding blender internal counterparts on cycles won&#39;t cut it - are we<br>
&gt; looking for improvements, or are there any known problems or limitations<br>
&gt; with the existing code that we would like to address?<br>
<br>
</div>I don&#39;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&#39;t much time before the submission deadline, I&#39;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&#39;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&#39;t intuitive when I first tried it - but I&#39;ll have to look more into it. If approachable, I&#39;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&#39;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&#39;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&#39;t have time yet to read it all but<br>
maybe there&#39;s things that can be done at render time that wouldn&#39;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>
&gt;&gt; Field3D, OpenVDB and Partio are all interesting libraries to look into<br>
&gt;&gt; as this would give us some support for more standard file formats than<br>
&gt;&gt; just Blender specific ones. Also interesting would be adding support<br>
&gt;&gt; for smoke to export to such file formats, as we can then add support<br>
&gt;&gt; for rendering such volume data without the entire thing being in<br>
&gt;&gt; memory at once.<br>
&gt;&gt;<br>
&gt;<br>
&gt; This alone is very cool by itself, but a more in-depth survey of the pros<br>
&gt; and cons of supporting each of these might be needed (or not?). I&#39;m just not<br>
&gt; sure how open ended I should leave this, ie, how much of each I should<br>
&gt; evaluate prior to submitting the proposal, or if evaluating each of these<br>
&gt; might be part of the summer activities.<br>
<br>
</div>Personally I think OpenVDB support would be most interesting. It&#39;s<br>
being adopted by Houdini, Renderman and Arnold. It&#39;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&#39;d need to be able to<br>
export Blender smoke data to it, so you&#39;d probably spend time<br>
integrating it into various parts of Blender and wouldn&#39;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&#39;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>