From milefn at rpi.edu  Tue Sep  5 12:58:57 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Tue, 5 Sep 2017 16:58:57 +0000
Subject: [Imstk-developers] Squashing many commits
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AE7AD@ex14mb4.win.rpi.edu>

What's the recommended way to squash a few dozen commits? Somehow, the branch I was working on expands the commits when I rebase (I only see 4 commits on my local repo, but when I rebase these 4, they expand to about 40), so I need a fast way to squash them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170905/b83a1c06/attachment.html>

From milefn at rpi.edu  Mon Sep 18 10:52:14 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 18 Sep 2017 14:52:14 +0000
Subject: [Imstk-developers] Multiple materials per import
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>

This question has a subtle difference compared to a previous question I asked before, but should we add support for mesh files with multiple materials?

When the mesh gets imported, the regions with a different material would get split into a new mesh. Or should we introduce a new primitive such as a MeshGroup to handle this? Or should we keep them as separate, unrelated meshes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170918/4a1e4ed6/attachment.html>

From sreekanth.arikatla at kitware.com  Mon Sep 18 11:03:34 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Mon, 18 Sep 2017 11:03:34 -0400
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>

Having mesh split and maintained as separate pieces might complicate
imstk's geometry mappers. Do you have a use case from one of the projects?

On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> This question has a subtle difference compared to a previous question I
> asked before, but should we add support for mesh files with multiple
> materials?
>
> When the mesh gets imported, the regions with a different material would
> get split into a new mesh. Or should we introduce a new primitive such as a
> MeshGroup to handle this? Or should we keep them as separate, unrelated
> meshes?
>
> _______________________________________________
> 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/20170918/ae451f1c/attachment.html>

From milefn at rpi.edu  Mon Sep 18 11:39:56 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 18 Sep 2017 15:39:56 +0000
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>,
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>

Yes, it's very common to have this functionality, and many meshes we have use this. Currently, I have to individually export each material as a separate mesh, but this gets tedious when you end up with hundreds of meshes and have to separate/export each one individually. Also, managing these is a pain. Note that a single face can only have one material assigned to it (i.e., not layered materials).

We still don't have the scene graph, but what if we introduce one and then when you import a mesh it adds a new node (called MeshGroup) under root (the scene) and then nodes (meshes) under the MeshGroup? Or it could be called MeshObject or something, etc.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Monday, September 18, 2017 11:03 AM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Multiple materials per import

Having mesh split and maintained as separate pieces might complicate imstk's geometry mappers. Do you have a use case from one of the projects?

On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
This question has a subtle difference compared to a previous question I asked before, but should we add support for mesh files with multiple materials?

When the mesh gets imported, the regions with a different material would get split into a new mesh. Or should we introduce a new primitive such as a MeshGroup to handle this? Or should we keep them as separate, unrelated meshes?

_______________________________________________
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/20170918/8a9baf3c/attachment.html>

From andinet.enqu at kitware.com  Mon Sep 18 12:09:02 2017
From: andinet.enqu at kitware.com (Andinet Enquobahrie)
Date: Mon, 18 Sep 2017 12:09:02 -0400
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
Message-ID: <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>

I would think we will need a scene graph support at some point in iMSTK

For example,

https://www.sofa-framework.org/community/doc/main-principles/scene-graph/

On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Yes, it's very common to have this functionality, and many meshes we have
> use this. Currently, I have to individually export each material as a
> separate mesh, but this gets tedious when you end up with hundreds of
> meshes and have to separate/export each one individually. Also, managing
> these is a pain. Note that a single face can only have one material
> assigned to it (i.e., not layered materials).
>
> We still don't have the scene graph, but what if we introduce one and then
> when you import a mesh it adds a new node (called MeshGroup) under root
> (the scene) and then nodes (meshes) under the MeshGroup? Or it could be
> called MeshObject or something, etc.
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Monday, September 18, 2017 11:03 AM
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Multiple materials per import
>
> Having mesh split and maintained as separate pieces might complicate
> imstk's geometry mappers. Do you have a use case from one of the projects?
>
> On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> This question has a subtle difference compared to a previous question I
>> asked before, but should we add support for mesh files with multiple
>> materials?
>>
>> When the mesh gets imported, the regions with a different material would
>> get split into a new mesh. Or should we introduce a new primitive such as a
>> MeshGroup to handle this? Or should we keep them as separate, unrelated
>> meshes?
>>
>> _______________________________________________
>> 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
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/20170918/f55139da/attachment.html>

From alexis.girault at kitware.com  Mon Sep 25 11:01:03 2017
From: alexis.girault at kitware.com (Alexis Girault)
Date: Mon, 25 Sep 2017 11:01:03 -0400
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
Message-ID: <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>

We wouldn't want to confuse geometries (mesh, etc...) with objects (scene
object), which would be part of a scene graph when the needs come.

Sreekanth: wouldn't creating multiple meshes for a unique object be a
problem to handle physics?

Nick: do we need to dissociate meshes per material? Could we retain a
unique mesh and associate materials to a specific set of points/cells? I am
remembering of the multi-texture support in VTK, where I had two sets of
texture coordinates which allowed me to combine two textures at different
parts of a unique mesh.

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

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

On Mon, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <
andinet.enqu at kitware.com> wrote:

> I would think we will need a scene graph support at some point in iMSTK
>
> For example,
>
> https://www.sofa-framework.org/community/doc/main-principles/scene-graph/
>
> On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Yes, it's very common to have this functionality, and many meshes we have
>> use this. Currently, I have to individually export each material as a
>> separate mesh, but this gets tedious when you end up with hundreds of
>> meshes and have to separate/export each one individually. Also, managing
>> these is a pain. Note that a single face can only have one material
>> assigned to it (i.e., not layered materials).
>>
>> We still don't have the scene graph, but what if we introduce one and
>> then when you import a mesh it adds a new node (called MeshGroup) under
>> root (the scene) and then nodes (meshes) under the MeshGroup? Or it could
>> be called MeshObject or something, etc.
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Monday, September 18, 2017 11:03 AM
>> *To:* Milef, Nicholas Boris
>> *Cc:* imstk-developers at imstk.org
>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>
>> Having mesh split and maintained as separate pieces might complicate
>> imstk's geometry mappers. Do you have a use case from one of the projects?
>>
>> On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> This question has a subtle difference compared to a previous question I
>>> asked before, but should we add support for mesh files with multiple
>>> materials?
>>>
>>> When the mesh gets imported, the regions with a different material would
>>> get split into a new mesh. Or should we introduce a new primitive such as a
>>> MeshGroup to handle this? Or should we keep them as separate, unrelated
>>> meshes?
>>>
>>> _______________________________________________
>>> 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
> Director of Medical Computing
> Kitware, Inc.
>
> http://www.kitware.com
> (919) 969-6990 x311 <%28919%29%20969-6990%20x311>
>
>
>
>
> _______________________________________________
> 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/20170925/8de71cf7/attachment.html>

From sreekanth.arikatla at kitware.com  Mon Sep 25 11:15:38 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Mon, 25 Sep 2017 11:15:38 -0400
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
 <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>
Message-ID: <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>

We don't support multiple meshes for the same object in doing the physics.
However, if two non-connected meshes are numbered contiguously the physics
treats it as one but still simulates two bodies. This is generally not done
though since there is not much of a use case. It could happen at runtime
when one cuts a mesh into two (eg: pattern cutting simulator).

On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <alexis.girault at kitware.com
> wrote:

> We wouldn't want to confuse geometries (mesh, etc...) with objects (scene
> object), which would be part of a scene graph when the needs come.
>
> Sreekanth: wouldn't creating multiple meshes for a unique object be a
> problem to handle physics?
>
> Nick: do we need to dissociate meshes per material? Could we retain a
> unique mesh and associate materials to a specific set of points/cells? I am
> remembering of the multi-texture support in VTK, where I had two sets of
> texture coordinates which allowed me to combine two textures at different
> parts of a unique mesh.
>
> Alexis Girault
> R&D Engineer in Medical Computing
> Kitware, Inc.
>
> http://www.kitware.com
> (919) 969-6990 x325
>
> On Mon, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <
> andinet.enqu at kitware.com> wrote:
>
>> I would think we will need a scene graph support at some point in iMSTK
>>
>> For example,
>>
>> https://www.sofa-framework.org/community/doc/main-principles/scene-graph/
>>
>> On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> Yes, it's very common to have this functionality, and many meshes we
>>> have use this. Currently, I have to individually export each material as a
>>> separate mesh, but this gets tedious when you end up with hundreds of
>>> meshes and have to separate/export each one individually. Also, managing
>>> these is a pain. Note that a single face can only have one material
>>> assigned to it (i.e., not layered materials).
>>>
>>> We still don't have the scene graph, but what if we introduce one and
>>> then when you import a mesh it adds a new node (called MeshGroup) under
>>> root (the scene) and then nodes (meshes) under the MeshGroup? Or it could
>>> be called MeshObject or something, etc.
>>> ------------------------------
>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>> *Sent:* Monday, September 18, 2017 11:03 AM
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* imstk-developers at imstk.org
>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>
>>> Having mesh split and maintained as separate pieces might complicate
>>> imstk's geometry mappers. Do you have a use case from one of the projects?
>>>
>>> On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu>
>>> wrote:
>>>
>>>> This question has a subtle difference compared to a previous question I
>>>> asked before, but should we add support for mesh files with multiple
>>>> materials?
>>>>
>>>> When the mesh gets imported, the regions with a different material
>>>> would get split into a new mesh. Or should we introduce a new primitive
>>>> such as a MeshGroup to handle this? Or should we keep them as separate,
>>>> unrelated meshes?
>>>>
>>>> _______________________________________________
>>>> 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
>> Director of Medical Computing
>> Kitware, Inc.
>>
>> http://www.kitware.com
>> (919) 969-6990 x311 <%28919%29%20969-6990%20x311>
>>
>>
>>
>>
>> _______________________________________________
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/46398bd8/attachment-0001.html>

From milefn at rpi.edu  Mon Sep 25 11:56:18 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 25 Sep 2017 15:56:18 +0000
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
 <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>,
 <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF6F1@ex14mb4.win.rpi.edu>

@Sreekanth, The meshes wouldn't be numbered contiguously in this case. They would just be separate surface meshes. An example would be a car mesh. You would have the tires with one material, body with another material, windows with another, etc, so they would all belong to a car object but be separate meshes. I think this makes sense as well for when you implement materials for physics (with different friction coefficients, etc.).

@Alexis, No we shouldn't disassociate the mesh from the material. By applying the material per set of points, you risk having noncontiguous triangles in this case. Also, down the line it makes it difficult to batch draw objects similar materials.

Multiple UV channel support (VTK multitexturing) doesn't relate to this problem. In practice, multiple UV coords are only useful for lightmapping or some very specialized use cases. Different meshes belonging to a larger mesh (object) don't need unique UVs, they just need unique textures.
________________________________
From: Imstk-developers [imstk-developers-bounces at imstk.org] on behalf of Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Monday, September 25, 2017 11:15 AM
To: Alexis Girault
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Multiple materials per import

We don't support multiple meshes for the same object in doing the physics. However, if two non-connected meshes are numbered contiguously the physics treats it as one but still simulates two bodies. This is generally not done though since there is not much of a use case. It could happen at runtime when one cuts a mesh into two (eg: pattern cutting simulator).

On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>> wrote:
We wouldn't want to confuse geometries (mesh, etc...) with objects (scene object), which would be part of a scene graph when the needs come.

Sreekanth: wouldn't creating multiple meshes for a unique object be a problem to handle physics?

Nick: do we need to dissociate meshes per material? Could we retain a unique mesh and associate materials to a specific set of points/cells? I am remembering of the multi-texture support in VTK, where I had two sets of texture coordinates which allowed me to combine two textures at different parts of a unique mesh.

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, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <andinet.enqu at kitware.com<mailto:andinet.enqu at kitware.com>> wrote:
I would think we will need a scene graph support at some point in iMSTK

For example,

https://www.sofa-framework.org/community/doc/main-principles/scene-graph/

On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Yes, it's very common to have this functionality, and many meshes we have use this. Currently, I have to individually export each material as a separate mesh, but this gets tedious when you end up with hundreds of meshes and have to separate/export each one individually. Also, managing these is a pain. Note that a single face can only have one material assigned to it (i.e., not layered materials).

We still don't have the scene graph, but what if we introduce one and then when you import a mesh it adds a new node (called MeshGroup) under root (the scene) and then nodes (meshes) under the MeshGroup? Or it could be called MeshObject or something, etc.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 18, 2017 11:03 AM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Multiple materials per import

Having mesh split and maintained as separate pieces might complicate imstk's geometry mappers. Do you have a use case from one of the projects?

On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
This question has a subtle difference compared to a previous question I asked before, but should we add support for mesh files with multiple materials?

When the mesh gets imported, the regions with a different material would get split into a new mesh. Or should we introduce a new primitive such as a MeshGroup to handle this? Or should we keep them as separate, unrelated meshes?

_______________________________________________
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
Director of Medical Computing
Kitware, Inc.

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



_______________________________________________
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/20170925/3c3a0312/attachment.html>

