[Imstk-developers] Multiple materials per import

[Sreekanth Arikatla]

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>