<div dir="ltr"><div>Hi all,</div><div><br></div><div>I'm sorry for not being specific about the bug.</div><br>Render time for VDB grids converted to sparse grids:<br>- With Mesh: 00:48<br>- Without Mesh: 00:43<br><br>Render time for VDB grids directly saved as textures:<br>- With Mesh: 01:45<br><div>- Without Mesh: 00:25</div><div><br></div><div>For reference, it takes ~20 seconds to do the VDB to sparse texture conversion.<br></div><br>Both types of textures have noise and solid shadows only if there is a mesh. So for sparse VDBs, there is no slowdown issue, but there is still a problem with the visuals.<br><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>This is my patch for faster volume mesh generation:<br></div></blockquote><div><br></div>Checking how long each function takes (direct VDB with Mesh), total mesh building time is ~55 secs, with 31 seconds in adding nodes and 24 seconds in deduplicate_vertices. With Stefan's patch, deduplication time becomes negligible :) (1:15 rendering time!) The extra time in the node adding could be explained by the long iteration plus the padding.<br><br>Putting a diffuse shader shows a (heavily scaled down) complex mesh (<a href="http://pasteall.org/pic/show.php?id=9f0a3c8cb3e44368558fd81ca4261b50">http://pasteall.org/pic/show.php?id=9f0a3c8cb3e44368558fd81ca4261b50</a>). This may explain the long building time, but not the noise or the different shadow. Increasing light transparency to 16, max bounce to 24, and volume 
scattering to 4 yields the same issues. Trying the other test VDBs also has some problems (another example here: with mesh (<a href="http://pasteall.org/pic/show.php?id=1cea2c0f82d29ce53da1179a6162391d">http://pasteall.org/pic/show.php?id=1cea2c0f82d29ce53da1179a6162391d</a>) and without mesh (<a href="http://pasteall.org/pic/show.php?id=b978667234b614c02b1d6cd9494cc620)">http://pasteall.org/pic/show.php?id=b978667234b614c02b1d6cd9494cc620)</a>).<br><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>I think the place of the code is ok, it's easiest to do it just in time 
to ensure we don't do it when shader evaluation doesn't need it. We can 
cache the velocity lookup in ShaderData so it is performed only once if 
multiple volume reads are done.<br></div></blockquote><br><div>Alright! I originally thought to try to alter the ray shooting to gather more samples that way, since that is the approach mentioned by the paper, but I am very unfamiliar with that part of the kernel. This seemed like a decent approach to it. How would I go about caching the lookup? Maybe add a new member volume_velocity?</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>Request and export of the velocity grid should be disabled if the 
Blender object has motion blur disabled. This is done by checking if 
mesh->motion_steps > 0.<br></div></blockquote><div><br></div><div>I remember seeing veloctiy grids being used to color smoke, so there may be a use for it aside from motion blur. The velocity attribute node is supposed to plug into a Color socket as well, so I don't think it needs to be removed when there's no motion blur.</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>In principle the volume bounds also need padding to account for the 
motion blur, but if the velocity is not too big it's difficult to notice
 the difference so we could ignore that for now.<br></div></blockquote><div><br></div>There is an issue with smoke that (I think) happens when the smoke is near the edges of the bounding box (example: <a href="http://pasteall.org/pic/show.php?id=33ee8cb52f1b48a608bbbf1e8ba2faf4">http://pasteall.org/pic/show.php?id=33ee8cb52f1b48a608bbbf1e8ba2faf4</a>). Scaling the domain fixes the problem but greatly increases rendering time since every tile in the volume is now active. I wonder if padding can help with this?<br><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>It's not clear to me why there is a <span style="font-family:monospace,monospace"><span class="gmail-m_-5484079922823130582gmail-gi">kernel_data.cam.motion_samples</span></span>
 (= 3) used here. If I understand the paper correctly, formula (7) 
requires two volume lookups to compute the velocity, and then there is a
 third volume lookup to get the requested attribute itself.<br></div></blockquote><div><br></div>The idea behind the Eulerian motion blur formula is that instead of storing multiple smoke frames and interpolating, we can instead use the velocity data of Eulerian structures to calculate the appearance of the smoke at a given time aside from the current frame. If we use the algorithm only once at time N, what will happen is the smoke gets shifted to what it will look like at instance N, rather than the smear effect we need. The way I went about it was to calculate 3 samples: at the start, middle, and end of the shutter time, then average the samples together. So altogether there are 4 lookups: 1 velocity and 3 densities. Technically velocity should also be advected, but I tried it first without and the output seemed alright, so I forgot to try it with advected velocity :P I believe with one sample, there should be two lookups (1 velocity and 1 density).<br><br><div>Incidentally, I believe Eulerian motion blur was already implemented for dynamic meshes as sync_mesh_fluid_motion() in blender_mesh.cpp, but it works a bit differently, since there are only 2 samples per vertex and the vertices are pre-calculated. I haven't been able to trace very well how they are handled in the kernel either so the volume method is quite a bit different. Now that I think about it, it actually might be possible to also pre-calculate the density. I will have to try that out soon.<br></div><div><br></div><div>Best regards,</div><div>Geraldine<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 24, 2018 at 5:08 PM, Stefan Werner <span dir="ltr"><<a href="mailto:stewreo@gmail.com" target="_blank">stewreo@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 style="word-wrap:break-word;line-break:after-white-space">This is my patch for faster volume mesh generation:<div><a href="https://developer.blender.org/P756" target="_blank">https://developer.blender.org/<wbr>P756</a></div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">-Stefan</font></span><div><div class="h5"><br><div><br><blockquote type="cite"><div>On 23. Jul 2018, at 14:25, Stefan Werner <<a href="mailto:stewreo@gmail.com" target="_blank">stewreo@gmail.com</a>> wrote:</div><br class="m_-4012013983731132776Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space">Hi Geraldine!<br><div><br><blockquote type="cite"><div>On 20. Jul 2018, at 18:01, Geraldine Chua <<a href="mailto:chua.gsk@gmail.com" target="_blank">chua.gsk@gmail.com</a>> wrote:</div><div><div dir="ltr"><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. </div></div></blockquote><div><br></div>The volume mesh generation uses a vertex deduplication routine with O(n^2) runtime, that’s probably what you’re seeing. I should have a potential fix for that around somewhere, it’s possible to do this without creating duplicate vertices to begin with.</div><div><br><blockquote type="cite"><div><div dir="ltr">With reference to the Stephen's previous work on volume motion blur (<a href="https://github.com/tangent-animation/blender278/pull/103" target="_blank">https://github.com/tangent-<wbr>animation/blender278/pull/103</a>)<wbr>, 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" target="_blank">https://developer.blender.<wbr>org/P755</a>).<br></div></div></blockquote></div><div><br></div><div>Your patch works under the assumption that the motion vectors stored in the grid are in world coordinates, which they may not necessarily be. You probably need to apply the inverse scale and rotation matrix of the volume objects to the values read from the volume.</div><div><br></div><div>-Stefan</div></div></div></blockquote></div><br></div></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>