[Imstk-developers] Number of vertices in OR room

[Alexis Girault]

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/20161214/1832a6b9/attachment.html>