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

[Brecht Van Lommel]

It's not clear to me how OpenVDB can use so much less memory? I suspect
that either it's not reporting memory usage correctly because it's being
allocated in the OpenVDB library instead of our own code, or there is some
issue to be fixed for sparse textures .

Regards,
Brecht.

On Mon, Jul 9, 2018 at 1:21 PM Geraldine Chua <chua.gsk at gmail.com> wrote:

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