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

Brecht Van Lommel brechtvanlommel at gmail.com
Wed Jul 25 23:49:55 CEST 2018


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180725/b7ae3259/attachment.html>


More information about the Soc-2018-dev mailing list