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

Geraldine Chua chua.gsk at gmail.com
Sun May 20 19:11:03 CEST 2018


Wiki entry here:
https://wiki.blender.org/index.php/User:Geraldine/GSoC_2018/Reports

===================================

# Code familiarization

For the most part, GSoC is my first foray into the Cycles codebase. Because
of this, this week, as well as the previous weeks leading up to the start
of GSoC, was spent mostly exploring various parts of the cycles codebase
that may be relevant to my tasks, such as

* the exact algorithm used in `render/mesh_volume.cpp`
* the conversion from Blender object to Cycles Mesh in
`blender/blender_mesh.cpp`
* image saving and loading and memory allocation steps in
`render/image.cpp, device, blender/blender_session.cpp,
~/blender/makesrna/intern/rna_smoke.c`
* numerous bits and pieces of the `bvh` and `kernel` files

# Data structures

Currently, volumes are stored in kernel as raw arrays representing each
voxel's value. Upon some research into optimal data structures for storing
sparse 3D datasets, I came across some interesting papers that appeared to
be relevant:

* Fastsg: A Fast Routines Library for Sparse Grids (
https://www.sciencedirect.com/science/article/pii/S1877050912001597)
* Compact Data Structure and Scalable Algorithms for the Sparse Grid
Technique (
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.188.5367&rep=rep1&type=pdf
)

I had even implemented some parts of the code in Python before realizing
that these structures were shown to have negligible advantages over simply
using stl::map for fewer dimensionsal data, such as 3D images.

# 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.

# 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.
* Create a git branch for code changes.
* Make comparison tests on memory performance.
* If have time, move on to importing OpenVDB files.

# Questions and random musings

* Aside from logging the size of the data structures, is there another
method to measure memory usage?
* What is the difference in function between `bvh` and `kernel/bvh`?
* What are closures?
* What is a split kernel and how did it make Cycles more efficient than
before split kernel was implemented?
* Does index space vs object space mean the coordinate system of the world
vs the coordinate system of the object? How is the object's coordinate
system determined?

===================================

Some schedule notes

I am currently working at an internship which will conclude on June 14. It
was originally expected to end earlier, but I was requested to stay longer
in order to help train the new interns at my company. My schedule at this
internship is quite flexible, but I may still have some delay in progress
until mid-June. Starting June 16, I will have no other obligations as my
other plans have been cancelled so I can dedicate my full time to Cycles.

I would also like to make note of a potential problem in regards to
timezones. The vast majority of blender's developers live in Europe or the
Americas (GMT+2 to GMT-8), whereas I live in South East Asia (GMT+8), so
the time of the day in which the community is most active is during my
night. Especially since I work mostly during the day, there may be
difficulties in communicating and my presence on IRC may not be at the
busiest times. I will usually be there during my daytime though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180521/a9a4cfe1/attachment.html>


More information about the Soc-2018-dev mailing list