[Imstk-developers] Number of vertices in OR room

Wed Dec 14 11:50:16 EST 2016

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<http://www.kitware.com/>
(919) 969-6990 x325<tel:(919)+969-6990+x325>

On Mon, Dec 12, 2016 at 5:30 PM, Qi, Trudi <qid at rpi.edu<mailto: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<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<mailto:hongli03129 at gmail.com>>; Alexis Girault <alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>>

Cc: imstk-developers at imstk.org<mailto: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<mailto:imstk-developers-bounces at imstk.org>] on behalf of Hong Li [hongli03129 at gmail.com<mailto:hongli03129 at gmail.com>]
Sent: Monday, December 12, 2016 4:03 PM
To: Alexis Girault
Cc: imstk-developers at imstk.org<mailto: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<mailto: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<http://www.kitware.com/>
(919) 969-6990 x325<tel:(919)+969-6990+x325>

_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<mailto: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/d5cf8d51/attachment-0001.html>