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

[Geraldine Chua]

Hi Brecht,

* It seems to be treating the grid as dense to some degree. Better would be
> to iterate over the leaf nodes, which we should ensure have the same number
> of voxels as our sparse tiles in Cycles for quick conversion.
> * The voxel values of a leaf can be copied in one block with
> leaf->buffer().data(), to avoid the overhead of accessors.
>

Trying with a quick patch of the above suggestions, VDB to sparse grid
conversion drops from 33 to 2 seconds! There still needs to be a bit of
handling, like off the top of my head, non-8x8x8 grids need to be iterated
through manually (are there VDBs that actually do this?), and loading Vec3
leaves into float4 arrays (cast to float) requires adding a dummy 1.0f
every 4th slot, so even with directly copying the leaf there still needs to
be some post-processing.

By the way, can you push the latest code to the branch? The last commit is
> from July 16, maybe what you are testing is different now.
>

Aside from the above patch and some experimental other things, I have just
uploaded everything to my gsoc branch. Feel free to have a look when you
can :)

Best regards,
Geraldine


On Thu, Jul 26, 2018 at 5:49 AM, Brecht Van Lommel <
brechtvanlommel at gmail.com> wrote:

> On Wed, Jul 25, 2018 at 8:06 PM Geraldine Chua <chua.gsk at gmail.com> wrote:
>
>> The mesh are identical (checking the look and size), which makes sense
>> conversion to sparse grid shouldn't destroy any significant data. The ~35
>> second time difference is based on how long it takes to iterate through the
>> entire example VDB grid. For larger VDBs, this may well be worth the extra
>> time saved in rendering, but that depends on the exported VDB. What the two
>> storage methods have in common is the ~25 seconds of vertex deduplication,
>> which your patch resolves :)
>>
>
> I'm sure the loading can be made much faster. There may be unexpected
> bottlenecks, but from looking at the code these things jumped out at me:
>
> * Try is to disable delayed loading with m_file->open(false), since this
> is known to be slow on some systems depending on the operating system and
> disk.
> * It seems to be treating the grid as dense to some degree. Better would
> be to iterate over the leaf nodes, which we should ensure have the same
> number of voxels as our sparse tiles in Cycles for quick conversion.
> * The voxel values of a leaf can be copied in one block with
> leaf->buffer().data(), to avoid the overhead of accessors.
>
> By the way, can you push the latest code to the branch? The last commit is
> from July 16, maybe what you are testing is different now.
>
> For blurred smoke, since velocity grid is taken into account when
>> generating the mesh, we basically end up with a mesh similar to the
>> original bounding box since usually every velocity voxel is active. Since
>> the volume shouldn't reach out of the domain anyway, I'm not sure what
>> padding is for?
>>
>
> Good point. I've seen cases where the velocity grid is expanded to be
> bigger than the density grid, to make it work better for Eulerian motion
> blur. In that case the bounds could be made tighter, but it's not something
> to worry about now.
>
> Thanks,
> Brecht.
>
>
> --
> 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/20180727/f28abf8e/attachment.html>