From sreekanth.arikatla at kitware.com  Mon Sep 25 12:16:23 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Mon, 25 Sep 2017 12:16:23 -0400
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AF6F1@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
 <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>
 <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF6F1@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFLpX-vGvnuUrFOK+CCg1T2nhnyb-U6jvn8UokhDJHVpvA@mail.gmail.com>

We already support multiple physics materials (thanks to Vega!) within the
same mesh in iMSTK. One can define something called regions and assign
different material properties for each region. Based on your described,
this seems to be not practical for the case of render materials.

One solution could be to have the visual geometry be composed of multiple
meshes (optionally) while the physics and collision geometries are composed
of one mesh-like now. In that case, we need to add mesh IDs in addition to
primitive ID in the geometry mappers.

On Mon, Sep 25, 2017 at 11:56 AM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> @Sreekanth, The meshes wouldn't be numbered contiguously in this case.
> They would just be separate surface meshes. An example would be a car mesh.
> You would have the tires with one material, body with another material,
> windows with another, etc, so they would all belong to a car object but be
> separate meshes. I think this makes sense as well for when you implement
> materials for physics (with different friction coefficients, etc.).
>
> @Alexis, No we shouldn't disassociate the mesh from the material. By
> applying the material per set of points, you risk having noncontiguous
> triangles in this case. Also, down the line it makes it difficult to batch
> draw objects similar materials.
>
> Multiple UV channel support (VTK multitexturing) doesn't relate to this
> problem. In practice, multiple UV coords are only useful for lightmapping
> or some very specialized use cases. Different meshes belonging to a larger
> mesh (object) don't need unique UVs, they just need unique textures.
> ------------------------------
> *From:* Imstk-developers [imstk-developers-bounces at imstk.org] on behalf
> of Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Monday, September 25, 2017 11:15 AM
> *To:* Alexis Girault
>
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Multiple materials per import
>
> We don't support multiple meshes for the same object in doing the physics.
> However, if two non-connected meshes are numbered contiguously the physics
> treats it as one but still simulates two bodies. This is generally not done
> though since there is not much of a use case. It could happen at runtime
> when one cuts a mesh into two (eg: pattern cutting simulator).
>
> On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <
> alexis.girault at kitware.com> wrote:
>
>> We wouldn't want to confuse geometries (mesh, etc...) with objects (scene
>> object), which would be part of a scene graph when the needs come.
>>
>> Sreekanth: wouldn't creating multiple meshes for a unique object be a
>> problem to handle physics?
>>
>> Nick: do we need to dissociate meshes per material? Could we retain a
>> unique mesh and associate materials to a specific set of points/cells? I am
>> remembering of the multi-texture support in VTK, where I had two sets of
>> texture coordinates which allowed me to combine two textures at different
>> parts of a unique mesh.
>>
>> Alexis Girault
>> R&D Engineer in Medical Computing
>> Kitware, Inc.
>>
>> http://www.kitware.com
>> (919) 969-6990 x325
>>
>> On Mon, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <
>> andinet.enqu at kitware.com> wrote:
>>
>>> I would think we will need a scene graph support at some point in iMSTK
>>>
>>> For example,
>>>
>>> https://www.sofa-framework.org/community/doc/main-principles
>>> /scene-graph/
>>>
>>> On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <milefn at rpi.edu>
>>> wrote:
>>>
>>>> Yes, it's very common to have this functionality, and many meshes we
>>>> have use this. Currently, I have to individually export each material as a
>>>> separate mesh, but this gets tedious when you end up with hundreds of
>>>> meshes and have to separate/export each one individually. Also, managing
>>>> these is a pain. Note that a single face can only have one material
>>>> assigned to it (i.e., not layered materials).
>>>>
>>>> We still don't have the scene graph, but what if we introduce one and
>>>> then when you import a mesh it adds a new node (called MeshGroup) under
>>>> root (the scene) and then nodes (meshes) under the MeshGroup? Or it could
>>>> be called MeshObject or something, etc.
>>>> ------------------------------
>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>> *Sent:* Monday, September 18, 2017 11:03 AM
>>>> *To:* Milef, Nicholas Boris
>>>> *Cc:* imstk-developers at imstk.org
>>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>>
>>>> Having mesh split and maintained as separate pieces might complicate
>>>> imstk's geometry mappers. Do you have a use case from one of the projects?
>>>>
>>>> On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu
>>>> > wrote:
>>>>
>>>>> This question has a subtle difference compared to a previous question
>>>>> I asked before, but should we add support for mesh files with multiple
>>>>> materials?
>>>>>
>>>>> When the mesh gets imported, the regions with a different material
>>>>> would get split into a new mesh. Or should we introduce a new primitive
>>>>> such as a MeshGroup to handle this? Or should we keep them as separate,
>>>>> unrelated meshes?
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> Director of Medical Computing
>>> Kitware, Inc.
>>>
>>> http://www.kitware.com
>>> (919) 969-6990 x311 <%28919%29%20969-6990%20x311>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20170925/30b6de09/attachment.html>

From milefn at rpi.edu  Mon Sep 25 12:44:52 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 25 Sep 2017 16:44:52 +0000
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <CAJFrbFLpX-vGvnuUrFOK+CCg1T2nhnyb-U6jvn8UokhDJHVpvA@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
 <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>
 <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF6F1@ex14mb4.win.rpi.edu>,
 <CAJFrbFLpX-vGvnuUrFOK+CCg1T2nhnyb-U6jvn8UokhDJHVpvA@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF716@ex14mb4.win.rpi.edu>

Ok we could do that for imstkSceneObject (allow setting of multiple visual meshes). This would mean that mesh readers could import multiple geometries. Why would we need mesh IDs though?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Monday, September 25, 2017 12:16 PM
To: Milef, Nicholas Boris
Cc: Alexis Girault; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Multiple materials per import

We already support multiple physics materials (thanks to Vega!) within the same mesh in iMSTK. One can define something called regions and assign different material properties for each region. Based on your described, this seems to be not practical for the case of render materials.

One solution could be to have the visual geometry be composed of multiple meshes (optionally) while the physics and collision geometries are composed of one mesh-like now. In that case, we need to add mesh IDs in addition to primitive ID in the geometry mappers.

On Mon, Sep 25, 2017 at 11:56 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
@Sreekanth, The meshes wouldn't be numbered contiguously in this case. They would just be separate surface meshes. An example would be a car mesh. You would have the tires with one material, body with another material, windows with another, etc, so they would all belong to a car object but be separate meshes. I think this makes sense as well for when you implement materials for physics (with different friction coefficients, etc.).

@Alexis, No we shouldn't disassociate the mesh from the material. By applying the material per set of points, you risk having noncontiguous triangles in this case. Also, down the line it makes it difficult to batch draw objects similar materials.

Multiple UV channel support (VTK multitexturing) doesn't relate to this problem. In practice, multiple UV coords are only useful for lightmapping or some very specialized use cases. Different meshes belonging to a larger mesh (object) don't need unique UVs, they just need unique textures.
________________________________
From: Imstk-developers [imstk-developers-bounces at imstk.org<mailto:imstk-developers-bounces at imstk.org>] on behalf of Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 25, 2017 11:15 AM
To: Alexis Girault

Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Multiple materials per import

We don't support multiple meshes for the same object in doing the physics. However, if two non-connected meshes are numbered contiguously the physics treats it as one but still simulates two bodies. This is generally not done though since there is not much of a use case. It could happen at runtime when one cuts a mesh into two (eg: pattern cutting simulator).

On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>> wrote:
We wouldn't want to confuse geometries (mesh, etc...) with objects (scene object), which would be part of a scene graph when the needs come.

Sreekanth: wouldn't creating multiple meshes for a unique object be a problem to handle physics?

Nick: do we need to dissociate meshes per material? Could we retain a unique mesh and associate materials to a specific set of points/cells? I am remembering of the multi-texture support in VTK, where I had two sets of texture coordinates which allowed me to combine two textures at different parts of a unique mesh.

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, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <andinet.enqu at kitware.com<mailto:andinet.enqu at kitware.com>> wrote:
I would think we will need a scene graph support at some point in iMSTK

For example,

https://www.sofa-framework.org/community/doc/main-principles/scene-graph/

On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Yes, it's very common to have this functionality, and many meshes we have use this. Currently, I have to individually export each material as a separate mesh, but this gets tedious when you end up with hundreds of meshes and have to separate/export each one individually. Also, managing these is a pain. Note that a single face can only have one material assigned to it (i.e., not layered materials).

We still don't have the scene graph, but what if we introduce one and then when you import a mesh it adds a new node (called MeshGroup) under root (the scene) and then nodes (meshes) under the MeshGroup? Or it could be called MeshObject or something, etc.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 18, 2017 11:03 AM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Multiple materials per import

Having mesh split and maintained as separate pieces might complicate imstk's geometry mappers. Do you have a use case from one of the projects?

On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
This question has a subtle difference compared to a previous question I asked before, but should we add support for mesh files with multiple materials?

When the mesh gets imported, the regions with a different material would get split into a new mesh. Or should we introduce a new primitive such as a MeshGroup to handle this? Or should we keep them as separate, unrelated meshes?

_______________________________________________
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
Director of Medical Computing
Kitware, Inc.

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



_______________________________________________
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.




--
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/20170925/b9300732/attachment-0001.html>

From sreekanth.arikatla at kitware.com  Mon Sep 25 16:23:35 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Mon, 25 Sep 2017 16:23:35 -0400
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AF731@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
 <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>
 <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF6F1@ex14mb4.win.rpi.edu>
 <CAJFrbFLpX-vGvnuUrFOK+CCg1T2nhnyb-U6jvn8UokhDJHVpvA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF716@ex14mb4.win.rpi.edu>
 <CAJFrbF+7bK0BbO4XN_OuAqutqdeb9YggXfpyZidr2bVeDDN1LA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF731@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFLOqXdWS35iXk1JGkZAL8nFe=uGT4eJHW0oBb-NGEiKyQ@mail.gmail.com>

Hi Nick,
            I think there are two cases here:

1. Representing geometry of a *continuous object *with multiple meshes
which could otherwise be represented using a single mesh

?
2. Representing the body with an assembly of components with different
meshes.

?
*Physics*:

For the case 1, physics module can accept this but as a single mesh with
each region optionally having different material properties. It is possible
to treat them as separate meshes, but the formulation becomes unnecessarily
complex. For case 2, each part of the assembly is modeled as a separate
physics objects; and hence separate scene objects (since for example, the
car is non-contiguous). The contact interactions between the component
meshes will have to be defined which is a different matter.

*Rendering*:

I think rendering can also work if each partition is treated as different
mesh in case 1. If this is done, then there will be a 1-to-many kind of
geometry map when updating the visual meshes after each physics frame. To
make this possible we can extend the current maps additionally introducing
mesh id.
There could be a rare case of many-to-1 (for car example) but I don't see
much use for it.



