From milefn at rpi.edu  Thu Dec  1 20:01:54 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 2 Dec 2016 01:01:54 +0000
Subject: [Imstk-developers] Rendering interpolation/extrapolation
In-Reply-To: <CAJFrbFLwVr7CtYATed5+1su7bKdxLBP3L7RC9iwiAqRNMgFLTg@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E3094F2006F@ex14mb4.win.rpi.edu>
 <CAG1Y6mABreP=dXGP2oqzAH_gCSy1ERL32Kv6P8uXqLK9U_QrJw@mail.gmail.com>,
 <CAJFrbFLwVr7CtYATed5+1su7bKdxLBP3L7RC9iwiAqRNMgFLTg@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E3094F208A3@ex14mb4.win.rpi.edu>

Ok, so I did some more digging around, and I found this article with some useful animations:
http://gafferongames.com/networked-physics/snapshots-and-interpolation/

If you look at the last animation, it shows what happens when you use extrapolation vs. interpolation (for networking, but it's the same idea). I think interpolation makes sense for our application based on these results. I think that extrapolation is mainly used for animation and character movement in games.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Tuesday, November 29, 2016 12:38 PM
To: Alexis Girault
Cc: Milef, Nicholas Boris; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Rendering interpolation/extrapolation

Hi Alexis, Nick,
                 In our case i think the first thing we should do, which is easy, is to make the time step dT used by the physics module adaptive. It should be the set to the delta T that is measured in terms of the wall clock time between two successive physics solves. Once this is done we encounter the problem that Nick had mentioned.

In that case:

  1.  If the lowest frame rate amongst all of physics objects is more than 30 Hz then we shouldn't observe much of a difference (unless we are dealing with haptics).
  2.  If the lowest frame rate amongst all of physics objects is less than 30 Hz then we will observe something like stop motion animation. In that case we need to probably use one of the options suggested from the link: extrapolation or interpolation. Extrapolation might work if there is no sudden and drastic change in direction of motion of parts of the scene else you will see artifacts. If we choose interpolation, then i think we are forced to lag by one time step and also choose the linear interpolation constant (slope) adaptively. This could work but I myself have never tried this. One problem I see is that if the frame rates are really low like 4fps then if the user tries to interact with the objects, they will observe the lag of one time step enforced by the method. If it is not interactive it should be fine I guess.

Implementation wise adaptive time step and interpolation/extrapolation should not be very difficult. Its a good discussion to have. Let me know what you guys think.

Thanks.



On Tue, Nov 29, 2016 at 11:39 AM, Alexis Girault <alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>> wrote:
Sreekanth, what's your take on our possible update rate for the physics modules?

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 Tue, Nov 29, 2016 at 11:02 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
How are we handling different update rates from the physics modules in the rendering? I imagine this will be a pretty severe problem for physics modules with low update rates.

http://gamedev.stackexchange.com/questions/12754/how-to-interpolate-between-two-game-states

_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<mailto:Imstk-developers at imstk.org>
http://public.kitware.com/mailman/listinfo/imstk-developers



_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<mailto:Imstk-developers at imstk.org>
http://public.kitware.com/mailman/listinfo/imstk-developers




--
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc.<http://www.kitware.com>, Carrboro, NC.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161202/24f87886/attachment.html>

From sreekanth.arikatla at kitware.com  Thu Dec  1 20:20:11 2016
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Thu, 1 Dec 2016 20:20:11 -0500
Subject: [Imstk-developers] Rendering interpolation/extrapolation
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E3094F208A3@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E3094F2006F@ex14mb4.win.rpi.edu>
 <CAG1Y6mABreP=dXGP2oqzAH_gCSy1ERL32Kv6P8uXqLK9U_QrJw@mail.gmail.com>
 <CAJFrbFLwVr7CtYATed5+1su7bKdxLBP3L7RC9iwiAqRNMgFLTg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E3094F208A3@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFLeK4wm+QpaTRgUgDaQ544qSWp-ATDfzWULC8e=Umv97Q@mail.gmail.com>

Hi Nick,
            Great article. good to know that Hermite can eliminate some
artifacts of linear interpolation. This could definitely be considered for
iMSTK. Thanks.

On Thu, Dec 1, 2016 at 8:01 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Ok, so I did some more digging around, and I found this article with some
> useful animations:
> http://gafferongames.com/networked-physics/snapshots-and-interpolation/
>
> If you look at the last animation, it shows what happens when you use
> extrapolation vs. interpolation (for networking, but it's the same idea). I
> think interpolation makes sense for our application based on these results.
> I think that extrapolation is mainly used for animation and character
> movement in games.
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Tuesday, November 29, 2016 12:38 PM
> *To:* Alexis Girault
> *Cc:* Milef, Nicholas Boris; imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Rendering interpolation/extrapolation
>
> Hi Alexis, Nick,
>                  In our case i think the first thing we should do, which
> is easy, is to make the time step dT used by the physics module adaptive.
> It should be the set to the delta T that is measured in terms of the wall
> clock time between two successive physics solves. Once this is done we
> encounter the problem that Nick had mentioned.
>
> In that case:
>
>    1. If the lowest frame rate amongst all of physics objects is more
>    than 30 Hz then we shouldn't observe much of a difference (unless we are
>    dealing with haptics).
>    2. If the lowest frame rate amongst all of physics objects is less
>    than 30 Hz then we will observe something like stop motion animation. In
>    that case we need to probably use one of the options suggested from the
>    link: extrapolation or interpolation. Extrapolation might work if there is
>    no sudden and drastic change in direction of motion of parts of the scene
>    else you will see artifacts. If we choose interpolation, then i think we
>    are forced to lag by one time step and also choose the linear interpolation
>    constant (slope) adaptively. This could work but I myself have never tried
>    this. One problem I see is that if the frame rates are really low like 4fps
>    then if the user tries to interact with the objects, they will observe the
>    lag of one time step enforced by the method. If it is not interactive it
>    should be fine I guess.
>
> Implementation wise adaptive time step and interpolation/extrapolation
> should not be very difficult. Its a good discussion to have. Let me know
> what you guys think.
>
> Thanks.
>
>
>
> On Tue, Nov 29, 2016 at 11:39 AM, Alexis Girault <
> alexis.girault at kitware.com> wrote:
>
>> Sreekanth, what's your take on our possible update rate for the physics
>> modules?
>>
>> Alexis Girault
>> R&D Engineer in Medical Computing
>> Kitware, Inc.
>>
>> http://www.kitware.com
>> (919) 969-6990 x325
>>
>> On Tue, Nov 29, 2016 at 11:02 AM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> How are we handling different update rates from the physics modules in
>>> the rendering? I imagine this will be a pretty severe problem for physics
>>> modules with low update rates.
>>>
>>> http://gamedev.stackexchange.com/questions/12754/how-to-inte
>>> rpolate-between-two-game-states
>>>
>>> _______________________________________________
>>> Imstk-developers mailing list
>>> Imstk-developers at imstk.org
>>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>>
>>>
>>
>> _______________________________________________
>> Imstk-developers mailing list
>> Imstk-developers at imstk.org
>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>
>>
>
>
> --
> Sreekanth Arikatla, Ph.D,
> Senior R&D Engineer,
> Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
>
>


-- 
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161201/159df939/attachment-0001.html>

From milefn at rpi.edu  Tue Dec  6 18:58:48 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Tue, 6 Dec 2016 23:58:48 +0000
Subject: [Imstk-developers] Mesh classes are friends with VTK classes
Message-ID: <C745C1E748CE104AA373B656E0EF5E309A8DA316@ex14mb4.win.rpi.edu>

What should we do about this? Should I friend Vulkan classes as well and use a preprocessor command or forward declare? Or should we just make the data public?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161206/68025b54/attachment.html>

From alexis.girault at kitware.com  Wed Dec  7 17:35:50 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Wed, 7 Dec 2016 17:35:50 -0500
Subject: [Imstk-developers] Mesh classes are friends with VTK classes
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E309A8DA316@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E309A8DA316@ex14mb4.win.rpi.edu>
Message-ID: <CAG1Y6mB9p0S1Er+gu4hi0Bjj0a7OgpfgdC1C-5ovPhTJ1JB9Ew@mail.gmail.com>

Let's discuss it at our meeting tomorrow.

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

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

On Tue, Dec 6, 2016 at 6:58 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> What should we do about this? Should I friend Vulkan classes as well and
> use a preprocessor command or forward declare? Or should we just make the
> data public?
>
> _______________________________________________
> 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/20161207/18cd04e9/attachment.html>

From milefn at rpi.edu  Sat Dec 10 16:49:20 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Sat, 10 Dec 2016 21:49:20 +0000
Subject: [Imstk-developers] Spatial hashing
Message-ID: <C745C1E748CE104AA373B656E0EF5E309A8DA633@ex14mb4.win.rpi.edu>

Do we have any spatial hashing data structures?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161210/8d0bcc58/attachment.html>

From sreekanth.arikatla at kitware.com  Sat Dec 10 16:52:16 2016
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Sat, 10 Dec 2016 16:52:16 -0500
Subject: [Imstk-developers] Spatial hashing
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E309A8DA633@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E309A8DA633@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFLC89rCSJNnbAVtX4fuXhqPcgEgAvUd_uMHmQFTzocf_g@mail.gmail.com>

Not in iMSTK as of now. But we have plans to incorporate Tansel's spatial
hashing based collision detection from simmedtk.

On Sat, Dec 10, 2016 at 4:49 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Do we have any spatial hashing data structures?
>
> _______________________________________________
> Imstk-developers mailing list
> Imstk-developers at imstk.org
> http://public.kitware.com/mailman/listinfo/imstk-developers
>
>


-- 
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161210/f8a7277c/attachment.html>

From andinet.enqu at kitware.com  Sun Dec 11 09:45:25 2016
From: andinet.enqu at kitware.com (Andinet Enquobahrie)
Date: Sun, 11 Dec 2016 09:45:25 -0500
Subject: [Imstk-developers] Spatial hashing
In-Reply-To: <CAJFrbFLC89rCSJNnbAVtX4fuXhqPcgEgAvUd_uMHmQFTzocf_g@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E309A8DA633@ex14mb4.win.rpi.edu>
 <CAJFrbFLC89rCSJNnbAVtX4fuXhqPcgEgAvUd_uMHmQFTzocf_g@mail.gmail.com>
Message-ID: <CANrU598yxhmLT2SHmNzQUQyVGYphMp8NHVeoRpGJ3=hw6duOPg@mail.gmail.com>

On Sat, Dec 10, 2016 at 4:52 PM, Sreekanth Arikatla <
sreekanth.arikatla at kitware.com> wrote:

> Not in iMSTK as of now. But we have plans to incorporate Tansel's spatial
> hashing based collision detection from simmedtk.
>

Can you add this to the issue tracker?

we could look into using hash table data structure implementations in VTK


>
> On Sat, Dec 10, 2016 at 4:49 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Do we have any spatial hashing data structures?
>>
>> _______________________________________________
>> Imstk-developers mailing list
>> Imstk-developers at imstk.org
>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>
>>
>
>
> --
> Sreekanth Arikatla, Ph.D,
> Senior R&D Engineer,
> Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
>
>
> _______________________________________________
> Imstk-developers mailing list
> Imstk-developers at imstk.org
> http://public.kitware.com/mailman/listinfo/imstk-developers
>
>


-- 
Andinet Enquobahrie, Ph.D., MBA
Assistant Director of Medical Computing
Kitware, Inc.

http://www.kitware.com
(919) 969-6990 x311 <%28919%29%20969-6990%20x311>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161211/7eec9459/attachment.html>

From milefn at rpi.edu  Sun Dec 11 16:19:23 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Sun, 11 Dec 2016 21:19:23 +0000
Subject: [Imstk-developers] Spatial hashing
In-Reply-To: <CANrU598yxhmLT2SHmNzQUQyVGYphMp8NHVeoRpGJ3=hw6duOPg@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E309A8DA633@ex14mb4.win.rpi.edu>
 <CAJFrbFLC89rCSJNnbAVtX4fuXhqPcgEgAvUd_uMHmQFTzocf_g@mail.gmail.com>,
 <CANrU598yxhmLT2SHmNzQUQyVGYphMp8NHVeoRpGJ3=hw6duOPg@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E309A8DA6BC@ex14mb4.win.rpi.edu>

Added as an issue. I couldn't find any spatial hashing classes (or just general purpose hash tables) inside of VTK, but VTK is large so it's quite possible I missed it.

We probably should have multiple implementations for spatial hashing, one for dense, preferably bounded locations (but wrap around in case data values exceed this grid) and one for sparse locations.
________________________________
From: Andinet Enquobahrie [andinet.enqu at kitware.com]
Sent: Sunday, December 11, 2016 9:45 AM
To: Sreekanth Arikatla
Cc: Milef, Nicholas Boris; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Spatial hashing


On Sat, Dec 10, 2016 at 4:52 PM, Sreekanth Arikatla <sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>> wrote:
Not in iMSTK as of now. But we have plans to incorporate Tansel's spatial hashing based collision detection from simmedtk.

Can you add this to the issue tracker?

we could look into using hash table data structure implementations in VTK


On Sat, Dec 10, 2016 at 4:49 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Do we have any spatial hashing data structures?

_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<mailto:Imstk-developers at imstk.org>
http://public.kitware.com/mailman/listinfo/imstk-developers




--
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc.<http://www.kitware.com>, Carrboro, NC.


_______________________________________________
Imstk-developers mailing list
Imstk-developers at imstk.org<mailto:Imstk-developers at imstk.org>
http://public.kitware.com/mailman/listinfo/imstk-developers




--
Andinet Enquobahrie, Ph.D., MBA
Assistant Director of Medical Computing
Kitware, Inc.

http://www.kitware.com
(919) 969-6990 x311<tel:%28919%29%20969-6990%20x311>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161211/875bb44c/attachment.html>

From alexis.girault at kitware.com  Mon Dec 12 14:20:08 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Mon, 12 Dec 2016 14:20:08 -0500
Subject: [Imstk-developers] Number of vertices in OR room
Message-ID: <CAG1Y6mBHBWfR=L6a7nxuCCkpgQFD+7MKxyU-7qMupVbi_jqbmA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161212/90a77e1d/attachment.html>

From hongli03129 at gmail.com  Mon Dec 12 16:03:34 2016
From: hongli03129 at gmail.com (Hong Li)
Date: Mon, 12 Dec 2016 16:03:34 -0500
Subject: [Imstk-developers] Number of vertices in OR room
In-Reply-To: <CAG1Y6mBHBWfR=L6a7nxuCCkpgQFD+7MKxyU-7qMupVbi_jqbmA@mail.gmail.com>
References: <CAG1Y6mBHBWfR=L6a7nxuCCkpgQFD+7MKxyU-7qMupVbi_jqbmA@mail.gmail.com>
Message-ID: <CAMB8zNXnzyx8Fu1247T0p9ALUZnyw_mOc9NddnLSB9JwnXdATw@mail.gmail.com>

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/20161212/808196ab/attachment.html>

From milefn at rpi.edu  Mon Dec 12 16:42:46 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 12 Dec 2016 21:42:46 +0000
Subject: [Imstk-developers] Number of vertices in OR room
In-Reply-To: <CAMB8zNXnzyx8Fu1247T0p9ALUZnyw_mOc9NddnLSB9JwnXdATw@mail.gmail.com>
References: <CAG1Y6mBHBWfR=L6a7nxuCCkpgQFD+7MKxyU-7qMupVbi_jqbmA@mail.gmail.com>,
 <CAMB8zNXnzyx8Fu1247T0p9ALUZnyw_mOc9NddnLSB9JwnXdATw@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E309A8DA83B@ex14mb4.win.rpi.edu>

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<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/20161212/ab1b294e/attachment.html>

From qid at rpi.edu  Mon Dec 12 17:30:55 2016
From: qid at rpi.edu (Qi, Trudi)
Date: Mon, 12 Dec 2016 22:30:55 +0000
Subject: [Imstk-developers] Number of vertices in OR room
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E309A8DA83B@ex14mb4.win.rpi.edu>
References: <CAG1Y6mBHBWfR=L6a7nxuCCkpgQFD+7MKxyU-7qMupVbi_jqbmA@mail.gmail.com>, 
 <CAMB8zNXnzyx8Fu1247T0p9ALUZnyw_mOc9NddnLSB9JwnXdATw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E309A8DA83B@ex14mb4.win.rpi.edu>
Message-ID: <C69A266DADAF4849B6860DFC9D044485B1E7C8@EX14MB6.win.rpi.edu>

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<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/20161212/da977899/attachment-0001.html>

From alexis.girault at kitware.com  Wed Dec 14 11:01:06 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Wed, 14 Dec 2016 11:01:06 -0500
Subject: [Imstk-developers] Number of vertices in OR room
In-Reply-To: <C69A266DADAF4849B6860DFC9D044485B1E7C8@EX14MB6.win.rpi.edu>
References: <CAG1Y6mBHBWfR=L6a7nxuCCkpgQFD+7MKxyU-7qMupVbi_jqbmA@mail.gmail.com>
 <CAMB8zNXnzyx8Fu1247T0p9ALUZnyw_mOc9NddnLSB9JwnXdATw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E309A8DA83B@ex14mb4.win.rpi.edu>
 <C69A266DADAF4849B6860DFC9D044485B1E7C8@EX14MB6.win.rpi.edu>
Message-ID: <CAG1Y6mC=sKnMsTUd34HKFYk4dOWVY+KqvJ_NQThMkcQd+em5cg@mail.gmail.com>

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>

From milefn at rpi.edu  Wed Dec 14 11:50:16 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Wed, 14 Dec 2016 16:50:16 +0000
Subject: [Imstk-developers] Number of vertices in OR room
In-Reply-To: <CAG1Y6mC=sKnMsTUd34HKFYk4dOWVY+KqvJ_NQThMkcQd+em5cg@mail.gmail.com>
References: <CAG1Y6mBHBWfR=L6a7nxuCCkpgQFD+7MKxyU-7qMupVbi_jqbmA@mail.gmail.com>
 <CAMB8zNXnzyx8Fu1247T0p9ALUZnyw_mOc9NddnLSB9JwnXdATw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E309A8DA83B@ex14mb4.win.rpi.edu>
 <C69A266DADAF4849B6860DFC9D044485B1E7C8@EX14MB6.win.rpi.edu>,
 <CAG1Y6mC=sKnMsTUd34HKFYk4dOWVY+KqvJ_NQThMkcQd+em5cg@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E309A8DB1D4@ex14mb4.win.rpi.edu>

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>

From milefn at rpi.edu  Thu Dec 15 21:44:03 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 16 Dec 2016 02:44:03 +0000
Subject: [Imstk-developers] Assimp integration
Message-ID: <C745C1E748CE104AA373B656E0EF5E309A8DB2E4@ex14mb4.win.rpi.edu>

How should we proceed with this? It seems that there's someone interested in the VTK version. I'll need it for the Vulkan renderer to test out various things. And we'll need models that support vertex weights for both renderers.

From alexis.girault at kitware.com  Thu Dec 15 21:54:37 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Fri, 16 Dec 2016 02:54:37 +0000
Subject: [Imstk-developers] Assimp integration
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E309A8DB2E4@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E309A8DB2E4@ex14mb4.win.rpi.edu>
Message-ID: <CAG1Y6mBO_8PecRcYPbNGaCkrRhc3iXWtmDPqebS4TJFU+v7QSw@mail.gmail.com>

Do you think you could do it efficiently in VTK? If yes I'd do so, and
store the vertex weights in the PointData that we could then map it to our
structures.

How did you implement vertex weight in VTK in your previous work?

Alexis

On Thu, Dec 15, 2016, 21:44 Milef, Nicholas Boris <milefn at rpi.edu> wrote:

How should we proceed with this? It seems that there's someone interested
in the VTK version. I'll need it for the Vulkan renderer to test out
various things. And we'll need models that support vertex weights for both
renderers.
_______________________________________________
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/2dfbebbc/attachment.html>

From alexis.girault at kitware.com  Thu Dec 15 22:06:50 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Fri, 16 Dec 2016 03:06:50 +0000
Subject: [Imstk-developers] Assimp integration
In-Reply-To: <CAG1Y6mBO_8PecRcYPbNGaCkrRhc3iXWtmDPqebS4TJFU+v7QSw@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E309A8DB2E4@ex14mb4.win.rpi.edu>
 <CAG1Y6mBO_8PecRcYPbNGaCkrRhc3iXWtmDPqebS4TJFU+v7QSw@mail.gmail.com>
Message-ID: <CAG1Y6mBQfEqVvubWp40mTSDCGoPVmKN8k2ghK=gCWtUBN9xZUw@mail.gmail.com>

Maybe you could send a message again on the vtk developers thread to ask if
a project gatekeeper could tell you how to add a third party dependency to
VTK and if Assimp license works with them. If there is any issue they'll
let us know and we may move on.

On Thu, Dec 15, 2016, 21:54 Alexis Girault <alexis.girault at kitware.com>
wrote:

> Do you think you could do it efficiently in VTK? If yes I'd do so, and
> store the vertex weights in the PointData that we could then map it to our
> structures.
>
> How did you implement vertex weight in VTK in your previous work?
>
> Alexis
>
> On Thu, Dec 15, 2016, 21:44 Milef, Nicholas Boris <milefn at rpi.edu> wrote:
>
> How should we proceed with this? It seems that there's someone interested
> in the VTK version. I'll need it for the Vulkan renderer to test out
> various things. And we'll need models that support vertex weights for both
> renderers.
> _______________________________________________
> 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/1e52b003/attachment.html>

From alexis.girault at kitware.com  Fri Dec 16 23:10:09 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Fri, 16 Dec 2016 23:10:09 -0500
Subject: [Imstk-developers] Number of vertices in OR room
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E309A8DB1D4@ex14mb4.win.rpi.edu>
References: <CAG1Y6mBHBWfR=L6a7nxuCCkpgQFD+7MKxyU-7qMupVbi_jqbmA@mail.gmail.com>
 <CAMB8zNXnzyx8Fu1247T0p9ALUZnyw_mOc9NddnLSB9JwnXdATw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E309A8DA83B@ex14mb4.win.rpi.edu>
 <C69A266DADAF4849B6860DFC9D044485B1E7C8@EX14MB6.win.rpi.edu>
 <CAG1Y6mC=sKnMsTUd34HKFYk4dOWVY+KqvJ_NQThMkcQd+em5cg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E309A8DB1D4@ex14mb4.win.rpi.edu>
Message-ID: <CAG1Y6mDPSc_MzsiXFcq9Maj5+itLaPekBmkXM70Y+UHfTWD7yw@mail.gmail.com>

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>

From alexis.girault at kitware.com  Tue Dec 20 07:02:27 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Tue, 20 Dec 2016 12:02:27 +0000
Subject: [Imstk-developers] A couple new MRs
Message-ID: <CAG1Y6mBkswJt7dggdYTFyy1Y3L2Mm6ejwkqixnHF1U5fEubLZg@mail.gmail.com>

Hi devs,

I have been spending a couple (too many) hours in planes and airports
(still in Dublin currently waiting for my flight to France), so I have had
the opportunity to work on a couple things in iMSTK:

1) Correct warnings:
https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/116
2) Skip compute bounds in VTK to speed up rendering:
https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/115
3) Adapt and rebase Hina work to the camera navigation branch to enable the
use of lambdas for custom event handling in the vtk interactor style,
(design concept that we discussed a little while back) :
https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/117

