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

[Brecht Van Lommel]

On Sun, May 20, 2018 at 7:11 PM, Geraldine Chua <chua.gsk at gmail.com> wrote:

> # Texture saving and loading
>
> For the most part, it seems like hashtables are the most efficient way to
> store sparse data sets. In order to optimize volume texture storage, I
> traced the top-most relevant code to `ImageManager::file_load_image` in
> `render/image.cpp`. It appears that smoke data specifically is retrieved
> through the custom functions in `~/blender/makesrna/intern/rna_smoke.c`
> rather than using OIIO. Thus, I can implement here a simple conversion of
> the volume grid into a map of <coordinates, voxel value> pairs. All parent
> functions will also need to be modified to be compatible with a map object
> instead of a vector/array.
>

<coordinates, voxel value> pairs are not an efficient way to store and
sample sparse volume data. If you have just a float (or half float) density
grid the coordinates can take up 3x more space than the voxel values.
Further hash tables will cause cache misses which is not good for rendering
performance.

The intention for the GSoC project was to use sparse 3D tiles, which are
also used in OpenVDB and most other volume rendering or simulation
software. What you do is split up the big 3D grid into smaller tiles of
8x8x8 voxels. If a tile contains no data its voxel values are not stored.
The code in mesh_volume.c already detects empty 8x8x8 tiles for creating
bounds, so some of that code can perhaps be reused.

The other part is how you map from the big grid to the tiles. The simplest
solution is to use a two level grid, and that's what I suggest to do. To
get an idea, this is how such a data structure and associated lookup
function would work:
https://developer.blender.org/P692

In practice it will be a bit different to make it work well for GPUs.

# To-do next week
>
> * Modify the `rna_SmokeModifier_*_grid_get` functions to optionally
> recieve a thresholding value and return an array of coordinates + values of
> all active voxels.
> * Modify callers of `rna_SmokeModifier_*_grid_get` to properly interpret
> and manipulate the new array type.
>

RNA is not the right place to convert a dense grid to a sparse grid, it's
going to be more complicated than it needs to be. It will be good if
Blender itself supports sparse grids in the future, but when it does there
will be no need for thresholding in RNA, rather it would be exposing
existing tiled data.

Most of the work for Cycles is supporting tiled 3D image storage and
sampling. That means changing mostly the following files :
render/image.cpp
render/image.h
device/device_memory.h
kernel/kernels/cpu/kernel_cpu_image.h
kernel/kernels/cuda/kernel_cuda_image.h
kernel/kernels/opencl/kernel_opencl_image.h

Lukas or I can help you figure out a design for the data structures, since
the whole GPU and device memory aspect is rather complicated. We can start
with a CPU implementation first but it should be along the right direction.


> * Create a git branch for code changes.
> * Make comparison tests on memory performance.
> * If have time, move on to importing OpenVDB files.
>

You can do either OpenVDB import first, or do tiled 3D images first, but
both will take at least some weeks to finish fully.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180521/6c2ad03d/attachment-0001.html>