On Mon, Sep 25, 2017 at 2:25 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Why couldn't we just split up the mesh on import into multiple
> (physics/visual) meshes?
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Monday, September 25, 2017 1:42 PM
> *To:* Milef, Nicholas Boris
>
> *Subject:* Re: [Imstk-developers] Multiple materials per import
>
> After this change, single physics mesh can map to a group of rendering
> meshes. We might have to add the mesh ids to know which render mesh the
> primitive belongs to.
>
> On Mon, Sep 25, 2017 at 12:44 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Ok we could do that for imstkSceneObject (allow setting of multiple
>> visual meshes). This would mean that mesh readers could import multiple
>> geometries. Why would we need mesh IDs though?
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Monday, September 25, 2017 12:16 PM
>> *To:* Milef, Nicholas Boris
>> *Cc:* Alexis Girault; imstk-developers at imstk.org
>>
>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>
>> We already support multiple physics materials (thanks to Vega!) within
>> the same mesh in iMSTK. One can define something called regions and assign
>> different material properties for each region. Based on your described,
>> this seems to be not practical for the case of render materials.
>>
>> One solution could be to have the visual geometry be composed of multiple
>> meshes (optionally) while the physics and collision geometries are composed
>> of one mesh-like now. In that case, we need to add mesh IDs in addition to
>> primitive ID in the geometry mappers.
>>
>> On Mon, Sep 25, 2017 at 11:56 AM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> @Sreekanth, The meshes wouldn't be numbered contiguously in this case.
>>> They would just be separate surface meshes. An example would be a car mesh.
>>> You would have the tires with one material, body with another material,
>>> windows with another, etc, so they would all belong to a car object but be
>>> separate meshes. I think this makes sense as well for when you implement
>>> materials for physics (with different friction coefficients, etc.).
>>>
>>> @Alexis, No we shouldn't disassociate the mesh from the material. By
>>> applying the material per set of points, you risk having noncontiguous
>>> triangles in this case. Also, down the line it makes it difficult to batch
>>> draw objects similar materials.
>>>
>>> Multiple UV channel support (VTK multitexturing) doesn't relate to this
>>> problem. In practice, multiple UV coords are only useful for lightmapping
>>> or some very specialized use cases. Different meshes belonging to a larger
>>> mesh (object) don't need unique UVs, they just need unique textures.
>>> ------------------------------
>>> *From:* Imstk-developers [imstk-developers-bounces at imstk.org] on behalf
>>> of Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>> *Sent:* Monday, September 25, 2017 11:15 AM
>>> *To:* Alexis Girault
>>>
>>> *Cc:* imstk-developers at imstk.org
>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>
>>> We don't support multiple meshes for the same object in doing the
>>> physics. However, if two non-connected meshes are numbered contiguously the
>>> physics treats it as one but still simulates two bodies. This is generally
>>> not done though since there is not much of a use case. It could happen at
>>> runtime when one cuts a mesh into two (eg: pattern cutting simulator).
>>>
>>> On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <
>>> alexis.girault at kitware.com> wrote:
>>>
>>>> We wouldn't want to confuse geometries (mesh, etc...) with objects
>>>> (scene object), which would be part of a scene graph when the needs come.
>>>>
>>>> Sreekanth: wouldn't creating multiple meshes for a unique object be a
>>>> problem to handle physics?
>>>>
>>>> Nick: do we need to dissociate meshes per material? Could we retain a
>>>> unique mesh and associate materials to a specific set of points/cells? I am
>>>> remembering of the multi-texture support in VTK, where I had two sets of
>>>> texture coordinates which allowed me to combine two textures at different
>>>> parts of a unique mesh.
>>>>
>>>> Alexis Girault
>>>> R&D Engineer in Medical Computing
>>>> Kitware, Inc.
>>>>
>>>> http://www.kitware.com
>>>> (919) 969-6990 x325
>>>>
>>>> On Mon, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <
>>>> andinet.enqu at kitware.com> wrote:
>>>>
>>>>> I would think we will need a scene graph support at some point in
>>>>> iMSTK
>>>>>
>>>>> For example,
>>>>>
>>>>> https://www.sofa-framework.org/community/doc/main-principles
>>>>> /scene-graph/
>>>>>
>>>>> On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <
>>>>> milefn at rpi.edu> wrote:
>>>>>
>>>>>> Yes, it's very common to have this functionality, and many meshes we
>>>>>> have use this. Currently, I have to individually export each material as a
>>>>>> separate mesh, but this gets tedious when you end up with hundreds of
>>>>>> meshes and have to separate/export each one individually. Also, managing
>>>>>> these is a pain. Note that a single face can only have one material
>>>>>> assigned to it (i.e., not layered materials).
>>>>>>
>>>>>> We still don't have the scene graph, but what if we introduce one and
>>>>>> then when you import a mesh it adds a new node (called MeshGroup) under
>>>>>> root (the scene) and then nodes (meshes) under the MeshGroup? Or it could
>>>>>> be called MeshObject or something, etc.
>>>>>> ------------------------------
>>>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>>>> *Sent:* Monday, September 18, 2017 11:03 AM
>>>>>> *To:* Milef, Nicholas Boris
>>>>>> *Cc:* imstk-developers at imstk.org
>>>>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>>>>
>>>>>> Having mesh split and maintained as separate pieces might complicate
>>>>>> imstk's geometry mappers. Do you have a use case from one of the projects?
>>>>>>
>>>>>> On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <
>>>>>> milefn at rpi.edu> wrote:
>>>>>>
>>>>>>> This question has a subtle difference compared to a previous
>>>>>>> question I asked before, but should we add support for mesh files with
>>>>>>> multiple materials?
>>>>>>>
>>>>>>> When the mesh gets imported, the regions with a different material
>>>>>>> would get split into a new mesh. Or should we introduce a new primitive
>>>>>>> such as a MeshGroup to handle this? Or should we keep them as separate,
>>>>>>> unrelated meshes?
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>> Director of Medical Computing
>>>>> Kitware, Inc.
>>>>>
>>>>> http://www.kitware.com
>>>>> (919) 969-6990 x311 <%28919%29%20969-6990%20x311>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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.
>>
>>
>
>
> --
> 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/20170925/aae0c8dc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partitionedMesh.png
Type: image/png
Size: 59696 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/aae0c8dc/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MeshGroup.png
Type: image/png
Size: 165521 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/aae0c8dc/attachment-0003.png>

From milefn at rpi.edu  Mon Sep 25 16:50:42 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 25 Sep 2017 20:50:42 +0000
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <CAJFrbFLOqXdWS35iXk1JGkZAL8nFe=uGT4eJHW0oBb-NGEiKyQ@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
 <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>
 <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF6F1@ex14mb4.win.rpi.edu>
 <CAJFrbFLpX-vGvnuUrFOK+CCg1T2nhnyb-U6jvn8UokhDJHVpvA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF716@ex14mb4.win.rpi.edu>
 <CAJFrbF+7bK0BbO4XN_OuAqutqdeb9YggXfpyZidr2bVeDDN1LA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF731@ex14mb4.win.rpi.edu>,
 <CAJFrbFLOqXdWS35iXk1JGkZAL8nFe=uGT4eJHW0oBb-NGEiKyQ@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF760@ex14mb4.win.rpi.edu>

imo Case 1 and 2 are the same (they share vertices along material edges). On mesh import, the vertices will be duplicated along each edge though (it works somewhat this way currently for different UV coordinates), so the connectivity data gets separated anyway per region at least with the Assimp importer. I'm not sure if you currently remesh this data though to eliminate duplicates. Maybe with Vega meshes it's different though.

I don't think it's a common use case for deformable meshes to have multiple materials. Even if they did, it would likely be a very small number of materials, and it could possibly by represented by a custom shader. It's more for things like tools/environmental objects. If we map geometries, then we need to maintain render mesh data structures as well. I'm not sure what's supposed to happen if the user modifies the render mesh (or can they?). What do you think?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Monday, September 25, 2017 4:23 PM
To: Milef, Nicholas Boris; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Multiple materials per import

Hi Nick,
            I think there are two cases here:

1. Representing geometry of a continuous object with multiple meshes which could otherwise be represented using a single mesh
[cid:ii_j80m4cs40_15ebaae358d9d605]
?
2. Representing the body with an assembly of components with different meshes.
[cid:ii_j80m56x71_15ebaaecdc9303bf]
?
Physics:

For the case 1, physics module can accept this but as a single mesh with each region optionally having different material properties. It is possible to treat them as separate meshes, but the formulation becomes unnecessarily complex. For case 2, each part of the assembly is modeled as a separate physics objects; and hence separate scene objects (since for example, the car is non-contiguous). The contact interactions between the component meshes will have to be defined which is a different matter.

Rendering:

I think rendering can also work if each partition is treated as different mesh in case 1. If this is done, then there will be a 1-to-many kind of geometry map when updating the visual meshes after each physics frame. To make this possible we can extend the current maps additionally introducing mesh id.
There could be a rare case of many-to-1 (for car example) but I don't see much use for it.



On Mon, Sep 25, 2017 at 2:25 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Why couldn't we just split up the mesh on import into multiple (physics/visual) meshes?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 25, 2017 1:42 PM
To: Milef, Nicholas Boris

Subject: Re: [Imstk-developers] Multiple materials per import

After this change, single physics mesh can map to a group of rendering meshes. We might have to add the mesh ids to know which render mesh the primitive belongs to.

On Mon, Sep 25, 2017 at 12:44 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Ok we could do that for imstkSceneObject (allow setting of multiple visual meshes). This would mean that mesh readers could import multiple geometries. Why would we need mesh IDs though?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 25, 2017 12:16 PM
To: Milef, Nicholas Boris
Cc: Alexis Girault; imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>

Subject: Re: [Imstk-developers] Multiple materials per import

We already support multiple physics materials (thanks to Vega!) within the same mesh in iMSTK. One can define something called regions and assign different material properties for each region. Based on your described, this seems to be not practical for the case of render materials.

One solution could be to have the visual geometry be composed of multiple meshes (optionally) while the physics and collision geometries are composed of one mesh-like now. In that case, we need to add mesh IDs in addition to primitive ID in the geometry mappers.

On Mon, Sep 25, 2017 at 11:56 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
@Sreekanth, The meshes wouldn't be numbered contiguously in this case. They would just be separate surface meshes. An example would be a car mesh. You would have the tires with one material, body with another material, windows with another, etc, so they would all belong to a car object but be separate meshes. I think this makes sense as well for when you implement materials for physics (with different friction coefficients, etc.).

@Alexis, No we shouldn't disassociate the mesh from the material. By applying the material per set of points, you risk having noncontiguous triangles in this case. Also, down the line it makes it difficult to batch draw objects similar materials.

Multiple UV channel support (VTK multitexturing) doesn't relate to this problem. In practice, multiple UV coords are only useful for lightmapping or some very specialized use cases. Different meshes belonging to a larger mesh (object) don't need unique UVs, they just need unique textures.
________________________________
From: Imstk-developers [imstk-developers-bounces at imstk.org<mailto:imstk-developers-bounces at imstk.org>] on behalf of Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 25, 2017 11:15 AM
To: Alexis Girault

Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Multiple materials per import

We don't support multiple meshes for the same object in doing the physics. However, if two non-connected meshes are numbered contiguously the physics treats it as one but still simulates two bodies. This is generally not done though since there is not much of a use case. It could happen at runtime when one cuts a mesh into two (eg: pattern cutting simulator).

On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>> wrote:
We wouldn't want to confuse geometries (mesh, etc...) with objects (scene object), which would be part of a scene graph when the needs come.

Sreekanth: wouldn't creating multiple meshes for a unique object be a problem to handle physics?

Nick: do we need to dissociate meshes per material? Could we retain a unique mesh and associate materials to a specific set of points/cells? I am remembering of the multi-texture support in VTK, where I had two sets of texture coordinates which allowed me to combine two textures at different parts of a unique mesh.

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, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <andinet.enqu at kitware.com<mailto:andinet.enqu at kitware.com>> wrote:
I would think we will need a scene graph support at some point in iMSTK

For example,

https://www.sofa-framework.org/community/doc/main-principles/scene-graph/

On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Yes, it's very common to have this functionality, and many meshes we have use this. Currently, I have to individually export each material as a separate mesh, but this gets tedious when you end up with hundreds of meshes and have to separate/export each one individually. Also, managing these is a pain. Note that a single face can only have one material assigned to it (i.e., not layered materials).

We still don't have the scene graph, but what if we introduce one and then when you import a mesh it adds a new node (called MeshGroup) under root (the scene) and then nodes (meshes) under the MeshGroup? Or it could be called MeshObject or something, etc.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 18, 2017 11:03 AM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Multiple materials per import

Having mesh split and maintained as separate pieces might complicate imstk's geometry mappers. Do you have a use case from one of the projects?

On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
This question has a subtle difference compared to a previous question I asked before, but should we add support for mesh files with multiple materials?

When the mesh gets imported, the regions with a different material would get split into a new mesh. Or should we introduce a new primitive such as a MeshGroup to handle this? Or should we keep them as separate, unrelated meshes?

_______________________________________________
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
Director of Medical Computing
Kitware, Inc.

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



_______________________________________________
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.




--
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.




--
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/20170925/434180ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partitionedMesh.png
Type: image/png
Size: 59696 bytes
Desc: partitionedMesh.png
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/434180ff/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MeshGroup.png
Type: image/png
Size: 165521 bytes
Desc: MeshGroup.png
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/434180ff/attachment-0003.png>

From sreekanth.arikatla at kitware.com  Mon Sep 25 17:11:40 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Mon, 25 Sep 2017 17:11:40 -0400
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AF760@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
 <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>
 <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF6F1@ex14mb4.win.rpi.edu>
 <CAJFrbFLpX-vGvnuUrFOK+CCg1T2nhnyb-U6jvn8UokhDJHVpvA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF716@ex14mb4.win.rpi.edu>
 <CAJFrbF+7bK0BbO4XN_OuAqutqdeb9YggXfpyZidr2bVeDDN1LA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF731@ex14mb4.win.rpi.edu>
 <CAJFrbFLOqXdWS35iXk1JGkZAL8nFe=uGT4eJHW0oBb-NGEiKyQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF760@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFLF7R48YSwUN_DUecrx0RAjkKof_Y_PF0KmooS8jukTYg@mail.gmail.com>

Hi Nick,
            Case 1 and 2 are very different from physics POV. They are
treated as different bodies and there are formulations that work with
contacts of non-conformal meshes. Yes, we don't encounter many different
materials in physics but if we were to reach high fidelity, we could have
graded physics material property which could mean each element could have a
slightly different material property compared to its neighbors. Having this
generally doesn't come with an additional computational cost.

In this regard, rendering is more flexible. For example non-contiguous
medium (eg: two organs touching each other) can be treated as one by the
rendering is given that one takes care of the details about intersecting
primitives that you mentioned.

As far as the user is concerned he/she is modifying what they are seeing
i.e., the rendering mesh (eg: pattern cutting simulation). But behind the
scenes, all associated mesh representations (physics, collision, rendering)
have to be modified in a *consistent* manner. This essentially means that
we have to modify the geometry maps.