If you are not yet on holidays you're welcome to review those. If I get
more travel time in my hands I'll look into render details / materials.

@Hina: not sure if you're in the iMSTK developers mailing list. If not, you
can join it here : http://www.imstk.org/mailing-lists/

Best,

Alexis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161220/c40907dd/attachment.html>

From sreekanth.arikatla at kitware.com  Thu Dec 29 11:55:18 2016
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Thu, 29 Dec 2016 11:55:18 -0500
Subject: [Imstk-developers] A couple new MRs
In-Reply-To: <CAG1Y6mBkswJt7dggdYTFyy1Y3L2Mm6ejwkqixnHF1U5fEubLZg@mail.gmail.com>
References: <CAG1Y6mBkswJt7dggdYTFyy1Y3L2Mm6ejwkqixnHF1U5fEubLZg@mail.gmail.com>
Message-ID: <CAJFrbFKjVTLxpd6buWRoAtL7AKL_NrqBDGLSfeJKFw6k3juZ6A@mail.gmail.com>

Hi All,
         I have added another MR to the list. Here is the link:
*https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/118
<https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/118>*

In summary, this MR contains changes that fix all the major outstanding
issues with the physics module in iMSTK. Please see the description in the
link for more details.

It would be great if you guys can review. I'll take a look at some of the
MRs that are waiting for review.

