<div dir="ltr"><div><div>Wiki entry here: <a href="https://wiki.blender.org/index.php/User:Geraldine/GSoC_2018/Reports">https://wiki.blender.org/index.php/User:Geraldine/GSoC_2018/Reports</a><br><br>===================================<br><br># Code familiarization<br><br>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<br><br>* the exact algorithm used in `render/mesh_volume.cpp`<br>* the conversion from Blender object to Cycles Mesh in `blender/blender_mesh.cpp`<br>* image saving and loading and memory allocation steps in `render/image.cpp, device, blender/blender_session.cpp, ~/blender/makesrna/intern/rna_smoke.c`<br>* numerous bits and pieces of the `bvh` and `kernel` files<br><br># Data structures<br><br>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:<br><br>* Fastsg: A Fast Routines Library for Sparse Grids (<a href="https://www.sciencedirect.com/science/article/pii/S1877050912001597">https://www.sciencedirect.com/science/article/pii/S1877050912001597</a>)<br>* Compact Data Structure and Scalable Algorithms for the Sparse Grid Technique (<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.188.5367&rep=rep1&type=pdf">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.188.5367&rep=rep1&type=pdf</a>)<br><br>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.<br><br># Texture saving and loading<br><br>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.<br><br># To-do next week<br><br>* Modify the `rna_SmokeModifier_*_grid_get` functions to optionally recieve a thresholding value and return an array of coordinates + values of all active voxels.<br>* Modify callers of `rna_SmokeModifier_*_grid_get` to properly interpret and manipulate the new array type.<br>* Create a git branch for code changes.<br>* Make comparison tests on memory performance.<br>* If have time, move on to importing OpenVDB files. <br><br># Questions and random musings<br><br>* Aside from logging the size of the data structures, is there another method to measure memory usage?<br>* What is the difference in function between `bvh` and `kernel/bvh`?<br>* What are closures?<br>* What is a split kernel and how did it make Cycles more efficient than before split kernel was implemented?<br>* 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?<br><br>===================================<br></div><br></div>Some schedule notes<br><br>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.<br><br>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.<br><div><div><br></div></div></div>