On Mon, Sep 25, 2017 at 4:50 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> imo Case 1 and 2 are the same (they share vertices along material edges).
> On mesh import, the vertices will be duplicated along each edge though (it
> works somewhat this way currently for different UV coordinates), so the
> connectivity data gets separated anyway per region at least with the Assimp
> importer. I'm not sure if you currently remesh this data though to
> eliminate duplicates. Maybe with Vega meshes it's different though.
>
> I don't think it's a common use case for deformable meshes to have
> multiple materials. Even if they did, it would likely be a very small
> number of materials, and it could possibly by represented by a custom
> shader. It's more for things like tools/environmental objects. If we map
> geometries, then we need to maintain render mesh data structures as well.
> I'm not sure what's supposed to happen if the user modifies the render mesh
> (or can they?). What do you think?
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Monday, September 25, 2017 4:23 PM
> *To:* Milef, Nicholas Boris; imstk-developers at imstk.org
>
> *Subject:* Re: [Imstk-developers] Multiple materials per import
>
> Hi Nick,
>             I think there are two cases here:
>
> 1. Representing geometry of a *continuous object *with multiple meshes
> which could otherwise be represented using a single mesh
>
> ?
> 2. Representing the body with an assembly of components with different
> meshes.
>
> ?
> *Physics*:
>
> For the case 1, physics module can accept this but as a single mesh with
> each region optionally having different material properties. It is possible
> to treat them as separate meshes, but the formulation becomes unnecessarily
> complex. For case 2, each part of the assembly is modeled as a separate
> physics objects; and hence separate scene objects (since for example, the
> car is non-contiguous). The contact interactions between the component
> meshes will have to be defined which is a different matter.
>
> *Rendering*:
>
> I think rendering can also work if each partition is treated as different
> mesh in case 1. If this is done, then there will be a 1-to-many kind of
> geometry map when updating the visual meshes after each physics frame. To
> make this possible we can extend the current maps additionally introducing
> mesh id.
> There could be a rare case of many-to-1 (for car example) but I don't see
> much use for it.
>
>
>
> On Mon, Sep 25, 2017 at 2:25 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Why couldn't we just split up the mesh on import into multiple
>> (physics/visual) meshes?
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Monday, September 25, 2017 1:42 PM
>> *To:* Milef, Nicholas Boris
>>
>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>
>> After this change, single physics mesh can map to a group of rendering
>> meshes. We might have to add the mesh ids to know which render mesh the
>> primitive belongs to.
>>
>> On Mon, Sep 25, 2017 at 12:44 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> Ok we could do that for imstkSceneObject (allow setting of multiple
>>> visual meshes). This would mean that mesh readers could import multiple
>>> geometries. Why would we need mesh IDs though?
>>> ------------------------------
>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>> *Sent:* Monday, September 25, 2017 12:16 PM
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* Alexis Girault; imstk-developers at imstk.org
>>>
>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>
>>> We already support multiple physics materials (thanks to Vega!) within
>>> the same mesh in iMSTK. One can define something called regions and assign
>>> different material properties for each region. Based on your described,
>>> this seems to be not practical for the case of render materials.
>>>
>>> One solution could be to have the visual geometry be composed of
>>> multiple meshes (optionally) while the physics and collision geometries are
>>> composed of one mesh-like now. In that case, we need to add mesh IDs in
>>> addition to primitive ID in the geometry mappers.
>>>
>>> On Mon, Sep 25, 2017 at 11:56 AM, Milef, Nicholas Boris <milefn at rpi.edu>
>>> wrote:
>>>
>>>> @Sreekanth, The meshes wouldn't be numbered contiguously in this case.
>>>> They would just be separate surface meshes. An example would be a car mesh.
>>>> You would have the tires with one material, body with another material,
>>>> windows with another, etc, so they would all belong to a car object but be
>>>> separate meshes. I think this makes sense as well for when you implement
>>>> materials for physics (with different friction coefficients, etc.).
>>>>
>>>> @Alexis, No we shouldn't disassociate the mesh from the material. By
>>>> applying the material per set of points, you risk having noncontiguous
>>>> triangles in this case. Also, down the line it makes it difficult to batch
>>>> draw objects similar materials.
>>>>
>>>> Multiple UV channel support (VTK multitexturing) doesn't relate to this
>>>> problem. In practice, multiple UV coords are only useful for lightmapping
>>>> or some very specialized use cases. Different meshes belonging to a larger
>>>> mesh (object) don't need unique UVs, they just need unique textures.
>>>> ------------------------------
>>>> *From:* Imstk-developers [imstk-developers-bounces at imstk.org] on
>>>> behalf of Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>> *Sent:* Monday, September 25, 2017 11:15 AM
>>>> *To:* Alexis Girault
>>>>
>>>> *Cc:* imstk-developers at imstk.org
>>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>>
>>>> We don't support multiple meshes for the same object in doing the
>>>> physics. However, if two non-connected meshes are numbered contiguously the
>>>> physics treats it as one but still simulates two bodies. This is generally
>>>> not done though since there is not much of a use case. It could happen at
>>>> runtime when one cuts a mesh into two (eg: pattern cutting simulator).
>>>>
>>>> On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <
>>>> alexis.girault at kitware.com> wrote:
>>>>
>>>>> We wouldn't want to confuse geometries (mesh, etc...) with objects
>>>>> (scene object), which would be part of a scene graph when the needs come.
>>>>>
>>>>> Sreekanth: wouldn't creating multiple meshes for a unique object be a
>>>>> problem to handle physics?
>>>>>
>>>>> Nick: do we need to dissociate meshes per material? Could we retain a
>>>>> unique mesh and associate materials to a specific set of points/cells? I am
>>>>> remembering of the multi-texture support in VTK, where I had two sets of
>>>>> texture coordinates which allowed me to combine two textures at different
>>>>> parts of a unique mesh.
>>>>>
>>>>> Alexis Girault
>>>>> R&D Engineer in Medical Computing
>>>>> Kitware, Inc.
>>>>>
>>>>> http://www.kitware.com
>>>>> (919) 969-6990 x325
>>>>>
>>>>> On Mon, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <
>>>>> andinet.enqu at kitware.com> wrote:
>>>>>
>>>>>> I would think we will need a scene graph support at some point in
>>>>>> iMSTK
>>>>>>
>>>>>> For example,
>>>>>>
>>>>>> https://www.sofa-framework.org/community/doc/main-principles
>>>>>> /scene-graph/
>>>>>>
>>>>>> On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <
>>>>>> milefn at rpi.edu> wrote:
>>>>>>
>>>>>>> Yes, it's very common to have this functionality, and many meshes we
>>>>>>> have use this. Currently, I have to individually export each material as a
>>>>>>> separate mesh, but this gets tedious when you end up with hundreds of
>>>>>>> meshes and have to separate/export each one individually. Also, managing
>>>>>>> these is a pain. Note that a single face can only have one material
>>>>>>> assigned to it (i.e., not layered materials).
>>>>>>>
>>>>>>> We still don't have the scene graph, but what if we introduce one
>>>>>>> and then when you import a mesh it adds a new node (called MeshGroup) under
>>>>>>> root (the scene) and then nodes (meshes) under the MeshGroup? Or it could
>>>>>>> be called MeshObject or something, etc.
>>>>>>> ------------------------------
>>>>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>>>>> *Sent:* Monday, September 18, 2017 11:03 AM
>>>>>>> *To:* Milef, Nicholas Boris
>>>>>>> *Cc:* imstk-developers at imstk.org
>>>>>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>>>>>
>>>>>>> Having mesh split and maintained as separate pieces might complicate
>>>>>>> imstk's geometry mappers. Do you have a use case from one of the projects?
>>>>>>>
>>>>>>> On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <
>>>>>>> milefn at rpi.edu> wrote:
>>>>>>>
>>>>>>>> This question has a subtle difference compared to a previous
>>>>>>>> question I asked before, but should we add support for mesh files with
>>>>>>>> multiple materials?
>>>>>>>>
>>>>>>>> When the mesh gets imported, the regions with a different material
>>>>>>>> would get split into a new mesh. Or should we introduce a new primitive
>>>>>>>> such as a MeshGroup to handle this? Or should we keep them as separate,
>>>>>>>> unrelated meshes?
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>> Director of Medical Computing
>>>>>> Kitware, Inc.
>>>>>>
>>>>>> http://www.kitware.com
>>>>>> (919) 969-6990 x311 <%28919%29%20969-6990%20x311>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>
>>>
>>
>>
>> --
>> 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.
>
>


-- 
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/20170925/9b2e1377/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MeshGroup.png
Type: image/png
Size: 165521 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/9b2e1377/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partitionedMesh.png
Type: image/png
Size: 59696 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/9b2e1377/attachment-0003.png>

From milefn at rpi.edu  Mon Sep 25 17:45:04 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 25 Sep 2017 21:45:04 +0000
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <CAJFrbFLF7R48YSwUN_DUecrx0RAjkKof_Y_PF0KmooS8jukTYg@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
 <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>
 <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF6F1@ex14mb4.win.rpi.edu>
 <CAJFrbFLpX-vGvnuUrFOK+CCg1T2nhnyb-U6jvn8UokhDJHVpvA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF716@ex14mb4.win.rpi.edu>
 <CAJFrbF+7bK0BbO4XN_OuAqutqdeb9YggXfpyZidr2bVeDDN1LA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF731@ex14mb4.win.rpi.edu>
 <CAJFrbFLOqXdWS35iXk1JGkZAL8nFe=uGT4eJHW0oBb-NGEiKyQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF760@ex14mb4.win.rpi.edu>,
 <CAJFrbFLF7R48YSwUN_DUecrx0RAjkKof_Y_PF0KmooS8jukTYg@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF79F@ex14mb4.win.rpi.edu>

What I mean for materials is render materials. Currently, if you were to import a mesh, these regions wouldn't be contiguous if they had different render materials. There are a few exceptions to this such as Vega, but that's because there's not render material information. I wouldn't expect there to be multiple render materials to on a single deformable mesh.

Anyway, if we do this, then we will need to create an imstkRenderMesh class or something similar. Also, what do the hexahedral and tetrahedral render delegates do? I haven't seen an example of it and not sure how they factor in to this.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Monday, September 25, 2017 5:11 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Multiple materials per import

Hi Nick,
            Case 1 and 2 are very different from physics POV. They are treated as different bodies and there are formulations that work with contacts of non-conformal meshes. Yes, we don't encounter many different materials in physics but if we were to reach high fidelity, we could have graded physics material property which could mean each element could have a slightly different material property compared to its neighbors. Having this generally doesn't come with an additional computational cost.

In this regard, rendering is more flexible. For example non-contiguous medium (eg: two organs touching each other) can be treated as one by the rendering is given that one takes care of the details about intersecting primitives that you mentioned.

As far as the user is concerned he/she is modifying what they are seeing i.e., the rendering mesh (eg: pattern cutting simulation). But behind the scenes, all associated mesh representations (physics, collision, rendering) have to be modified in a consistent manner. This essentially means that we have to modify the geometry maps.

On Mon, Sep 25, 2017 at 4:50 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
imo Case 1 and 2 are the same (they share vertices along material edges). On mesh import, the vertices will be duplicated along each edge though (it works somewhat this way currently for different UV coordinates), so the connectivity data gets separated anyway per region at least with the Assimp importer. I'm not sure if you currently remesh this data though to eliminate duplicates. Maybe with Vega meshes it's different though.

I don't think it's a common use case for deformable meshes to have multiple materials. Even if they did, it would likely be a very small number of materials, and it could possibly by represented by a custom shader. It's more for things like tools/environmental objects. If we map geometries, then we need to maintain render mesh data structures as well. I'm not sure what's supposed to happen if the user modifies the render mesh (or can they?). What do you think?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 25, 2017 4:23 PM
To: Milef, Nicholas Boris; imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>

Subject: Re: [Imstk-developers] Multiple materials per import

Hi Nick,
            I think there are two cases here:

1. Representing geometry of a continuous object with multiple meshes which could otherwise be represented using a single mesh
[cid:ii_j80m4cs40_15ebaae358d9d605]
?
2. Representing the body with an assembly of components with different meshes.
[cid:ii_j80m56x71_15ebaaecdc9303bf]
?
Physics:

For the case 1, physics module can accept this but as a single mesh with each region optionally having different material properties. It is possible to treat them as separate meshes, but the formulation becomes unnecessarily complex. For case 2, each part of the assembly is modeled as a separate physics objects; and hence separate scene objects (since for example, the car is non-contiguous). The contact interactions between the component meshes will have to be defined which is a different matter.

Rendering:

I think rendering can also work if each partition is treated as different mesh in case 1. If this is done, then there will be a 1-to-many kind of geometry map when updating the visual meshes after each physics frame. To make this possible we can extend the current maps additionally introducing mesh id.
There could be a rare case of many-to-1 (for car example) but I don't see much use for it.



On Mon, Sep 25, 2017 at 2:25 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Why couldn't we just split up the mesh on import into multiple (physics/visual) meshes?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 25, 2017 1:42 PM
To: Milef, Nicholas Boris

Subject: Re: [Imstk-developers] Multiple materials per import

After this change, single physics mesh can map to a group of rendering meshes. We might have to add the mesh ids to know which render mesh the primitive belongs to.

On Mon, Sep 25, 2017 at 12:44 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Ok we could do that for imstkSceneObject (allow setting of multiple visual meshes). This would mean that mesh readers could import multiple geometries. Why would we need mesh IDs though?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 25, 2017 12:16 PM
To: Milef, Nicholas Boris
Cc: Alexis Girault; imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>