Thanks.

On Tue, Dec 20, 2016 at 7:02 AM, Alexis Girault <alexis.girault at kitware.com>
wrote:

> Hi devs,
>
> I have been spending a couple (too many) hours in planes and airports
> (still in Dublin currently waiting for my flight to France), so I have had
> the opportunity to work on a couple things in iMSTK:
>
> 1) Correct warnings: https://gitlab.kitware.com/
> iMSTK/iMSTK/merge_requests/116
> 2) Skip compute bounds in VTK to speed up rendering:
> https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/115
> 3) Adapt and rebase Hina work to the camera navigation branch to enable
> the use of lambdas for custom event handling in the vtk interactor style,
> (design concept that we discussed a little while back) :
> https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/117
>
> If you are not yet on holidays you're welcome to review those. If I get
> more travel time in my hands I'll look into render details / materials.
>
> @Hina: not sure if you're in the iMSTK developers mailing list. If not,
> you can join it here : http://www.imstk.org/mailing-lists/
>
> Best,
>
> Alexis
>
> _______________________________________________
> Imstk-developers mailing list
> Imstk-developers at imstk.org
> http://public.kitware.com/mailman/listinfo/imstk-developers
>
>


-- 
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161229/436fd339/attachment.html>

From alexis.girault at kitware.com  Thu Dec 29 19:02:12 2016
From: alexis.girault at kitware.com (Alexis Girault)
Date: Fri, 30 Dec 2016 00:02:12 +0000
Subject: [Imstk-developers] A couple new MRs
In-Reply-To: <CAJFrbFKjVTLxpd6buWRoAtL7AKL_NrqBDGLSfeJKFw6k3juZ6A@mail.gmail.com>
References: <CAG1Y6mBkswJt7dggdYTFyy1Y3L2Mm6ejwkqixnHF1U5fEubLZg@mail.gmail.com>
 <CAJFrbFKjVTLxpd6buWRoAtL7AKL_NrqBDGLSfeJKFw6k3juZ6A@mail.gmail.com>
