<div dir="ltr"><b>OpenVDB Importer</b><br><br>I made some finishing touches to the OpenVDB importer. After discussion with Brecht, node based texture loading is not the preferred input method. At the moment, I will just leave the simple interface as is, i.e. VDB is input as a Smoke Domain.<br><br>It is now possible to store volume textures as VDB grids, though it is not yet enabled it and there is no interface yet for toggling. For large volumes (hundreds of MB), this results in both rendering speed-up and large memory savings (quick speed test with bunny_cloud.vdb stored as sparse grid v.s. VDB grid: 50 and 24 secs respectively). Volume textures thus now have 3 options for storage: the original dense array, a sparse array, or a VDB grid. With this, it may be possible to write a OpenVDB exporter.<br><br>There appears to be a bug where VDB textures are rendered with artifacts and solid shadows, but only if a volume mesh is created. I have attempted to debug the issue but cannot figure out the reason so far. In addition to this, generating a mesh takes a considerable amount of time compared to built-in smoke. A simple fix to these issues would be disabling volume mesh construction for VDB grids, but it would be nice to figure out the cause of this bug. Here is a comparison image of a VDB texture of an imported bunny_cloud:<br><br>Without volume mesh: <a href="https://i.imgur.com/ispyeGF.png">https://i.imgur.com/ispyeGF.png</a><br>With volume mesh: <a href="https://i.imgur.com/6hbJUYp.png">https://i.imgur.com/6hbJUYp.png</a><br><b><br>Volume Motion Blur</b><br><br>With reference to the Stephen's previous work on volume motion blur (<a href="https://github.com/tangent-animation/blender278/pull/103">https://github.com/tangent-animation/blender278/pull/103</a>), I wrote a minor patch with promising results. I am uploading the diff instead of committing since it's pretty hacky and there may be more efficient ways of going about implementing it (<a href="https://developer.blender.org/P755">https://developer.blender.org/P755</a>).<br><br>This patch uses the Eulerian motion blur algorithm (Eulerian Motion Blur, 2007, Doyub Kim and Hyeong-Seok Ko, <a href="https://doyub.com/research/2007/emb/emb.pdf">https://doyub.com/research/2007/emb/emb.pdf</a>) since the Blender smoke simulator readily provides velocity data. I had difficulties figuring out how to work the sampling into the current kernel structure, so right now the advected points are calculated right before the voxel is interpolated. The point is advected 3 times (may be made customizable by the user) across the shutter speed and the densities are then averaged. Motion blur for the smoke can be enabled by checking the Motion Blur checkbox in the Render tab.<br><br>Quick example of a high vorticity smoke, with 3 samples, 0.5 shutter speed, centered on frame, and the default shutter curve:<br><br>Without motion blur: <a href="https://i.imgur.com/YvYN6Gu.png">https://i.imgur.com/YvYN6Gu.png</a><br>With motion blur: <a href="https://i.imgur.com/A4nBLWv.png">https://i.imgur.com/A4nBLWv.png</a><br><br>It would be nice to see if the blur actually looks good in animation, but I am still in the process of rendering one.<br><br>An alternative algorithm for motion blur, as used in films such as the Good Dinosaur, is outlined here (Efficient Rendering of Volumetric Motion Blur<br>Using Temporally Unstructured Volumes, 2016, Magnus Wrenninge, <a href="http://jcgt.org/published/0005/01/01/paper-lowres.pdf">http://jcgt.org/published/0005/01/01/paper-lowres.pdf</a>). Unfortunately, this algorithm is very animation oriented, and implementing this would require an overhaul of how Cycles currently handles volume data, i.e. one grid loaded per frame, and TUVs are not inherently compatible with OpenVDB.<br><br><b>To-dos next week</b><br><br>Unless there are any major issues or recommended changes for any of the previous tasks, the only things left to do are cleanup and review. Brecht has given me his previous work on implementing a native Volume primtive in Blender, which I will review and see if I can work on.<br><br><b>Questions</b><br><ul><li>Is there a better way to implement OpenVDB import interface compared to how it currently is?</li><li>Should I provide an option for the users to choose storage options for volume texture? (Currently defaults to sparse grid) If yes, where would I put it?</li><li>Any comments on the motion blur patch?</li></ul></div>