Subject: Re: [Imstk-developers] Multiple materials per import

We already support multiple physics materials (thanks to Vega!) within the same mesh in iMSTK. One can define something called regions and assign different material properties for each region. Based on your described, this seems to be not practical for the case of render materials.

One solution could be to have the visual geometry be composed of multiple meshes (optionally) while the physics and collision geometries are composed of one mesh-like now. In that case, we need to add mesh IDs in addition to primitive ID in the geometry mappers.

On Mon, Sep 25, 2017 at 11:56 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
@Sreekanth, The meshes wouldn't be numbered contiguously in this case. They would just be separate surface meshes. An example would be a car mesh. You would have the tires with one material, body with another material, windows with another, etc, so they would all belong to a car object but be separate meshes. I think this makes sense as well for when you implement materials for physics (with different friction coefficients, etc.).

@Alexis, No we shouldn't disassociate the mesh from the material. By applying the material per set of points, you risk having noncontiguous triangles in this case. Also, down the line it makes it difficult to batch draw objects similar materials.

Multiple UV channel support (VTK multitexturing) doesn't relate to this problem. In practice, multiple UV coords are only useful for lightmapping or some very specialized use cases. Different meshes belonging to a larger mesh (object) don't need unique UVs, they just need unique textures.
________________________________
From: Imstk-developers [imstk-developers-bounces at imstk.org<mailto:imstk-developers-bounces at imstk.org>] on behalf of Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 25, 2017 11:15 AM
To: Alexis Girault

Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Multiple materials per import

We don't support multiple meshes for the same object in doing the physics. However, if two non-connected meshes are numbered contiguously the physics treats it as one but still simulates two bodies. This is generally not done though since there is not much of a use case. It could happen at runtime when one cuts a mesh into two (eg: pattern cutting simulator).

On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>> wrote:
We wouldn't want to confuse geometries (mesh, etc...) with objects (scene object), which would be part of a scene graph when the needs come.

Sreekanth: wouldn't creating multiple meshes for a unique object be a problem to handle physics?

Nick: do we need to dissociate meshes per material? Could we retain a unique mesh and associate materials to a specific set of points/cells? I am remembering of the multi-texture support in VTK, where I had two sets of texture coordinates which allowed me to combine two textures at different parts of a unique mesh.

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, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <andinet.enqu at kitware.com<mailto:andinet.enqu at kitware.com>> wrote:
I would think we will need a scene graph support at some point in iMSTK

For example,

https://www.sofa-framework.org/community/doc/main-principles/scene-graph/

On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Yes, it's very common to have this functionality, and many meshes we have use this. Currently, I have to individually export each material as a separate mesh, but this gets tedious when you end up with hundreds of meshes and have to separate/export each one individually. Also, managing these is a pain. Note that a single face can only have one material assigned to it (i.e., not layered materials).

We still don't have the scene graph, but what if we introduce one and then when you import a mesh it adds a new node (called MeshGroup) under root (the scene) and then nodes (meshes) under the MeshGroup? Or it could be called MeshObject or something, etc.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Monday, September 18, 2017 11:03 AM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Multiple materials per import

Having mesh split and maintained as separate pieces might complicate imstk's geometry mappers. Do you have a use case from one of the projects?

On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
This question has a subtle difference compared to a previous question I asked before, but should we add support for mesh files with multiple materials?

When the mesh gets imported, the regions with a different material would get split into a new mesh. Or should we introduce a new primitive such as a MeshGroup to handle this? Or should we keep them as separate, unrelated meshes?

_______________________________________________
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
Director of Medical Computing
Kitware, Inc.

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



_______________________________________________
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.




--
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.




--
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/20170925/03601c25/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MeshGroup.png
Type: image/png
Size: 165521 bytes
Desc: MeshGroup.png
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/03601c25/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partitionedMesh.png
Type: image/png
Size: 59696 bytes
Desc: partitionedMesh.png
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/03601c25/attachment-0003.png>

From sreekanth.arikatla at kitware.com  Mon Sep 25 17:59:44 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Mon, 25 Sep 2017 17:59:44 -0400
Subject: [Imstk-developers] Multiple materials per import
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AF79F@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF10E@ex14mb4.win.rpi.edu>
 <CAJFrbF+MrWGMv-viA=SwY568JQw8wg3tYxc2d87q1u4GNXLFHQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF12F@ex14mb4.win.rpi.edu>
 <CANrU599-tpGrwjckm=K0Fh8HfRuaU96dTo3QOcm5XW4cT3p6uw@mail.gmail.com>
 <CAG1Y6mDNkQ85Xdv4zmYcOf+2=Es8AgnCNR_TfneypWrDY35p+w@mail.gmail.com>
 <CAJFrbF+Viy9D1LqEMirwUaRNrdpoXB+pKoJZsiP6_sGavUqmPA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF6F1@ex14mb4.win.rpi.edu>
 <CAJFrbFLpX-vGvnuUrFOK+CCg1T2nhnyb-U6jvn8UokhDJHVpvA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF716@ex14mb4.win.rpi.edu>
 <CAJFrbF+7bK0BbO4XN_OuAqutqdeb9YggXfpyZidr2bVeDDN1LA@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF731@ex14mb4.win.rpi.edu>
 <CAJFrbFLOqXdWS35iXk1JGkZAL8nFe=uGT4eJHW0oBb-NGEiKyQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF760@ex14mb4.win.rpi.edu>
 <CAJFrbFLF7R48YSwUN_DUecrx0RAjkKof_Y_PF0KmooS8jukTYg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF79F@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbF+VGkiTGXAWXUUH9imL6Cuvpe-n5sCwGJuxTBvN7gYDYg@mail.gmail.com>

I use tetrahedral render delegate for bone drilling simulation. All the
faces of each tetrahedra are rendered so that when new surfaces are created
due to drilling nothing special needs to be done to render them. This is
not ideal though. It could be safe to assume these render delegates will be
used for debug rendering purposes that way realistic rendering with
multiple materials is supported only for the surface mesh. Anyway, we can
discuss this further during the weekly meeting/

On Mon, Sep 25, 2017 at 5:45 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> What I mean for materials is render materials. Currently, if you were to
> import a mesh, these regions wouldn't be contiguous if they had different
> render materials. There are a few exceptions to this such as Vega, but
> that's because there's not render material information. I wouldn't expect
> there to be multiple render materials to on a single deformable mesh.
>
> Anyway, if we do this, then we will need to create an imstkRenderMesh
> class or something similar. Also, what do the hexahedral and tetrahedral
> render delegates do? I haven't seen an example of it and not sure how they
> factor in to this.
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Monday, September 25, 2017 5:11 PM
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
>
> *Subject:* Re: [Imstk-developers] Multiple materials per import
>
> Hi Nick,
>             Case 1 and 2 are very different from physics POV. They are
> treated as different bodies and there are formulations that work with
> contacts of non-conformal meshes. Yes, we don't encounter many different
> materials in physics but if we were to reach high fidelity, we could have
> graded physics material property which could mean each element could have a
> slightly different material property compared to its neighbors. Having this
> generally doesn't come with an additional computational cost.
>
> In this regard, rendering is more flexible. For example non-contiguous
> medium (eg: two organs touching each other) can be treated as one by the
> rendering is given that one takes care of the details about intersecting
> primitives that you mentioned.
>
> As far as the user is concerned he/she is modifying what they are seeing
> i.e., the rendering mesh (eg: pattern cutting simulation). But behind the
> scenes, all associated mesh representations (physics, collision, rendering)
> have to be modified in a *consistent* manner. This essentially means that
> we have to modify the geometry maps.
>
> On Mon, Sep 25, 2017 at 4:50 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> imo Case 1 and 2 are the same (they share vertices along material edges).
>> On mesh import, the vertices will be duplicated along each edge though (it
>> works somewhat this way currently for different UV coordinates), so the
>> connectivity data gets separated anyway per region at least with the Assimp
>> importer. I'm not sure if you currently remesh this data though to
>> eliminate duplicates. Maybe with Vega meshes it's different though.
>>
>> I don't think it's a common use case for deformable meshes to have
>> multiple materials. Even if they did, it would likely be a very small
>> number of materials, and it could possibly by represented by a custom
>> shader. It's more for things like tools/environmental objects. If we map
>> geometries, then we need to maintain render mesh data structures as well.
>> I'm not sure what's supposed to happen if the user modifies the render mesh
>> (or can they?). What do you think?
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Monday, September 25, 2017 4:23 PM
>> *To:* Milef, Nicholas Boris; imstk-developers at imstk.org
>>
>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>
>> Hi Nick,
>>             I think there are two cases here:
>>
>> 1. Representing geometry of a *continuous object *with multiple meshes
>> which could otherwise be represented using a single mesh
>>
>> ?
>> 2. Representing the body with an assembly of components with different
>> meshes.
>>
>> ?
>> *Physics*:
>>
>> For the case 1, physics module can accept this but as a single mesh with
>> each region optionally having different material properties. It is possible
>> to treat them as separate meshes, but the formulation becomes unnecessarily
>> complex. For case 2, each part of the assembly is modeled as a separate
>> physics objects; and hence separate scene objects (since for example, the
>> car is non-contiguous). The contact interactions between the component
>> meshes will have to be defined which is a different matter.
>>
>> *Rendering*:
>>
>> I think rendering can also work if each partition is treated as different
>> mesh in case 1. If this is done, then there will be a 1-to-many kind of
>> geometry map when updating the visual meshes after each physics frame. To
>> make this possible we can extend the current maps additionally introducing
>> mesh id.
>> There could be a rare case of many-to-1 (for car example) but I don't see
>> much use for it.
>>
>>
>>
>> On Mon, Sep 25, 2017 at 2:25 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> Why couldn't we just split up the mesh on import into multiple
>>> (physics/visual) meshes?
>>> ------------------------------
>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>> *Sent:* Monday, September 25, 2017 1:42 PM
>>> *To:* Milef, Nicholas Boris
>>>
>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>
>>> After this change, single physics mesh can map to a group of rendering
>>> meshes. We might have to add the mesh ids to know which render mesh the
>>> primitive belongs to.
>>>
>>> On Mon, Sep 25, 2017 at 12:44 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>>> wrote:
>>>
>>>> Ok we could do that for imstkSceneObject (allow setting of multiple
>>>> visual meshes). This would mean that mesh readers could import multiple
>>>> geometries. Why would we need mesh IDs though?
>>>> ------------------------------
>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>> *Sent:* Monday, September 25, 2017 12:16 PM
>>>> *To:* Milef, Nicholas Boris
>>>> *Cc:* Alexis Girault; imstk-developers at imstk.org
>>>>
>>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>>
>>>> We already support multiple physics materials (thanks to Vega!) within
>>>> the same mesh in iMSTK. One can define something called regions and assign
>>>> different material properties for each region. Based on your described,
>>>> this seems to be not practical for the case of render materials.
>>>>
>>>> One solution could be to have the visual geometry be composed of
>>>> multiple meshes (optionally) while the physics and collision geometries are
>>>> composed of one mesh-like now. In that case, we need to add mesh IDs in
>>>> addition to primitive ID in the geometry mappers.
>>>>
>>>> On Mon, Sep 25, 2017 at 11:56 AM, Milef, Nicholas Boris <milefn at rpi.edu
>>>> > wrote:
>>>>
>>>>> @Sreekanth, The meshes wouldn't be numbered contiguously in this case.
>>>>> They would just be separate surface meshes. An example would be a car mesh.
>>>>> You would have the tires with one material, body with another material,
>>>>> windows with another, etc, so they would all belong to a car object but be
>>>>> separate meshes. I think this makes sense as well for when you implement
>>>>> materials for physics (with different friction coefficients, etc.).
>>>>>
>>>>> @Alexis, No we shouldn't disassociate the mesh from the material. By
>>>>> applying the material per set of points, you risk having noncontiguous
>>>>> triangles in this case. Also, down the line it makes it difficult to batch
>>>>> draw objects similar materials.
>>>>>
>>>>> Multiple UV channel support (VTK multitexturing) doesn't relate to
>>>>> this problem. In practice, multiple UV coords are only useful for
>>>>> lightmapping or some very specialized use cases. Different meshes belonging
>>>>> to a larger mesh (object) don't need unique UVs, they just need unique
>>>>> textures.
>>>>> ------------------------------
>>>>> *From:* Imstk-developers [imstk-developers-bounces at imstk.org] on
>>>>> behalf of Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>>> *Sent:* Monday, September 25, 2017 11:15 AM
>>>>> *To:* Alexis Girault
>>>>>
>>>>> *Cc:* imstk-developers at imstk.org
>>>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>>>
>>>>> We don't support multiple meshes for the same object in doing the
>>>>> physics. However, if two non-connected meshes are numbered contiguously the
>>>>> physics treats it as one but still simulates two bodies. This is generally
>>>>> not done though since there is not much of a use case. It could happen at
>>>>> runtime when one cuts a mesh into two (eg: pattern cutting simulator).
>>>>>
>>>>> On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <
>>>>> alexis.girault at kitware.com> wrote:
>>>>>
>>>>>> We wouldn't want to confuse geometries (mesh, etc...) with objects
>>>>>> (scene object), which would be part of a scene graph when the needs come.
>>>>>>
>>>>>> Sreekanth: wouldn't creating multiple meshes for a unique object be a
>>>>>> problem to handle physics?
>>>>>>
>>>>>> Nick: do we need to dissociate meshes per material? Could we retain a
>>>>>> unique mesh and associate materials to a specific set of points/cells? I am
>>>>>> remembering of the multi-texture support in VTK, where I had two sets of
>>>>>> texture coordinates which allowed me to combine two textures at different
>>>>>> parts of a unique mesh.
>>>>>>
>>>>>> Alexis Girault
>>>>>> R&D Engineer in Medical Computing
>>>>>> Kitware, Inc.
>>>>>>
>>>>>> http://www.kitware.com
>>>>>> (919) 969-6990 x325
>>>>>>
>>>>>> On Mon, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <
>>>>>> andinet.enqu at kitware.com> wrote:
>>>>>>
>>>>>>> I would think we will need a scene graph support at some point in
>>>>>>> iMSTK
>>>>>>>
>>>>>>> For example,
>>>>>>>
>>>>>>> https://www.sofa-framework.org/community/doc/main-principles
>>>>>>> /scene-graph/
>>>>>>>
>>>>>>> On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <
>>>>>>> milefn at rpi.edu> wrote:
>>>>>>>
>>>>>>>> Yes, it's very common to have this functionality, and many meshes
>>>>>>>> we have use this. Currently, I have to individually export each material as
>>>>>>>> a separate mesh, but this gets tedious when you end up with hundreds of
>>>>>>>> meshes and have to separate/export each one individually. Also, managing
>>>>>>>> these is a pain. Note that a single face can only have one material
>>>>>>>> assigned to it (i.e., not layered materials).
>>>>>>>>
>>>>>>>> We still don't have the scene graph, but what if we introduce one
>>>>>>>> and then when you import a mesh it adds a new node (called MeshGroup) under
>>>>>>>> root (the scene) and then nodes (meshes) under the MeshGroup? Or it could
>>>>>>>> be called MeshObject or something, etc.
>>>>>>>> ------------------------------
>>>>>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>>>>>> *Sent:* Monday, September 18, 2017 11:03 AM
>>>>>>>> *To:* Milef, Nicholas Boris
>>>>>>>> *Cc:* imstk-developers at imstk.org
>>>>>>>> *Subject:* Re: [Imstk-developers] Multiple materials per import
>>>>>>>>
>>>>>>>> Having mesh split and maintained as separate pieces might
>>>>>>>> complicate imstk's geometry mappers. Do you have a use case from one of the
>>>>>>>> projects?
>>>>>>>>
>>>>>>>> On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <
>>>>>>>> milefn at rpi.edu> wrote:
>>>>>>>>
>>>>>>>>> This question has a subtle difference compared to a previous
>>>>>>>>> question I asked before, but should we add support for mesh files with
>>>>>>>>> multiple materials?
>>>>>>>>>
>>>>>>>>> When the mesh gets imported, the regions with a different material
>>>>>>>>> would get split into a new mesh. Or should we introduce a new primitive
>>>>>>>>> such as a MeshGroup to handle this? Or should we keep them as separate,
>>>>>>>>> unrelated meshes?
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>> Director of Medical Computing
>>>>>>> Kitware, Inc.
>>>>>>>
>>>>>>> http://www.kitware.com
>>>>>>> (919) 969-6990 x311 <%28919%29%20969-6990%20x311>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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.
>>>>
>>>>
>>>
>>>
>>> --
>>> 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.
>>
>>
>
>
> --
> 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/20170925/87b70240/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MeshGroup.png
Type: image/png
Size: 165521 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/87b70240/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: partitionedMesh.png
Type: image/png
Size: 59696 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170925/87b70240/attachment-0003.png>

