[Imstk-developers] Number of vertices in OR room

Fri Dec 16 23:10:09 EST 2016

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:
https://gitlab.kitware.com/vtk/vtk/merge_requests/2269

Other good news: we're now up to 190 fps for the same 110k with vertices
guys :)
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:

- Skip frustrum culling

renderer->RemoveCuller(renderer->GetCullers()->GetLastItem());

- Skip auto shift & scale of VBO

openglmapper->SetVBOShiftScaleMethod(vtkOpenGLVertexBufferObject::DISABLE_SHIFT_SCALE);

Those two changes allow to bypass `GetBounds()`, which needed to recompute
the bounds at each frame since we were deforming our meshes.

So... no streaming in the vbos yet, but with 190 fps for 110k vertices with
normals, we're doing pretty good now with VTK!
See here for MR: https://gitlab.kitware.com/vtk/vtk/merge_requests/2271

I'll leave to France that Monday and will be back on January 2nd.

Best,

Alexis Girault
R&D Engineer in Medical Computing
Kitware, Inc.

http://www.kitware.com
(919) 969-6990 x325

On Wed, Dec 14, 2016 at 11:50 AM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Nice work! Those are some much better numbers!
>
> 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.
>
> 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:
> https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch42.html
>
> 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.
> ------------------------------
> *From:* Alexis Girault [alexis.girault at kitware.com]
> *Sent:* Wednesday, December 14, 2016 11:01 AM
> *To:* Qi, Trudi
> *Cc:* Milef, Nicholas Boris; Hong Li; imstk-developers at imstk.org
>
> *Subject:* Re: [Imstk-developers] Number of vertices in OR room
>
> Thanks guys for your answers!
>
> 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.
>
> 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?
>
> On another point, the changes to avoid rebuilding the shaders too many
> times (ex: transformations of the actor) is in VTK upstream:
> https://gitlab.kitware.com/vtk/vtk/merge_requests/2222/diffs
> 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.
>
> I'll keep you up-to-date on the next improvements for VTK in real-time.
>
> Best,
>
>
> Alexis Girault
> R&D Engineer in Medical Computing
> Kitware, Inc.
>
> http://www.kitware.com
> (919) 969-6990 x325
>
> On Mon, Dec 12, 2016 at 5:30 PM, Qi, Trudi <qid at rpi.edu> wrote:
>
>> Hi Alexis,
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> Thanks,
>>
>> Trudi
>>
>>
>>
>> *From:* Imstk-developers [mailto:imstk-developers-bounces at imstk.org] *On
>> Behalf Of *Milef, Nicholas Boris
>> *Sent:* Monday, December 12, 2016 4:43 PM
>> *To:* Hong Li <hongli03129 at gmail.com>; Alexis Girault <
>> alexis.girault at kitware.com>
>>
>> *Cc:* imstk-developers at imstk.org
>> *Subject:* Re: [Imstk-developers] Number of vertices in OR room
>>
>>
>>
>> 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?
>>
>>
>>
>> 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.
>> ------------------------------
>>
>> *From:* Imstk-developers [imstk-developers-bounces at imstk.org] on behalf
>> of Hong Li [hongli03129 at gmail.com]
>> *Sent:* Monday, December 12, 2016 4:03 PM
>> *To:* Alexis Girault
>> *Cc:* imstk-developers at imstk.org
>> *Subject:* Re: [Imstk-developers] Number of vertices in OR room
>>
>> 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.
>>
>> I'm not sure if the VERY high resolution mesh for objects like tools and
>> teeth are really necessary.
>>
>>
>>
>> Hong
>>
>>
>>
>> On Mon, Dec 12, 2016 at 2:20 PM, Alexis Girault <
>> alexis.girault at kitware.com> wrote:
>>
>> 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?
>>
>>
>>
>> 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.
>>
>>
>>
>> Thank you,
>>
>>
>> Alexis Girault
>> R&D Engineer in Medical Computing
>> Kitware, Inc.
>>
>> http://www.kitware.com
>> (919) 969-6990 x325
>>
>>
>> _______________________________________________
>> Imstk-developers mailing list
>> Imstk-developers at imstk.org
>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161216/1bddb310/attachment.html>