<div dir="ltr">Hi,<div><br></div><div>I'm not sure why a <i style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">device_openvdb </i>is needed, I thought we agreed to always use our own sparse grid storage and interpolation functions, without the need for OpenVDB accessors?</div><div><br></div><div>So that would make the question maybe obsolete. <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><font face="monospace, monospace">ShaderData.object == 0</font> could be valid if it's the first object, and <font face="monospace, monospace">Shader.prim = -1 </font>is also correct for volume shading since there is no one corresponding primitive like a triangle then. So I guess perhaps the problem happens after that, in retrieving the attribute?</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Regards,</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Brecht.</span></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 7, 2018 at 2:35 AM Geraldine Chua <<a href="mailto:chua.gsk@gmail.com">chua.gsk@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>(Resending this report with links to the photos instead of embedded photos)<br></div><div><br></div><div>This week, I have finished the foundation work needed to get
OpenVDB importing working in Cycles, as well as a very simple importer
for the Blender UI. The importer now works under specific cases.</div><br>Broadly,
Cycles expects an OpenVDB file to be associated with a Smoke Domain
passed to it from Blender. This Domain will be treated as the bounding
box of the vdb volume, and the volume will be scaled and positioned
appropriately. If a valid .vdb file is recieved from the Smoke Domain,
Cycles will either convert the grid into a dense texture, or save the
vdb grid(s) directly.<br><div><br></div><div><a href="https://i.imgur.com/7TvPDWV.png" target="_blank">https://i.imgur.com/7TvPDWV.png</a></div><div></div><div></div><div><i></i></div><div><i>New OpenVDB Import checkbox</i></div><div><br></div><div><div><a href="https://i.imgur.com/zM0Gbxt.png" target="_blank">https://i.imgur.com/zM0Gbxt.png</a><br></div><i>When selected, all other settings are disabled. Can't edit external .vdb's yet!</i><br></div><div><br></div>For
the Blender UI of the importer, in order to be able to visualize the
volume, a lot of the OpenVDB pointcache code was reused. An interesting
quirk of this is that Blender can actually pass the cached smoke data as
a texture to Cycles, rather than have Cycles load and convert the grid
itself, since the same grid to dense array conversion code is used by
both Blender and Cycles. Regardless, Cycles can do the conversion even
without the cached smoke from Blender.<br><br><b>Direct Interpolation on OpenVDB Grids</b><br><br>In order to be able to store OpenVDB grids rather than the usual textures, I created a wrapper class around <i>device_memory</i> called <i>device_openvdb</i>. <i>device_openvdb</i>
has two new members: the grid pointer and a const accessor to the grid.
Everything else is kept roughly the same, and a pointer to the grid can
then in theory be saved as a <i>TextureInfo</i>.<br><br>However, for
whatever reason, the vdb grid texture is not loaded / cannot be found in
the kernel. The ShaderData of the vdb texture lacks a valid object ID,
and if you try to force it past the check anyway, an invalid texture is
returned (my test returned a TextureInfo with all members set to 0,
though it may just be random data). I am still trying to figure out what
may be the root cause of this.<br><br><b>Other Notes</b><br><div><br></div><div><div><a href="https://i.imgur.com/HaMQTCi.png" target="_blank">https://i.imgur.com/HaMQTCi.png</a><br></div><br></div><div></div><div>Rendered
smoke density is significantly lighter than expected, compared to the
viewport preview, or comparison images from other engines.</div><div><br></div><div><div><a href="https://i.imgur.com/Mq9XweT.png" target="_blank">https://i.imgur.com/Mq9XweT.png</a></div><div><a href="https://i.imgur.com/jju5R4k.png" target="_blank">https://i.imgur.com/jju5R4k.png</a></div><div><a href="https://i.imgur.com/UZaZ9g4.png" target="_blank">https://i.imgur.com/UZaZ9g4.png</a><br></div></div><div><br></div>For
some reason, if the smoke domain is too large, the volume cannot be
seen. This doesn't seem to affect the Cycles render though, so it's not
too much of a priority to fix.<br><br><b>To-do next week</b><br><ul><li>Figure out the problem behind saving OpenVDB grids as textures.</li><li>Further testing, with .vdbs from other common engines e.g. Houdini, with color / velocity grids, etc.</li><li>Fix the light density issue.</li><li>Check compatibility with Cycles stand-alone.</li></ul><div><b>Questions</b></div><div><br></div><div>Well,
just one question... I've really been stumped on why the ShaderData /
TextureInfo for OpenVDB textures is invalid. Strictly speaking, the only
difference between saving normal textures and the OpenVDB grid texture
is the TextureInfo.data now points to the const accessor of the grid
instead of a dense array. The only obvious difference in ShaderData from
normal volume textures is that always ShaderData.prim = -1 and
ShaderData.object = 0. Does anyone know what may possibly cause
ShaderData to still hold its default values?</div><br></div>
-- <br>
Soc-2018-dev mailing list<br>
<a href="mailto:Soc-2018-dev@blender.org" target="_blank">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/mailman/listinfo/soc-2018-dev</a><br>
</blockquote></div>