From milefn at rpi.edu  Tue Sep 26 12:03:53 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Tue, 26 Sep 2017 16:03:53 +0000
Subject: [Imstk-developers] Creating billboard particle effects (e.g., smoke,
	fire)
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF862@ex14mb4.win.rpi.edu>

What would be the best way to create a billboard particle effect (for things such as smoke or fire)?

Example:
http://www.opengl-tutorial.org/intermediate-tutorials/billboards-particles/particles-instancing/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170926/48464fbf/attachment.html>

From milefn at rpi.edu  Tue Sep 26 12:08:31 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Tue, 26 Sep 2017 16:08:31 +0000
Subject: [Imstk-developers] Creating billboard particle effects (e.g.,
 smoke, fire)
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AF862@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF862@ex14mb4.win.rpi.edu>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF88D@ex14mb4.win.rpi.edu>

Sorry wrong mailing list...
________________________________
From: Imstk-developers [imstk-developers-bounces at imstk.org] on behalf of Milef, Nicholas Boris [milefn at rpi.edu]
Sent: Tuesday, September 26, 2017 12:03 PM
To: imstk-developers at imstk.org
Subject: [Imstk-developers] Creating billboard particle effects (e.g., smoke, fire)

What would be the best way to create a billboard particle effect (for things such as smoke or fire)?

Example:
http://www.opengl-tutorial.org/intermediate-tutorials/billboards-particles/particles-instancing/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170926/f30aa270/attachment.html>

From milefn at rpi.edu  Wed Sep 27 16:05:30 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Wed, 27 Sep 2017 20:05:30 +0000
Subject: [Imstk-developers] MD5 issue with libusb
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF9A1@ex14mb4.win.rpi.edu>

Has anyone been having issues with libusb recently? I'm getting an MD5 mismatch. On Windows, it can't compile because of this (you would need to do a new clone).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170927/b5da8689/attachment.html>

From dzenan.zukic at kitware.com  Wed Sep 27 16:21:58 2017
From: dzenan.zukic at kitware.com (Dzenan Zukic)
Date: Wed, 27 Sep 2017 16:21:58 -0400
Subject: [Imstk-developers] MD5 issue with libusb
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AF9A1@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF9A1@ex14mb4.win.rpi.edu>
Message-ID: <CAPmoeGaRO1SmKk8guCj-uREp2Rjpk3ZQoqTKU=efLdzX=sN3mw@mail.gmail.com>

If SourceForge is not down or corrupted, they might have updated the .7z
file which contains the source by some minor version. That is a plausible
explanation for MD5 mismatch. Or an error in downloading. This is
speculation, I haven't compiled iMSTK in a while.

D?enan Zuki?, PhD, Senior R&D Engineer, Kitware (Carrboro, N.C.)

On Wed, Sep 27, 2017 at 4:05 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Has anyone been having issues with libusb recently? I'm getting an MD5
> mismatch. On Windows, it can't compile because of this (you would need to
> do a new clone).
>
> _______________________________________________
> 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/20170927/f7045a15/attachment.html>

From milefn at rpi.edu  Wed Sep 27 16:34:31 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Wed, 27 Sep 2017 20:34:31 +0000
Subject: [Imstk-developers] MD5 issue with libusb
In-Reply-To: <CAPmoeGaRO1SmKk8guCj-uREp2Rjpk3ZQoqTKU=efLdzX=sN3mw@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF9A1@ex14mb4.win.rpi.edu>,
 <CAPmoeGaRO1SmKk8guCj-uREp2Rjpk3ZQoqTKU=efLdzX=sN3mw@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AF9BE@ex14mb4.win.rpi.edu>

What's strange is that I can download it (or rather CMake downloads it). The last update on SourceForge was in January, which was before the MD5 hash was changed in iMSTK. The MD5 hash on SourceForge matches what's in the CMake file.
________________________________
From: Dzenan Zukic [dzenan.zukic at kitware.com]
Sent: Wednesday, September 27, 2017 4:21 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] MD5 issue with libusb

If SourceForge is not down or corrupted, they might have updated the .7z file which contains the source by some minor version. That is a plausible explanation for MD5 mismatch. Or an error in downloading. This is speculation, I haven't compiled iMSTK in a while.

D?enan Zuki?, PhD, Senior R&D Engineer, Kitware (Carrboro, N.C.)

On Wed, Sep 27, 2017 at 4:05 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Has anyone been having issues with libusb recently? I'm getting an MD5 mismatch. On Windows, it can't compile because of this (you would need to do a new clone).

_______________________________________________
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/20170927/40f41f9e/attachment.html>

From dzenan.zukic at kitware.com  Wed Sep 27 16:45:47 2017
From: dzenan.zukic at kitware.com (Dzenan Zukic)
Date: Wed, 27 Sep 2017 16:45:47 -0400
Subject: [Imstk-developers] MD5 issue with libusb
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AF9BE@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF9A1@ex14mb4.win.rpi.edu>
 <CAPmoeGaRO1SmKk8guCj-uREp2Rjpk3ZQoqTKU=efLdzX=sN3mw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF9BE@ex14mb4.win.rpi.edu>
Message-ID: <CAPmoeGaJA2nRbPwVNvXP8cWnDv-KZN14MFkQtRzarvJ26rczgw@mail.gmail.com>

Maybe some download was incomplete. Try deleting the downloaded file and
see if it is correctly re-downloaded when you configure.

D?enan Zuki?, PhD, Senior R&D Engineer, Kitware (Carrboro, N.C.)

On Wed, Sep 27, 2017 at 4:34 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> What's strange is that I can download it (or rather CMake downloads it).
> The last update on SourceForge was in January, which was before the MD5
> hash was changed in iMSTK. The MD5 hash on SourceForge matches what's in
> the CMake file.
> ------------------------------
> *From:* Dzenan Zukic [dzenan.zukic at kitware.com]
> *Sent:* Wednesday, September 27, 2017 4:21 PM
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] MD5 issue with libusb
>
> If SourceForge is not down or corrupted, they might have updated the .7z
> file which contains the source by some minor version. That is a plausible
> explanation for MD5 mismatch. Or an error in downloading. This is
> speculation, I haven't compiled iMSTK in a while.
>
> D?enan Zuki?, PhD, Senior R&D Engineer, Kitware (Carrboro, N.C.)
>
> On Wed, Sep 27, 2017 at 4:05 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Has anyone been having issues with libusb recently? I'm getting an MD5
>> mismatch. On Windows, it can't compile because of this (you would need to
>> do a new clone).
>>
>> _______________________________________________
>> 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/20170927/dd880650/attachment.html>

From milefn at rpi.edu  Wed Sep 27 17:23:50 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Wed, 27 Sep 2017 21:23:50 +0000
Subject: [Imstk-developers] MD5 issue with libusb
In-Reply-To: <CAPmoeGaJA2nRbPwVNvXP8cWnDv-KZN14MFkQtRzarvJ26rczgw@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF9A1@ex14mb4.win.rpi.edu>
 <CAPmoeGaRO1SmKk8guCj-uREp2Rjpk3ZQoqTKU=efLdzX=sN3mw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF9BE@ex14mb4.win.rpi.edu>,
 <CAPmoeGaJA2nRbPwVNvXP8cWnDv-KZN14MFkQtRzarvJ26rczgw@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AFA01@ex14mb4.win.rpi.edu>

I tried that, but it didn't work. It turns out the .7z file that's downloaded during the build process is corrupted (couldn't unzip it). I downloaded it manually and it's working now. I cloned the iMSTK a second time, and it had the same problem. I'm not sure if it's SourceForge corrupting the file. It was like this yesterday too.
________________________________
From: Dzenan Zukic [dzenan.zukic at kitware.com]
Sent: Wednesday, September 27, 2017 4:45 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] MD5 issue with libusb

Maybe some download was incomplete. Try deleting the downloaded file and see if it is correctly re-downloaded when you configure.

D?enan Zuki?, PhD, Senior R&D Engineer, Kitware (Carrboro, N.C.)

On Wed, Sep 27, 2017 at 4:34 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
What's strange is that I can download it (or rather CMake downloads it). The last update on SourceForge was in January, which was before the MD5 hash was changed in iMSTK. The MD5 hash on SourceForge matches what's in the CMake file.
________________________________
From: Dzenan Zukic [dzenan.zukic at kitware.com<mailto:dzenan.zukic at kitware.com>]
Sent: Wednesday, September 27, 2017 4:21 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] MD5 issue with libusb

If SourceForge is not down or corrupted, they might have updated the .7z file which contains the source by some minor version. That is a plausible explanation for MD5 mismatch. Or an error in downloading. This is speculation, I haven't compiled iMSTK in a while.

D?enan Zuki?, PhD, Senior R&D Engineer, Kitware (Carrboro, N.C.)

On Wed, Sep 27, 2017 at 4:05 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Has anyone been having issues with libusb recently? I'm getting an MD5 mismatch. On Windows, it can't compile because of this (you would need to do a new clone).

_______________________________________________
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/20170927/0d49601d/attachment-0001.html>

From alexis.girault at kitware.com  Wed Sep 27 17:27:22 2017
From: alexis.girault at kitware.com (Alexis Girault)
Date: Wed, 27 Sep 2017 17:27:22 -0400
Subject: [Imstk-developers] MD5 issue with libusb
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AFA01@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF9A1@ex14mb4.win.rpi.edu>
 <CAPmoeGaRO1SmKk8guCj-uREp2Rjpk3ZQoqTKU=efLdzX=sN3mw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF9BE@ex14mb4.win.rpi.edu>
 <CAPmoeGaJA2nRbPwVNvXP8cWnDv-KZN14MFkQtRzarvJ26rczgw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFA01@ex14mb4.win.rpi.edu>
