<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 20, 2018 at 7:11 PM, Geraldine Chua <span dir="ltr"><<a href="mailto:chua.gsk@gmail.com" target="_blank">chua.gsk@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div># 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<wbr>` in `render/image.cpp`. It appears that smoke data specifically is retrieved through the custom functions in `~/blender/makesrna/intern/rna<wbr>_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></div></div></div></blockquote><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><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.</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div>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.</div><div><br></div><div>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:</div><div><a href="https://developer.blender.org/P692" target="_blank">https://developer.blender.org/<wbr>P692</a><br></div><div><br></div>In practice it will be a bit different to make it work well for GPUs.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div># 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></div></div></div></blockquote><div><br></div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">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.</div></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="text-decoration-style:initial;text-decoration-color:initial"><div style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-align:start;text-indent:0px;text-decoration-style:initial;text-decoration-color:initial">Most of the work for Cycles is supporting tiled 3D image storage and sampling. That means changing mostly the following files :</div><div style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-align:start;text-indent:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="monospace, monospace">render/image.cpp</font></div><div style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-align:start;text-indent:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="monospace, monospace">render/image.h</font></div><div style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-align:start;text-indent:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="monospace, monospace">device/device_memory.h</font></div><div style="background-color:rgb(255,255,255);text-align:start;text-indent:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="monospace, monospace">kernel/kernels/cpu/kernel_cpu_<wbr>image.h<br></font></div><div style="background-color:rgb(255,255,255);text-align:start;text-indent:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="monospace, monospace">kernel/kernels/cuda/kernel_<wbr>cuda_image.h<br></font></div><div style="background-color:rgb(255,255,255);text-align:start;text-indent:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="monospace, monospace">kernel/kernels/opencl/kernel_<wbr>opencl_image.h</font></div><div style="background-color:rgb(255,255,255);text-align:start;text-indent:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="monospace, monospace"><br></font></div>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.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>* 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></div></div></div></blockquote><div><br></div><div>You can do either OpenVDB import first, or do tiled 3D images first, but both will take at least some weeks to finish fully.</div><div><br></div></div></div></div>