
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Geraldine!<div class=""><br class=""></div><div class="">My comments are inlined.</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 10. Jun 2018, at 18:04, Geraldine Chua <<a href="mailto:chua.gsk@gmail.com" class="">chua.gsk@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""></div></div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Memory usage of 'color' (__tex_image_float4_000) reduced from 3.06M to 2.50M (18.3% reduction)</div><div class="">Memory usage of 'density' (__tex_image_float_003) reduced from 783.75K to 644.00K (17.8% reduction)<br class="">Memory usage of 'flame' (__tex_image_float_011) reduced from 783.75K to 292.00K (62.7% reduction)<br class="">Memory usage of 'temperature' (__tex_image_float_019) reduced from 783.75K to 290.00K (63.0% reduction)<br class="">Memory usage of 'velocity' (__tex_image_float4_008) increased from 3.06M to 3.06M, not using sparse grid. (0% reduction)<br class=""></div></div></div></blockquote><div><br class=""></div><div>That’s looking good! The amount of memory saved will heavily depend on how values are distributed in a volume, I think in many use cases we will see significant savings.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Render time increased from 8:46 to 10:07 (0.86x speed)<br class=""></div></div></div></blockquote><div><br class=""></div><div>This we can eventually take a look at in a profiler. Maybe with some changes to the memory layout (morton order in tiles?) we can get a better cache utilisation from the tiled cache.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">While we could convert the offsets into cartesian coordinates, a more efficient method would be to simply store the coordinates of the first voxel in every tile. While this triples the size of <i class="">grid_info</i>, the lookup savings from not having to compute coordinates from the index should be worth it.<br class=""></div></div></div></blockquote><div><br class=""></div><div>This is something that eventually will need benchmarking. The old assumptions of memory vs speed tradeoffs and using lookup tables to save a few calculations don’t necessarily hold true any more with modern memory architectures, especially on GPUs. A memory lookup through a cache miss can take hundreds of cycles, while the processor can execute several additions or multiplications in a single cycle.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I think that beginning next week I can start working on creating the OpenVDB import function. An easy start would be adding a UI option for it, butI will have to read up some more on the background of the problem before I can say for certain what will need to be done for this feature.<br class=""></div></div></div></blockquote><div><br class=""></div><div>You can also take a look at the work that Luca Rood has done for Tangent Animation in their branch:</div><div><a href="https://github.com/tangent-animation/blender278/tree/openvdb_import" class="">https://github.com/tangent-animation/blender278/tree/openvdb_import</a></div><div><br class=""></div><div>Note that this code is still based on Blender 2.78, so it may take a little work to get it to run in master. There, OpenVDB import is done as a modifier.</div></div></div><div><br class=""></div><div>Thanks for your work on this project so far! It’s great to see tiled memory for volumes being implemented, previously there was lots of memory wasted on empty bytes!</div><div><br class=""></div><div>-Stefan</div></body></html>