Message-ID: <CAG1Y6mAEMXHxjRfjXBuhZR_SHAdONnQoNiT06Ar=-rjCh+5gAw@mail.gmail.com>

We had problems yesterday, it seems that sourceforge just has some on and
off issues with their servers:
- 2 days ago:  https://twitter.com/sfnet_ops/status/912673956712341514
- today: https://twitter.com/sfnet_ops/status/913044025791467520

Current downloaded package from their server is corrupted, the MD5
check works properly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170927/41faecea/attachment.html>

From milefn at rpi.edu  Wed Sep 27 17:32:20 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Wed, 27 Sep 2017 21:32:20 +0000
Subject: [Imstk-developers] MD5 issue with libusb
In-Reply-To: <CAG1Y6mAEMXHxjRfjXBuhZR_SHAdONnQoNiT06Ar=-rjCh+5gAw@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF9A1@ex14mb4.win.rpi.edu>
 <CAPmoeGaRO1SmKk8guCj-uREp2Rjpk3ZQoqTKU=efLdzX=sN3mw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF9BE@ex14mb4.win.rpi.edu>
 <CAPmoeGaJA2nRbPwVNvXP8cWnDv-KZN14MFkQtRzarvJ26rczgw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFA01@ex14mb4.win.rpi.edu>,
 <CAG1Y6mAEMXHxjRfjXBuhZR_SHAdONnQoNiT06Ar=-rjCh+5gAw@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AFA1A@ex14mb4.win.rpi.edu>

Ok, that's good to know!
________________________________
From: Alexis Girault [alexis.girault at kitware.com]
Sent: Wednesday, September 27, 2017 5:27 PM
To: Milef, Nicholas Boris
Cc: Dzenan Zukic; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] MD5 issue with libusb

We had problems yesterday, it seems that sourceforge just has some on and off issues with their servers:
- 2 days ago:  https://twitter.com/sfnet_ops/status/912673956712341514
- today: https://twitter.com/sfnet_ops/status/913044025791467520

Current downloaded package from their server is corrupted, the MD5 check works properly.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170927/87a6c5cf/attachment.html>

From alexis.girault at kitware.com  Thu Sep 28 11:17:58 2017
From: alexis.girault at kitware.com (Alexis Girault)
Date: Thu, 28 Sep 2017 11:17:58 -0400
Subject: [Imstk-developers] MD5 issue with libusb
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AFA1A@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AF9A1@ex14mb4.win.rpi.edu>
 <CAPmoeGaRO1SmKk8guCj-uREp2Rjpk3ZQoqTKU=efLdzX=sN3mw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AF9BE@ex14mb4.win.rpi.edu>
 <CAPmoeGaJA2nRbPwVNvXP8cWnDv-KZN14MFkQtRzarvJ26rczgw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFA01@ex14mb4.win.rpi.edu>
 <CAG1Y6mAEMXHxjRfjXBuhZR_SHAdONnQoNiT06Ar=-rjCh+5gAw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFA1A@ex14mb4.win.rpi.edu>
Message-ID: <CAG1Y6mCK8NXJYPo2sLnXx+qX+M7bNu22CuYL2OX1RmQKeJa9Ew@mail.gmail.com>

https://twitter.com/sfnet_ops/status/913183031111929857 ?

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

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

On Wed, Sep 27, 2017 at 5:32 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Ok, that's good to know!
> ------------------------------
> *From:* Alexis Girault [alexis.girault at kitware.com]
> *Sent:* Wednesday, September 27, 2017 5:27 PM
> *To:* Milef, Nicholas Boris
> *Cc:* Dzenan Zukic; imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] MD5 issue with libusb
>
> We had problems yesterday, it seems that sourceforge just has some on and
> off issues with their servers:
> - 2 days ago:  https://twitter.com/sfnet_ops/status/912673956712341514
> - today: https://twitter.com/sfnet_ops/status/913044025791467520
>
> Current downloaded package from their server is corrupted, the MD5
> check works properly.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170928/f30ee36a/attachment.html>

From milefn at rpi.edu  Fri Sep 29 13:56:26 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 29 Sep 2017 17:56:26 +0000
Subject: [Imstk-developers] Mesh load factor
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>

What do you all think about a mesh load factor? I would like to add one to prevent a range of allocations issues (fragmentation, invalid allocations, etc.) when resizing a mesh. This would be able to be customized by the user of course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170929/62b879bc/attachment.html>

From sreekanth.arikatla at kitware.com  Fri Sep 29 15:50:09 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Fri, 29 Sep 2017 15:50:09 -0400
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>

Can you explain a bit more? Do you plan to do a fresh allocation when
resizing mesh beyond a certain size to prevent fragmentation?

On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> What do you all think about a mesh load factor? I would like to add one to
> prevent a range of allocations issues (fragmentation, invalid allocations,
> etc.) when resizing a mesh. This would be able to be customized by the user
> of course.
>
> _______________________________________________
> 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/20170929/b044e049/attachment.html>

From milefn at rpi.edu  Fri Sep 29 15:54:35 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 29 Sep 2017 19:54:35 +0000
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>,
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>

Well, I was thinking of just having a limit. So if you load a mesh that's 10k vertices, and it's load factor is 2x, then you can't add more than 20k vertices.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Friday, September 29, 2017 3:50 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Mesh load factor

Can you explain a bit more? Do you plan to do a fresh allocation when resizing mesh beyond a certain size to prevent fragmentation?

On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
What do you all think about a mesh load factor? I would like to add one to prevent a range of allocations issues (fragmentation, invalid allocations, etc.) when resizing a mesh. This would be able to be customized by the user of course.

_______________________________________________
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/20170929/7f987d1e/attachment.html>

From sreekanth.arikatla at kitware.com  Fri Sep 29 15:56:41 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Fri, 29 Sep 2017 15:56:41 -0400
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>

sounds good. Can we call it 'resizing factor' then?

On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Well, I was thinking of just having a limit. So if you load a mesh that's
> 10k vertices, and it's load factor is 2x, then you can't add more than 20k
> vertices.
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Friday, September 29, 2017 3:50 PM
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Mesh load factor
>
> Can you explain a bit more? Do you plan to do a fresh allocation when
> resizing mesh beyond a certain size to prevent fragmentation?
>
> On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> What do you all think about a mesh load factor? I would like to add one
>> to prevent a range of allocations issues (fragmentation, invalid
>> allocations, etc.) when resizing a mesh. This would be able to be
>> customized by the user of course.
>>
>> _______________________________________________
>> 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/20170929/55bbed66/attachment.html>

From sreekanth.arikatla at kitware.com  Fri Sep 29 16:00:29 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Fri, 29 Sep 2017 16:00:29 -0400
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>
 <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>
Message-ID: <CAJFrbFKEYLPTr8N7+fo5P6YW+x=uRvfnBtQy2-LFaaEuOQp65Q@mail.gmail.com>

The number of different instances the resizing happened also influences the
fragmentation.

On Fri, Sep 29, 2017 at 3:56 PM, Sreekanth Arikatla <
sreekanth.arikatla at kitware.com> wrote:

> sounds good. Can we call it 'resizing factor' then?
>
> On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Well, I was thinking of just having a limit. So if you load a mesh that's
>> 10k vertices, and it's load factor is 2x, then you can't add more than 20k
>> vertices.
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Friday, September 29, 2017 3:50 PM
>> *To:* Milef, Nicholas Boris
>> *Cc:* imstk-developers at imstk.org
>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>
>> Can you explain a bit more? Do you plan to do a fresh allocation when
>> resizing mesh beyond a certain size to prevent fragmentation?
>>
>> On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> What do you all think about a mesh load factor? I would like to add one
>>> to prevent a range of allocations issues (fragmentation, invalid
>>> allocations, etc.) when resizing a mesh. This would be able to be
>>> customized by the user of course.
>>>
>>> _______________________________________________
>>> 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.
>
>


-- 
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/20170929/3ff52113/attachment-0001.html>

From milefn at rpi.edu  Fri Sep 29 16:00:59 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 29 Sep 2017 20:00:59 +0000
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>,
 <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AFB8A@ex14mb4.win.rpi.edu>

Well, it's really a load factor:
https://en.wikipedia.org/wiki/Load_factor

________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Friday, September 29, 2017 3:56 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Mesh load factor

sounds good. Can we call it 'resizing factor' then?

On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Well, I was thinking of just having a limit. So if you load a mesh that's 10k vertices, and it's load factor is 2x, then you can't add more than 20k vertices.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Friday, September 29, 2017 3:50 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Mesh load factor

Can you explain a bit more? Do you plan to do a fresh allocation when resizing mesh beyond a certain size to prevent fragmentation?

On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
What do you all think about a mesh load factor? I would like to add one to prevent a range of allocations issues (fragmentation, invalid allocations, etc.) when resizing a mesh. This would be able to be customized by the user of course.

_______________________________________________
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.




--
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/20170929/f2796761/attachment.html>

From milefn at rpi.edu  Fri Sep 29 16:01:29 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 29 Sep 2017 20:01:29 +0000
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <CAJFrbFKEYLPTr8N7+fo5P6YW+x=uRvfnBtQy2-LFaaEuOQp65Q@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>
 <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>,
 <CAJFrbFKEYLPTr8N7+fo5P6YW+x=uRvfnBtQy2-LFaaEuOQp65Q@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AFB97@ex14mb4.win.rpi.edu>

What do you mean by this?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Friday, September 29, 2017 4:00 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Mesh load factor

The number of different instances the resizing happened also influences the fragmentation.

On Fri, Sep 29, 2017 at 3:56 PM, Sreekanth Arikatla <sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>> wrote:
sounds good. Can we call it 'resizing factor' then?

On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Well, I was thinking of just having a limit. So if you load a mesh that's 10k vertices, and it's load factor is 2x, then you can't add more than 20k vertices.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Friday, September 29, 2017 3:50 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Mesh load factor

Can you explain a bit more? Do you plan to do a fresh allocation when resizing mesh beyond a certain size to prevent fragmentation?

On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
What do you all think about a mesh load factor? I would like to add one to prevent a range of allocations issues (fragmentation, invalid allocations, etc.) when resizing a mesh. This would be able to be customized by the user of course.

_______________________________________________
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.




--
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/20170929/c2bea103/attachment.html>

From sreekanth.arikatla at kitware.com  Fri Sep 29 16:13:36 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Fri, 29 Sep 2017 16:13:36 -0400
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AFB97@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>
 <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>
 <CAJFrbFKEYLPTr8N7+fo5P6YW+x=uRvfnBtQy2-LFaaEuOQp65Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB97@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFJ2Qcyf8tEcDn3hYkjqGjSMWzhUoOR+FH9=_1dAEeZ0Sw@mail.gmail.com>

I know what load factor means in mech/aero fields. There is a common theme
to the definition of load factor in different fields and that doesn't seem
to be applicable here. 'Load factor' definition in comp sci there seems to
be in the context of hash tables, which seems apt.

What I mean is if you end up with 20k verts from 10k with resizing 100
times is different from that with resizing once. To overcome all of this
one generally, does a preallocation with the upper limit of the
expected size.

On Fri, Sep 29, 2017 at 4:01 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> What do you mean by this?
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Friday, September 29, 2017 4:00 PM
>
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Mesh load factor
>
> The number of different instances the resizing happened also influences
> the fragmentation.
>
> On Fri, Sep 29, 2017 at 3:56 PM, Sreekanth Arikatla <
> sreekanth.arikatla at kitware.com> wrote:
>
>> sounds good. Can we call it 'resizing factor' then?
>>
>> On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> Well, I was thinking of just having a limit. So if you load a mesh
>>> that's 10k vertices, and it's load factor is 2x, then you can't add more
>>> than 20k vertices.
>>> ------------------------------
>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>> *Sent:* Friday, September 29, 2017 3:50 PM
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* imstk-developers at imstk.org
>>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>>
>>> Can you explain a bit more? Do you plan to do a fresh allocation when
>>> resizing mesh beyond a certain size to prevent fragmentation?
>>>
>>> On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>>> wrote:
>>>
>>>> What do you all think about a mesh load factor? I would like to add one
>>>> to prevent a range of allocations issues (fragmentation, invalid
>>>> allocations, etc.) when resizing a mesh. This would be able to be
>>>> customized by the user of course.
>>>>
>>>> _______________________________________________
>>>> 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.
>>
>>
>
>
> --
> 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/20170929/59e71176/attachment-0001.html>

From milefn at rpi.edu  Fri Sep 29 16:30:52 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 29 Sep 2017 20:30:52 +0000
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <CAJFrbFJ2Qcyf8tEcDn3hYkjqGjSMWzhUoOR+FH9=_1dAEeZ0Sw@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>
 <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>
 <CAJFrbFKEYLPTr8N7+fo5P6YW+x=uRvfnBtQy2-LFaaEuOQp65Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB97@ex14mb4.win.rpi.edu>,
 <CAJFrbFJ2Qcyf8tEcDn3hYkjqGjSMWzhUoOR+FH9=_1dAEeZ0Sw@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AFBB7@ex14mb4.win.rpi.edu>