Message-ID: <CAG1Y6mDg7vK+Bqqt_2z=PdBvpm_=kydZzkwFWGCLOHNKxtAq2Q@mail.gmail.com>

Great, thanks! Will review on my way back.

Alexis

On Thu, Dec 29, 2016, 17:55 Sreekanth Arikatla <
sreekanth.arikatla at kitware.com> wrote:

> Hi All,
>          I have added another MR to the list. Here is the link: *https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/118
> <https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/118>*
>
> In summary, this MR contains changes that fix all the major outstanding
> issues with the physics module in iMSTK. Please see the description in the
> link for more details.
>
> It would be great if you guys can review. I'll take a look at some of the
> MRs that are waiting for review.
>
> Thanks.
>
> On Tue, Dec 20, 2016 at 7:02 AM, Alexis Girault <
> alexis.girault at kitware.com> wrote:
>
> Hi devs,
>
> I have been spending a couple (too many) hours in planes and airports
> (still in Dublin currently waiting for my flight to France), so I have had
> the opportunity to work on a couple things in iMSTK:
>
> 1) Correct warnings:
> https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/116
> 2) Skip compute bounds in VTK to speed up rendering:
> https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/115
> 3) Adapt and rebase Hina work to the camera navigation branch to enable
> the use of lambdas for custom event handling in the vtk interactor style,
> (design concept that we discussed a little while back) :
> https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/117
>
> If you are not yet on holidays you're welcome to review those. If I get
> more travel time in my hands I'll look into render details / materials.
>
> @Hina: not sure if you're in the iMSTK developers mailing list. If not,
> you can join it here : http://www.imstk.org/mailing-lists/
>
> Best,
>
> Alexis
>
> _______________________________________________
> Imstk-developers mailing list
> Imstk-developers at imstk.org
> http://public.kitware.com/mailman/listinfo/imstk-developers
>
>
>
>
> --
> Sreekanth Arikatla, Ph.D,
> Senior R&D Engineer,
> Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161230/7e917b70/attachment.html>

