[Imstk-developers] Multiple materials per import

Mon Sep 25 12:16:23 EDT 2017

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>