<div dir="ltr"><div>Hi Brecht,</div><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><div>* It seems to be treating the grid as dense to some degree. Better 
would be to iterate over the leaf nodes, which we should ensure have the
 same number of voxels as our sparse tiles in Cycles for quick 
conversion.</div><div>* The voxel values of a leaf can be copied in one block with <font face="monospace, monospace">leaf->buffer().data()</font>, to avoid the overhead of accessors.</div></div></blockquote><div><br></div><div>Trying with a quick patch of the above suggestions, VDB to sparse grid conversion drops from 33 to 2 seconds! There still needs to be a bit of handling, like off the top of my head, non-8x8x8 grids need to be iterated through manually (are there VDBs that actually do this?), and loading Vec3 leaves into float4 arrays (cast to float) requires adding a
 dummy 1.0f every 4th slot, so even with directly copying the leaf there
 still needs to be some post-processing.<br></div><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>By the way, can you push the latest code to the branch? The last commit 
is from July 16, maybe what you are testing is different now.<br></div></blockquote><div><br></div><div>Aside from the above patch and some experimental other things, I have just uploaded everything to my gsoc branch. Feel free to have a look when you can :)</div><div><br></div><div>Best regards,</div><div>Geraldine</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 26, 2018 at 5:49 AM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@gmail.com" target="_blank">brechtvanlommel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Wed, Jul 25, 2018 at 8:06 PM Geraldine Chua <<a href="mailto:chua.gsk@gmail.com" target="_blank">chua.gsk@gmail.com</a>> wrote:<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>The mesh are identical (checking the look and size), which makes sense conversion to sparse grid shouldn't destroy any significant data. The ~35 second time difference is based on how long it takes to iterate through the entire example VDB grid. For larger VDBs, this may well be worth the extra time saved in rendering, but that depends on the exported VDB. What the two storage methods have in common is the ~25 seconds of vertex deduplication, which your patch resolves :)<br></div></div></div></blockquote><div><br></div></span><div>I'm sure the loading can be made much faster. There may be unexpected bottlenecks, but from looking at the code these things jumped out at me:</div><div><br></div><div>* Try is to disable delayed loading with <font face="monospace, monospace">m_file->open(false)</font>, since this is known to be slow on some systems depending on the operating system and disk.<br></div><div>* It seems to be treating the grid as dense to some degree. Better would be to iterate over the leaf nodes, which we should ensure have the same number of voxels as our sparse tiles in Cycles for quick conversion.</div><div>* The voxel values of a leaf can be copied in one block with <font face="monospace, monospace">leaf->buffer().data()</font>, to avoid the overhead of accessors.</div><div><br></div><div><div>By the way, can you push the latest code to the branch? The last commit is from July 16, maybe what you are testing is different now.<br></div></div><div><br></div></div><div class="gmail_quote"><span class=""><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>For blurred smoke, since velocity grid is taken into account when generating the mesh, we basically end up with a mesh similar to the original bounding box since usually every velocity voxel is active. Since the volume shouldn't reach out of the domain anyway, I'm not sure what padding is for?</div></div></blockquote><div><br></div></span><div>Good point. I've seen cases where the velocity grid is expanded to be bigger than the density grid, to make it work better for Eulerian motion blur. In that case the bounds could be made tighter, but it's not something to worry about now. </div><div><br></div><div>Thanks,</div><div>Brecht.</div><div><br></div></div></div>
<br>-- <br>
Soc-2018-dev mailing list<br>
<a href="mailto:Soc-2018-dev@blender.org">Soc-2018-dev@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/soc-2018-dev" rel="noreferrer" target="_blank">https://lists.blender.org/<wbr>mailman/listinfo/soc-2018-dev</a><br>
<br></blockquote></div><br></div>