From sreekanth.arikatla at kitware.com  Sat Dec 31 21:35:05 2016
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Sat, 31 Dec 2016 21:35:05 -0500
Subject: [Imstk-developers] A couple new MRs
In-Reply-To: <CAG1Y6mDg7vK+Bqqt_2z=PdBvpm_=kydZzkwFWGCLOHNKxtAq2Q@mail.gmail.com>
References: <CAG1Y6mBkswJt7dggdYTFyy1Y3L2Mm6ejwkqixnHF1U5fEubLZg@mail.gmail.com>
 <CAJFrbFKjVTLxpd6buWRoAtL7AKL_NrqBDGLSfeJKFw6k3juZ6A@mail.gmail.com>
 <CAG1Y6mDg7vK+Bqqt_2z=PdBvpm_=kydZzkwFWGCLOHNKxtAq2Q@mail.gmail.com>
Message-ID: <CAJFrbFJhrjxzzN5uC6voO0HJsywEJhjR0cKZTBPUUfSSTN8MXQ@mail.gmail.com>

Hi All,
         One more: https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/119

This MR adds laparoscopic tool controller required for the liver-tool
interaction example that I'm trying to get up and running soon. It would be
great if one of you guys can review. Thanks,

On Thu, Dec 29, 2016 at 7:02 PM, Alexis Girault <alexis.girault at kitware.com>
wrote:

