<div dir="ltr"><div class="gmail_quote"><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><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"><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><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>