Sorry, I didn't mean in mechanical or aeronautics. I was more pointing towards its use in CS, electrical, and passenger load factor. But if it's confusing we can choose a new name (e.g., maxStorageFactor).

The limit doesn't change with each resize if that's what you're saying. You specify an upper limit (either an absolute limit or a scale from the original geometry, not sure which one is more appropriate). Then once you reach that limit, you get a warning and no more vertices can be added.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Friday, September 29, 2017 4:13 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Mesh load factor

I know what load factor means in mech/aero fields. There is a common theme to the definition of load factor in different fields and that doesn't seem to be applicable here. 'Load factor' definition in comp sci there seems to be in the context of hash tables, which seems apt.

What I mean is if you end up with 20k verts from 10k with resizing 100 times is different from that with resizing once. To overcome all of this one generally, does a preallocation with the upper limit of the expected size.

On Fri, Sep 29, 2017 at 4:01 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
What do you mean by this?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Friday, September 29, 2017 4:00 PM

To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Mesh load factor

The number of different instances the resizing happened also influences the fragmentation.

On Fri, Sep 29, 2017 at 3:56 PM, Sreekanth Arikatla <sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>> wrote:
sounds good. Can we call it 'resizing factor' then?

On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Well, I was thinking of just having a limit. So if you load a mesh that's 10k vertices, and it's load factor is 2x, then you can't add more than 20k vertices.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Friday, September 29, 2017 3:50 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Mesh load factor

Can you explain a bit more? Do you plan to do a fresh allocation when resizing mesh beyond a certain size to prevent fragmentation?

On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
What do you all think about a mesh load factor? I would like to add one to prevent a range of allocations issues (fragmentation, invalid allocations, etc.) when resizing a mesh. This would be able to be customized by the user of course.

_______________________________________________
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.




--
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.




--
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/20170929/221676ee/attachment.html>

From sreekanth.arikatla at kitware.com  Fri Sep 29 16:50:45 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Fri, 29 Sep 2017 16:50:45 -0400
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AFBB7@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>
 <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>
 <CAJFrbFKEYLPTr8N7+fo5P6YW+x=uRvfnBtQy2-LFaaEuOQp65Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB97@ex14mb4.win.rpi.edu>
 <CAJFrbFJ2Qcyf8tEcDn3hYkjqGjSMWzhUoOR+FH9=_1dAEeZ0Sw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFBB7@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbFJS6fqXdZbCvTepGuGLtuQ6Ak9G-8HLjd9cjK4QDorz8w@mail.gmail.com>

Sorry, all of my answers were assuming that preallocation to upper limit
was not the strategy. If one preallocates to the limit load factor makes
sense. I think it makes sense to set the upper limit to a certain factor of
the original size.

On Fri, Sep 29, 2017 at 4:30 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Sorry, I didn't mean in mechanical or aeronautics. I was more pointing
> towards its use in CS, electrical, and passenger load factor. But if it's
> confusing we can choose a new name (e.g., maxStorageFactor).
>
> The limit doesn't change with each resize if that's what you're saying.
> You specify an upper limit (either an absolute limit or a scale from the
> original geometry, not sure which one is more appropriate). Then once you
> reach that limit, you get a warning and no more vertices can be added.
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Friday, September 29, 2017 4:13 PM
>
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Mesh load factor
>
> I know what load factor means in mech/aero fields. There is a common theme
> to the definition of load factor in different fields and that doesn't seem
> to be applicable here. 'Load factor' definition in comp sci there seems to
> be in the context of hash tables, which seems apt.
>
> What I mean is if you end up with 20k verts from 10k with resizing 100
> times is different from that with resizing once. To overcome all of this
> one generally, does a preallocation with the upper limit of the
> expected size.
>
> On Fri, Sep 29, 2017 at 4:01 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> What do you mean by this?
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Friday, September 29, 2017 4:00 PM
>>
>> *To:* Milef, Nicholas Boris
>> *Cc:* imstk-developers at imstk.org
>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>
>> The number of different instances the resizing happened also influences
>> the fragmentation.
>>
>> On Fri, Sep 29, 2017 at 3:56 PM, Sreekanth Arikatla <
>> sreekanth.arikatla at kitware.com> wrote:
>>
>>> sounds good. Can we call it 'resizing factor' then?
>>>
>>> On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>>> wrote:
>>>
>>>> Well, I was thinking of just having a limit. So if you load a mesh
>>>> that's 10k vertices, and it's load factor is 2x, then you can't add more
>>>> than 20k vertices.
>>>> ------------------------------
>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>> *Sent:* Friday, September 29, 2017 3:50 PM
>>>> *To:* Milef, Nicholas Boris
>>>> *Cc:* imstk-developers at imstk.org
>>>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>>>
>>>> Can you explain a bit more? Do you plan to do a fresh allocation when
>>>> resizing mesh beyond a certain size to prevent fragmentation?
>>>>
>>>> On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>>>> wrote:
>>>>
>>>>> What do you all think about a mesh load factor? I would like to add
>>>>> one to prevent a range of allocations issues (fragmentation, invalid
>>>>> allocations, etc.) when resizing a mesh. This would be able to be
>>>>> customized by the user of course.
>>>>>
>>>>> _______________________________________________
>>>>> 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.
>>>
>>>
>>
>>
>> --
>> 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.
>
>


-- 
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/20170929/d44298d9/attachment-0001.html>

From milefn at rpi.edu  Fri Sep 29 17:11:47 2017
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 29 Sep 2017 21:11:47 +0000
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <CAJFrbFJS6fqXdZbCvTepGuGLtuQ6Ak9G-8HLjd9cjK4QDorz8w@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>
 <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>
 <CAJFrbFKEYLPTr8N7+fo5P6YW+x=uRvfnBtQy2-LFaaEuOQp65Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB97@ex14mb4.win.rpi.edu>
 <CAJFrbFJ2Qcyf8tEcDn3hYkjqGjSMWzhUoOR+FH9=_1dAEeZ0Sw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFBB7@ex14mb4.win.rpi.edu>,
 <CAJFrbFJS6fqXdZbCvTepGuGLtuQ6Ak9G-8HLjd9cjK4QDorz8w@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E30E96AFC01@ex14mb4.win.rpi.edu>

Ok, now that makes more sense! I'll make an MR for this soon since this is pretty simple.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
Sent: Friday, September 29, 2017 4:50 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Mesh load factor

Sorry, all of my answers were assuming that preallocation to upper limit was not the strategy. If one preallocates to the limit load factor makes sense. I think it makes sense to set the upper limit to a certain factor of the original size.

On Fri, Sep 29, 2017 at 4:30 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Sorry, I didn't mean in mechanical or aeronautics. I was more pointing towards its use in CS, electrical, and passenger load factor. But if it's confusing we can choose a new name (e.g., maxStorageFactor).

The limit doesn't change with each resize if that's what you're saying. You specify an upper limit (either an absolute limit or a scale from the original geometry, not sure which one is more appropriate). Then once you reach that limit, you get a warning and no more vertices can be added.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Friday, September 29, 2017 4:13 PM

To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Mesh load factor

I know what load factor means in mech/aero fields. There is a common theme to the definition of load factor in different fields and that doesn't seem to be applicable here. 'Load factor' definition in comp sci there seems to be in the context of hash tables, which seems apt.

What I mean is if you end up with 20k verts from 10k with resizing 100 times is different from that with resizing once. To overcome all of this one generally, does a preallocation with the upper limit of the expected size.

On Fri, Sep 29, 2017 at 4:01 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
What do you mean by this?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Friday, September 29, 2017 4:00 PM

To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Mesh load factor

The number of different instances the resizing happened also influences the fragmentation.

On Fri, Sep 29, 2017 at 3:56 PM, Sreekanth Arikatla <sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>> wrote:
sounds good. Can we call it 'resizing factor' then?

On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Well, I was thinking of just having a limit. So if you load a mesh that's 10k vertices, and it's load factor is 2x, then you can't add more than 20k vertices.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Friday, September 29, 2017 3:50 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Mesh load factor

Can you explain a bit more? Do you plan to do a fresh allocation when resizing mesh beyond a certain size to prevent fragmentation?

On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
What do you all think about a mesh load factor? I would like to add one to prevent a range of allocations issues (fragmentation, invalid allocations, etc.) when resizing a mesh. This would be able to be customized by the user of course.

_______________________________________________
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.




--
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.




--
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/20170929/0ed82690/attachment.html>

From sreekanth.arikatla at kitware.com  Fri Sep 29 17:17:58 2017
From: sreekanth.arikatla at kitware.com (Sreekanth Arikatla)
Date: Fri, 29 Sep 2017 17:17:58 -0400
Subject: [Imstk-developers] Mesh load factor
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E30E96AFC01@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E30E96AFB4D@ex14mb4.win.rpi.edu>
 <CAJFrbFK+FjWpRbKdphsONVvZhTxAEpFAfXsUn5mB3T2CC1Awsg@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB73@ex14mb4.win.rpi.edu>
 <CAJFrbFJd3pknkdbNxJVKjuD7t4D-GquXFSJP6rbitod++0Z2ew@mail.gmail.com>
 <CAJFrbFKEYLPTr8N7+fo5P6YW+x=uRvfnBtQy2-LFaaEuOQp65Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFB97@ex14mb4.win.rpi.edu>
 <CAJFrbFJ2Qcyf8tEcDn3hYkjqGjSMWzhUoOR+FH9=_1dAEeZ0Sw@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFBB7@ex14mb4.win.rpi.edu>
 <CAJFrbFJS6fqXdZbCvTepGuGLtuQ6Ak9G-8HLjd9cjK4QDorz8w@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E30E96AFC01@ex14mb4.win.rpi.edu>
Message-ID: <CAJFrbF+jOwWzP0fD4=Wf7iSG3GSme4E07p1GscvE-TWJE5tA_w@mail.gmail.com>

Sounds good. Thanks.

On Fri, Sep 29, 2017 at 5:11 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Ok, now that makes more sense! I'll make an MR for this soon since this is
> pretty simple.
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Friday, September 29, 2017 4:50 PM
>
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Mesh load factor
>
> Sorry, all of my answers were assuming that preallocation to upper limit
> was not the strategy. If one preallocates to the limit load factor makes
> sense. I think it makes sense to set the upper limit to a certain factor of
> the original size.
>
> On Fri, Sep 29, 2017 at 4:30 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Sorry, I didn't mean in mechanical or aeronautics. I was more pointing
>> towards its use in CS, electrical, and passenger load factor. But if it's
>> confusing we can choose a new name (e.g., maxStorageFactor).
>>
>> The limit doesn't change with each resize if that's what you're saying.
>> You specify an upper limit (either an absolute limit or a scale from the
>> original geometry, not sure which one is more appropriate). Then once you
>> reach that limit, you get a warning and no more vertices can be added.
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Friday, September 29, 2017 4:13 PM
>>
>> *To:* Milef, Nicholas Boris
>> *Cc:* imstk-developers at imstk.org
>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>
>> I know what load factor means in mech/aero fields. There is a common
>> theme to the definition of load factor in different fields and that doesn't
>> seem to be applicable here. 'Load factor' definition in comp sci there
>> seems to be in the context of hash tables, which seems apt.
>>
>> What I mean is if you end up with 20k verts from 10k with resizing 100
>> times is different from that with resizing once. To overcome all of this
>> one generally, does a preallocation with the upper limit of the
>> expected size.
>>
>> On Fri, Sep 29, 2017 at 4:01 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> What do you mean by this?
>>> ------------------------------
>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>> *Sent:* Friday, September 29, 2017 4:00 PM
>>>
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* imstk-developers at imstk.org
>>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>>
>>> The number of different instances the resizing happened also influences
>>> the fragmentation.
>>>
>>> On Fri, Sep 29, 2017 at 3:56 PM, Sreekanth Arikatla <
>>> sreekanth.arikatla at kitware.com> wrote:
>>>
>>>> sounds good. Can we call it 'resizing factor' then?
>>>>
>>>> On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>>>> wrote:
>>>>
>>>>> Well, I was thinking of just having a limit. So if you load a mesh
>>>>> that's 10k vertices, and it's load factor is 2x, then you can't add more
>>>>> than 20k vertices.
>>>>> ------------------------------
>>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>>> *Sent:* Friday, September 29, 2017 3:50 PM
>>>>> *To:* Milef, Nicholas Boris
>>>>> *Cc:* imstk-developers at imstk.org
>>>>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>>>>
>>>>> Can you explain a bit more? Do you plan to do a fresh allocation when
>>>>> resizing mesh beyond a certain size to prevent fragmentation?
>>>>>
>>>>> On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>>>> > wrote:
>>>>>
>>>>>> What do you all think about a mesh load factor? I would like to add
>>>>>> one to prevent a range of allocations issues (fragmentation, invalid
>>>>>> allocations, etc.) when resizing a mesh. This would be able to be
>>>>>> customized by the user of course.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>>
>>>>
>>>
>>>
>>> --
>>> 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.
>>
>>
>
>
> --
> 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/20170929/a9c33714/attachment-0001.html>