> Great, thanks! Will review on my way back.
>
> Alexis
>
> On Thu, Dec 29, 2016, 17:55 Sreekanth Arikatla <
> sreekanth.arikatla at kitware.com> wrote:
>
>> Hi All,
>>          I have added another MR to the list. Here is the link: *https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/118
>> <https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/118>*
>>
>> In summary, this MR contains changes that fix all the major outstanding
>> issues with the physics module in iMSTK. Please see the description in the
>> link for more details.
>>
>> It would be great if you guys can review. I'll take a look at some of the
>> MRs that are waiting for review.
>>
>> Thanks.
>>
>> On Tue, Dec 20, 2016 at 7:02 AM, Alexis Girault <
>> alexis.girault at kitware.com> wrote:
>>
>> Hi devs,
>>
>> I have been spending a couple (too many) hours in planes and airports
>> (still in Dublin currently waiting for my flight to France), so I have had
>> the opportunity to work on a couple things in iMSTK:
>>
>> 1) Correct warnings: https://gitlab.kitware.com/
>> iMSTK/iMSTK/merge_requests/116
>> 2) Skip compute bounds in VTK to speed up rendering:
>> https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/115
>> 3) Adapt and rebase Hina work to the camera navigation branch to enable
>> the use of lambdas for custom event handling in the vtk interactor style,
>> (design concept that we discussed a little while back) :
>> https://gitlab.kitware.com/iMSTK/iMSTK/merge_requests/117
>>
>> If you are not yet on holidays you're welcome to review those. If I get
>> more travel time in my hands I'll look into render details / materials.
>>
>> @Hina: not sure if you're in the iMSTK developers mailing list. If not,
>> you can join it here : http://www.imstk.org/mailing-lists/
>>
>> Best,
>>
>> Alexis
>>
>> _______________________________________________
>> Imstk-developers mailing list
>> Imstk-developers at imstk.org
>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>
>>
>>
>>
>> --
>> Sreekanth Arikatla, Ph.D,
>> Senior R&D Engineer,
>> Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
>>
>>


-- 
Sreekanth Arikatla, Ph.D,
Senior R&D Engineer,
Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20161231/cc3c92c6/attachment.html>