<div dir="ltr"><div>Hi everyone, sorry for not asking around too much about this task first, as I admittedly don't know too much about the background.</div><div><br></div><div>I originally interpreted the task as converting OpenVDB grids into dense
 Cycles volumes instead of changing Cycles to store volumes in OpenVDB 
format. If what is expected is the former, we can trivially load the 
OpenVDB file, retrieve and transform the grids, then generate a dense 
texture from it, which now that I've typed it out looks pretty 
inefficient...<br><br>A quick naive implementation of the latter for 
native volumes would probably involve loading the voxel values into 
OpenVDB grids, saving the grid pointer in TextureInfo.data, and in the 
kernel use the provided OpenVDB methods for interpolation (probably by 
creating kernel_tex_volume_interp_3d() which calls the OpenVDB 
interpolation methods instead + editing whichever files call 
kernel_tex_image_interp_3d() to use OpenVDB's world to index space 
converters). Extending this to imported OpenVDB grids would be very easy
 as well.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>For the GSoC project I would mainly like to see native Cycles support 
for rendering OpenVDB volumes. Even if the Blender side is simply a 
string property on meshes to specify the OpenVDB filepath, and doing 
everything else in Cycles.<br></div></blockquote><div><br></div><div>Thank you for clarifying :) Luca's code is very useful though for providing the UI for importing + positioning and transforming the imported volume (and it let me have an easy way to put the volume in front of the camera for Cycles testing :P). If all we need to worry about right now is the Cycles side, all the Blender side needs to do is pass the file path and the (linear) transformation matrix of each grid, then let Cycles load the grids itself (although this isn't very efficient since the file gets loaded twice and the first time, the volume is basically converted into a dense array). May I ask how do you think would be a good way of implementing Blender-side importing?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Users should not need to enable grids in the UI. Cycles (and later the 
Blender viewport) can request attributes based on the shader graph, and 
only load the relevant ones in that case. For example for the smoke 
object in Cycles this is done <span style="font-family:monospace,monospace">create_mesh_volume_attributes</span>.</div></blockquote><div><br></div><div>Unless the volume is imported as a Smoke object, I don't think the attribute nodes can be assigned. Maybe for now we can just check if a grid with a corresponding name for each attribute exists and load it if it does? How this will be handled depends on the how the importing on the Blender side will be implemented.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>The ideal solution is to have a new volume object type in Blender, and 
any other implementation will be a placeholder.<br></div></blockquote><div><br>It would be nice to have a Volume primitive working for smoke simulation at the very least. Broadly, my interpretation of this task is converting structs / classes in Blender that currently use large but sparsely populated arrays to use OpenVDB trees instead. Based on an initial look through, voxel values for smoke are stored in FLUID_3D (?), but it looks like an external library so I don't think this is the struct to convert?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>First, if we want this to work on the GPU, you’d need to import OpenVDB 
data into your sparse 3D texture data structures. The OpenVDB library 
itself has lookup calls, but those won’t be available in OpenCL or CUDA.<br></div></blockquote><div><br>I'm really surprised that OpenVDB is not officially compatible with GPU rendering. An easy patch is as you say, converting trees into arrays. From a quick google search there are some libraries for OpenVDB compatibility with OpenCL (<a href="https://github.com/matthew-reid/Graphtane">https://github.com/matthew-reid/Graphtane</a>) and CUDA (<a href="https://developer.nvidia.com/gvdb">https://developer.nvidia.com/gvdb</a>) though I haven't looked too deeply into these.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Coordinates in OpenVDB are a bit tricky and unfortunately, some programs
 odd conventions. If you skim Luca’s code, you can see that he has 
workarounds based on the metadata of the file.  The grids in a file also
 don’t need to have the same bounding box. When mapping normalized 
coordinates to VDB’s index space, make sure your conversion is 
consistent across all grids. <br>
<br>
Also, I recently ‘discovered’ that a VDB file can happily store several 
grids with the same name. Be careful when referring to grid by their 
name instead of their index. The name iterator of OpenVDB will append 
numbers to the names, but if you query a grid’s name directly, those 
numbers are omitted!<br></div></blockquote><div><br></div><div>Thanks for the heads up on these issues :) I will try to look into them some more. Importing from other programs without very strict standards for the file type is always bound to be a little messy.<br></div><div><br></div><div>Best regards,</div><div>Geraldine<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 27, 2018 at 1:21 AM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@gmail.com" target="_blank">brechtvanlommel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Tue, Jun 26, 2018 at 4:42 PM Stefan Werner <<a href="mailto:stewreo@gmail.com" target="_blank">stewreo@gmail.com</a>> wrote:<br></span><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, I recently ‘discovered’ that a VDB file can happily store several grids with the same name. Be careful when referring to grid by their name instead of their index. The name iterator of OpenVDB will append numbers to the names, but if you query a grid’s name directly, those numbers are omitted!<br></blockquote><div><br></div></span><div>If I remember correctly this can happen when writing clustered grids from Houdini?<br></div><a href="http://www.sidefx.com/docs/houdini/pyro/clustering.html" target="_blank">http://www.sidefx.com/docs/<wbr>houdini/pyro/clustering.html</a> <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The correct way to interpret those would be to merge grids with the same name, or at least render them as if they were merged. I wouldn't expect us to support this immediately though, it's a bit of an advanced case which can be worked around by the user. There's also things like perspective grids for camera adaptive resolution, but we should also ignore that for now.<br></div><div class="gmail_quote"><br></div></div>
<br>-- <br>
Soc-2018-dev mailing list<br>
<a href="mailto:Soc-2018-dev@blender.org">Soc-2018-dev@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/soc-2018-dev" rel="noreferrer" target="_blank">https://lists.blender.org/<wbr>mailman/listinfo/soc-2018-dev</a><br>
<br></blockquote></div><br></div>