<div dir="ltr">Nich: Ken actually told me about that a normals compression in the vbos a while back. Could be an option but he considers it seriously, especially since he has been working a lot to help me improve the VBO infrastructure in VTK and made major changes. See this MR for our work on the non-interleaved shared VBOs: <a href="https://gitlab.kitware.com/vtk/vtk/merge_requests/2269">https://gitlab.kitware.com/vtk/vtk/merge_requests/2269</a><div><br></div><div>Other good news: we're now up to 190 fps for the same 110k with vertices guys :)</div><div>I rewrote the mesh normals filter to get a fast-path (all of this encouraged by Ken), which allows me to do five times faster than the previous filter (even with my changes to optimize it. 16x faster without my previous changes). The rest that helped bring it to ~200fps is the following:</div><div><br></div><div><div>- Skip frustrum culling</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">renderer->RemoveCuller(renderer->GetCullers()->GetLastItem());</blockquote><div><br></div><div>- Skip auto shift & scale of VBO</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">openglmapper->SetVBOShiftScaleMethod(vtkOpenGLVertexBufferObject::DISABLE_SHIFT_SCALE);</blockquote><div><br></div><div>Those two changes allow to bypass `GetBounds()`, which needed to recompute the bounds at each frame since we were deforming our meshes.</div></div><div><br></div><div>So... no streaming in the vbos yet, but with 190 fps for 110k vertices with normals, we're doing pretty good now with VTK!<br>See here for MR: <a href="https://gitlab.kitware.com/vtk/vtk/merge_requests/2271">https://gitlab.kitware.com/vtk/vtk/merge_requests/2271</a></div><div><br></div><div>I'll leave to France that Monday and will be back on January 2nd.</div><div><br></div><div>Best,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(136,136,136);font-size:12.8000001907349px">Alexis Girault</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><span style="color:rgb(136,136,136);font-size:12.8000001907349px">R&D Engineer in Medical Computing</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><span style="color:rgb(136,136,136);font-size:12.8000001907349px">Kitware, Inc.</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><a href="http://www.kitware.com/" rel="noreferrer" style="color:rgb(17,85,204);font-size:12.8000001907349px" target="_blank">http://www.kitware.com</a><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><font color="#999999"><a href="tel:(919)+969-6990+x325" target="_blank"><span style="font-size:12.8000001907349px">(919) 969-6990 x3</span>25</a></font><br></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Dec 14, 2016 at 11:50 AM, Milef, Nicholas Boris <span dir="ltr"><<a href="mailto:milefn@rpi.edu" target="_blank">milefn@rpi.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">Nice work! Those are some much better numbers!
<div><br>
</div>
<div>I'm not totally sure how to do normals efficiently. We could possible have some sort of normal calculation module since this only affects the lighting, so a few frames of incorrect normals shouldn't be too bad. In terms of GPU computation, if the mesh
can be transformed with a transformation matrix, it's easy to do in the vertex shader. In the case of deformable objects though, it wouldn't be trivial to do in shaders and would require a large change to the way rendering works, and it could actually decrease
performance (I'm not really sure because I haven't tried). Another option could be to use OpenCL or a compute shader to do this, but there will likely be some latency involved.</div>
<div><br>
</div>
<div>Here's an article about some other techniques, but I think it requires deforming imaginary vertices, which may make the physics calculations work too much:</div>
<div><a href="https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch42.html" target="_blank">https://developer.nvidia.com/<wbr>gpugems/GPUGems/gpugems_ch42.<wbr>html</a></div>
<div><br>
</div>
<div>One thing that can be done is compressing the normals if the transfer operation is a bottleneck. This doesn't have anything to do with the normal calculations, but you could reduce the normals into 4 bytes using 2 normal components (generally 10-bits each)
and a sign bit to point to the direction of the third component. Some game engines do this type of compression in g-buffers, but it should work pretty well for meshes too as it's the same idea. Generally the precision can be much less for normals than for
positions, but I'm not sure if VTK would be willing to sacrifice that precision.<br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div id="m_-572053591721898528divRpF244664" style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Alexis Girault [<a href="mailto:alexis.girault@kitware.com" target="_blank">alexis.girault@kitware.com</a>]<br>
<b>Sent:</b> Wednesday, December 14, 2016 11:01 AM<br>
<b>To:</b> Qi, Trudi<br>
<b>Cc:</b> Milef, Nicholas Boris; Hong Li; <a href="mailto:imstk-developers@imstk.org" target="_blank">imstk-developers@imstk.org</a><div><div class="h5"><br>
<b>Subject:</b> Re: [Imstk-developers] Number of vertices in OR room<br>
</div></div></font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr">Thanks guys for your answers!<br>
<br>
FIY, I have been working on the normals generation. The links (neighborhood information) was recomputed at each frame, and some options (splitting, consistency check for normals orientation) would be done by default. By putting those options to OFF we go from
3 fps to 16fps. I then worked on optimizing things to avoid recomputing too many things, and I'm up to 35fps, so big boost.
<div><br>
</div>
<div>Still not back to 60fps but we know normals computation can be expensive. However, we'll keep profiling with Ken to see if we can do more work to improve the normals computation, or anything else that ends up being the bottleneck (we still haven't looked
at streaming vertices VBO). Nick: is computing normals on the GPU something you think could be done in VTK?
<div><br>
</div>
<div>On another point, the changes to avoid rebuilding the shaders too many times (ex: transformations of the actor) is in VTK upstream:</div>
<div><a href="https://gitlab.kitware.com/vtk/vtk/merge_requests/2222/diffs" target="_blank">https://gitlab.kitware.com/<wbr>vtk/vtk/merge_requests/2222/<wbr>diffs</a><br>
</div>
<div>This fixes the issue with a lot of actors moving too many times. Using a CompositePolyDataMapper could have also worked for objects sharing the same shaders.</div>
<div><br>
</div>
<div>I'll keep you up-to-date on the next improvements for VTK in real-time.</div>
<div><br>
</div>
<div>Best,</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="m_-572053591721898528gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr"><span style="color:rgb(136,136,136);font-size:12.8000001907349px">Alexis Girault</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px">
<span style="color:rgb(136,136,136);font-size:12.8000001907349px">R&D Engineer in Medical Computing</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px">
<span style="color:rgb(136,136,136);font-size:12.8000001907349px">Kitware, Inc.</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px">
<br style="color:rgb(136,136,136);font-size:12.8000001907349px">
<a href="http://www.kitware.com/" rel="noreferrer" style="color:rgb(17,85,204);font-size:12.8000001907349px" target="_blank">http://www.kitware.com</a><br style="color:rgb(136,136,136);font-size:12.8000001907349px">
<font color="#999999"><a href="tel:(919)+969-6990+x325" target="_blank"><span style="font-size:12.8000001907349px">(919) 969-6990 x3</span>25</a></font><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Mon, Dec 12, 2016 at 5:30 PM, Qi, Trudi <span dir="ltr">
<<a href="mailto:qid@rpi.edu" target="_blank">qid@rpi.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US">
<div class="m_-572053591721898528m_4689608866709699188WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1f497d">Hi Alexis,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1f497d">In CCT, # of vertices for static object and tools should be similar to ETI. I have not yet finalize the vertices number for the simulation models, as that will be depending on the resolution
of the underlying 3D voxel grid chosen for both cutting and deformation. I am still at the stage of development and will be figuring out how large the voxel density should be to achieve a tradeoff between speed and physically plausibility later some time.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1f497d">Based on my current review of the other similar research work on cutting simulation, I would say 10K for PBD and 100K for deformable surface meshes (for rendering) should be fair enough.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1f497d">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1f497d">Trudi<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Imstk-developers [mailto:<a href="mailto:imstk-developers-bounces@imstk.org" target="_blank">imstk-developers-bounc<wbr>es@imstk.org</a>]
<b>On Behalf Of </b>Milef, Nicholas Boris<br>
<b>Sent:</b> Monday, December 12, 2016 4:43 PM<br>
<b>To:</b> Hong Li <<a href="mailto:hongli03129@gmail.com" target="_blank">hongli03129@gmail.com</a>>; Alexis Girault <<a href="mailto:alexis.girault@kitware.com" target="_blank">alexis.girault@kitware.com</a>></span></p>
<div>
<div class="m_-572053591721898528h5"><br>
<b>Cc:</b> <a href="mailto:imstk-developers@imstk.org" target="_blank">imstk-developers@imstk.org</a><br>
<b>Subject:</b> Re: [Imstk-developers] Number of vertices in OR room<u></u><u></u></div>
</div>
<p></p>
</div>
</div>
<div>
<div class="m_-572053591721898528h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">I found that computing the normals took a long time in the profiling I did, but I didn't realize that it scaled like that. Where is this being calculated?
<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">100-200k doesn't seem unreasonable for deformable. For static meshes, a few million shouldn't be too difficult to achieve, but this is mostly GPU-limited and is
heavily dependent on the amount of work done in the shaders and the number of unique objects.<u></u><u></u></span></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="color:black">
<hr size="2" width="100%" align="center">
</span></div>
<div id="m_-572053591721898528m_4689608866709699188divRpF534569">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"> Imstk-developers [<a href="mailto:imstk-developers-bounces@imstk.org" target="_blank">imstk-developers-bounces@imst<wbr>k.org</a>]
on behalf of Hong Li [<a href="mailto:hongli03129@gmail.com" target="_blank">hongli03129@gmail.com</a>]<br>
<b>Sent:</b> Monday, December 12, 2016 4:03 PM<br>
<b>To:</b> Alexis Girault<br>
<b>Cc:</b> <a href="mailto:imstk-developers@imstk.org" target="_blank">imstk-developers@imstk.org</a><br>
<b>Subject:</b> Re: [Imstk-developers] Number of vertices in OR room</span><span style="color:black"><u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">In the ETI simulator, # of vertices of static scene objects is 103K, # of vertices in tools(non-deformable, but will be translated and rotated) is 99K, # of vertices in deformable skinning objects is 80K, # of
vertices in deformable PBD objects is 6K. <u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="color:black">I'm not sure if the VERY high resolution mesh for objects like tools and teeth are really necessary.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Hong<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><span style="color:black">On Mon, Dec 12, 2016 at 2:20 PM, Alexis Girault <<a href="mailto:alexis.girault@kitware.com" target="_blank">alexis.girault@kitware.com</a>> wrote:<u></u><u></u></span></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"><span style="color:black">Hong, Trudi, could you give me an estimate of the number of vertices in you OR room? And how many of those would be for rigid objects, how many for deformable objects? Are you satisfied with those numbers or would
you expect to be able to do more, and if yes how much? <u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Nick, Sreekanth: right now VTK runs at 60fps with 110k vertices deforming if there is no normals computed by VTK itself. Add the normals computation and you go down 8fps. So we want to improve the data streaming
so that we can do more than 110k vertices (any idea of a reasonable number which would because our target?), but also we will need work on the normals computation, or do this ourselves outside of the rendering thread.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Thank you,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><br clear="all">
<u></u><u></u></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt;color:#888888">Alexis Girault<br>
R&D Engineer in Medical Computing<br>
Kitware, Inc.<br>
<br>
</span><span style="color:black"><a href="http://www.kitware.com/" target="_blank"><span style="font-size:9.5pt;color:#1155cc">http://www.kitware.com</span></a></span><span style="font-size:9.5pt;color:#888888"><br>
</span><span style="color:#999999"><a href="tel:(919)+969-6990+x325" target="_blank"><span style="font-size:9.5pt">(919) 969-6990 x3</span>25</a></span><span style="color:black"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"><br>
______________________________<wbr>_________________<br>
Imstk-developers mailing list<br>
<a href="mailto:Imstk-developers@imstk.org" target="_blank">Imstk-developers@imstk.org</a><br>
<a href="http://public.kitware.com/mailman/listinfo/imstk-developers" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/imstk-developers</a><u></u><u></u></span></p>
</blockquote>
</div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div></div></div>
</div>
</div>
</div>
</blockquote></div><br></div>