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

[Geraldine Chua]

Hi Brecht,

*device_openvdb* is for storing pointers to the OpenVDB grids for directly
sampling. I thought it may be possible to implement and wanted to see the
performance of doing so.

I've managed to solve the kernel issue (it wasn't actually related to the
kernel, the missing volume was caused by some naming issue), so textures
with data stored in OpenVDB grids should now be fully functional.

Testing with converting the sample smoke.vdb to texture and rendering the
texture:

Dense Texture (Original): 10.53M, 00:17.70
Sparse Texture: 5.48M, 00:19.62 (48% smaller, 10% slower)
OpenVDB Texture: 769.62K, 00:26.22 (93% smaller, 48% slower)

Maybe with larger volumes, the speed loss from directly accessing OpenVDB
grids in the kernel will be lower thanks to caching, and the space savings
are much, much larger compared to the sparse textures. For GPU rendering,
OpenVDB textures cannot be used, but for CPU rendering, it may be possible
to allow users to choose between storing volumes in dense, sparse, or
OpenVDB textures, trading speed for space.

Best regards,
Geraldine


On Mon, Jul 9, 2018 at 6:39 AM, Brecht Van Lommel <brechtvanlommel at gmail.com
> wrote:

> 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
>>
>
> --
> 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/cbca1658/attachment.html>