[Soc-2018-dev] Weekly Report #8 - Further Development for Cycles' Volume Rendering

Brecht Van Lommel brechtvanlommel at gmail.com
Mon Jul 9 00:39:24 CEST 2018


Hi,

I'm not sure why a *device_openvdb *is needed, I thought we agreed to
always use our own sparse grid storage and interpolation functions, without
the need for OpenVDB accessors?

So that would make the question maybe obsolete. ShaderData.object == 0
could be valid if it's the first object, and Shader.prim = -1 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?

Regards,
Brecht.




On Sat, Jul 7, 2018 at 2:35 AM Geraldine Chua <chua.gsk at gmail.com> wrote:

> ​(Resending this report with links to the photos instead of embedded
> photos)
>
> 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.
>
> 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.
>
> https://i.imgur.com/7TvPDWV.png
> *New OpenVDB Import checkbox*
>
> https://i.imgur.com/zM0Gbxt.png
> ​*When selected, all other settings are disabled. Can't edit external
> .vdb's yet!*
>
> 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.
>
> *Direct Interpolation on OpenVDB Grids*
>
> In order to be able to store OpenVDB grids rather than the usual textures,
> I created a wrapper class around *device_memory* called *device_openvdb*.
> *device_openvdb* 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 *TextureInfo*.
>
> 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.
>
> *Other Notes*
>
> https://i.imgur.com/HaMQTCi.png
>> Rendered smoke density is significantly lighter than expected, compared to
> the viewport preview, or comparison images from other engines.
>
> https://i.imgur.com/Mq9XweT.png
> https://i.imgur.com/jju5R4k.png
> https://i.imgur.com/UZaZ9g4.png
>> 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.
>
> *To-do next week*
>
>    - Figure out the problem behind saving OpenVDB grids as textures.
>    - Further testing, with .vdbs from other common engines e.g. Houdini,
>    with color / velocity grids, etc.
>    - Fix the light density issue.
>    - Check compatibility with Cycles stand-alone.
>
> *Questions*
>
> 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?
>
> --
> Soc-2018-dev mailing list
> Soc-2018-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180709/b5f71d4f/attachment-0001.html>


More information about the Soc-2018-dev mailing list