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

Geraldine Chua chua.gsk at gmail.com
Sat May 26 14:22:06 CEST 2018


Wiki link:
https://wiki.blender.org/index.php/User:Geraldine/GSoC_2018/Reports#Week_2

Unfortunately was not able to do much this week, thanks to some personal
stuff happening.

*Notes on Last Week's Report*

On advice from Brecht:

* Conversion from dense to sparse grid should be done in *render/image.cpp*
after image manipulation such as scaling. I was mistaken in thinking that
there will be a performance issue otherwise.

* Check out *device/device_memory.h* for memory handling and
*kernel/kernels/<device>/kernel_<device>_image.h* files to see how volumes
are read.

* Don't use std::map for sparse grid (see below).

* Overestimated timeline, will probably not get to Voxel primitive until
next week at the earliest.

*Sparse Grid Data Structure*

Sparse grids should, instead of using map, have an auxiliary array to keep
track of active and inactive tile indexes. Tentatively the structure should
be something similar to this:

struct VolumeTile {
    float4 voxels[CUBE_SIZE * CUBE_SIZE * CUBE_SIZE];
}
VolumeTile *grid;   /* array of active tiles */
int *indexes;
/* maps the index of a tile in the original volume to its index in the
sparse volume
 * e.g. indexes[A] = B means a tile at orig_vol[A] is now at grid[B]
 * tiles not in grid (inactive tiles) have index -1. */

Since *VolumeTile* is just an array of floats, it may be better to forgo
the struct and just make grid a float array and make indexes keep track of
the start of each "tile". This will make the code more difficult to read
though, and I am not sure about the performance difference.

*Other progress*

I have written functions for generating and looking up in the sparse grid,
but most of the code has problems like inconsistent typing because I am not
yet certain of how the volume will be called during rendering, so I cannot
properly write the functions yet. I have spent most of this week tracing
the rendering process.

Since the volume textures will be stored as *device_memory*, I needed to
trace what *device_memory* was converted to after *device_update* completed
(seems to be *ShaderData*), and from there figure out how voxels are looked
up.

>From what I can tell, the lookup change should be inserted in the functions
in *kernel/kernel_volume.h* that call *ccl_device_inline bool
volume_shader_sample()*, but I will need to investigate further to be sure.

On an unrelated note, it may be worth templating the separate float/float3
functions in *geom/geom_primitive.h* and *geom/geom_volume.h* since most of
the code is identical.

*To-do next week*

* Finish tracking the whole volume rendering process.
* Finalize data structure of sparse volume and insert the creation and
lookup functions where appropriate.
* Testing code, compare performance.
* Create a Git branch, upload changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180526/8bad03d8/attachment.html>


More information about the Soc-2018-dev mailing list