<div dir="ltr">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/</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 25, 2017 at 5:45 PM, Milef, Nicholas Boris <span dir="ltr"><<a href="mailto:milefn@rpi.edu" target="_blank">milefn@rpi.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>

<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">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.

<div><br>

</div>

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

<div>

<div>

<div>

<div style="font-family:Times New Roman;color:#000000;font-size:16px">

<hr>

<div id="m_-3539218541596294682divRpF453368" style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Sreekanth Arikatla [<a href="mailto:sreekanth.arikatla@kitware.com" target="_blank">sreekanth.arikatla@kitware.<wbr>com</a>]<br>

<b>Sent:</b> Monday, September 25, 2017 5:11 PM<br>

<b>To:</b> Milef, Nicholas Boris<br>

<b>Cc:</b> <a href="mailto:imstk-developers@imstk.org" target="_blank">imstk-developers@imstk.org</a><div><div class="h5"><br>

<b>Subject:</b> Re: [Imstk-developers] Multiple materials per import<br>

</div></div></font><br>

</div><div><div class="h5">

<div></div>

<div>

<div dir="ltr">Hi Nick,

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

<div><br>

</div>

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

<div><br>

</div>

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

<i>consistent</i> manner. This essentially means that we have to modify the geometry maps.</div>

</div>

<div class="gmail_extra"><br>

<div class="gmail_quote">On Mon, Sep 25, 2017 at 4:50 PM, Milef, Nicholas Boris <span dir="ltr">

<<a href="mailto:milefn@rpi.edu" target="_blank">milefn@rpi.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>

<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">

<div>

<div style="font-family:Tahoma;font-size:13px">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.

</div>

<div style="font-family:Tahoma;font-size:13px"><br>

</div>

<div style="font-family:Tahoma;font-size:13px">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?</div>

</div>

<div style="font-family:Times New Roman;color:#000000;font-size:16px">

<hr>

<div id="m_-3539218541596294682m_-7736204380821454230divRpF341025" style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Sreekanth Arikatla [<a href="mailto:sreekanth.arikatla@kitware.com" target="_blank">sreekanth.arikatla@kitware.co<wbr>m</a>]<br>

<b>Sent:</b> Monday, September 25, 2017 4:23 PM<br>

<b>To:</b> Milef, Nicholas Boris; <a href="mailto:imstk-developers@imstk.org" target="_blank">

imstk-developers@imstk.org</a>

<div>

<div class="m_-3539218541596294682h5"><br>

<b>Subject:</b> Re: [Imstk-developers] Multiple materials per import<br>

</div>

</div>

</font><br>

</div>

<div>

<div class="m_-3539218541596294682h5">

<div></div>

<div>

<div dir="ltr">Hi Nick,

<div>            I think there are two cases here:</div>

<div><br>

</div>

<div>1. Representing geometry of a <i>continuous object </i>with multiple meshes which could otherwise be represented using a single mesh </div>

<div><img src="cid:ii_j80m4cs40_15ebaae358d9d605" style="margin-right:0px" height="138" width="137"><br>

</div>

<div>2. Representing the body with an assembly of components with different meshes.

<div><img src="cid:ii_j80m56x71_15ebaaecdc9303bf" style="margin-right:0px" height="118" width="263"><br>

<br>

</div>

<div><u>Physics</u>:</div>

<div><br>

</div>

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

<div><br>

</div>

<div><u>Rendering</u>: </div>

</div>

<div><br>

</div>

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

<div>There could be a rare case of many-to-1 (for car example) but I don't see much use for it.</div>

<div><br>

</div>

<div><br>

</div>

</div>

<div class="gmail_extra"><br>

<div class="gmail_quote">On Mon, Sep 25, 2017 at 2:25 PM, Milef, Nicholas Boris <span dir="ltr">

<<a href="mailto:milefn@rpi.edu" target="_blank">milefn@rpi.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>

<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">Why couldn't we just split up the mesh on import into multiple (physics/visual) meshes?

<div style="font-family:Times New Roman;color:#000000;font-size:16px">

<hr>

<div id="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739divRpF103134" style="direction:ltr">

<font face="Tahoma" size="2" color="#000000"><b>From:</b> Sreekanth Arikatla [<a href="mailto:sreekanth.arikatla@kitware.com" target="_blank">sreekanth.arikatla@kitware.co<wbr>m</a>]<br>

<b>Sent:</b> Monday, September 25, 2017 1:42 PM<br>

<b>To:</b> Milef, Nicholas Boris

<div>

<div class="m_-3539218541596294682m_-7736204380821454230h5"><br>

<b>Subject:</b> Re: [Imstk-developers] Multiple materials per import<br>

</div>

</div>

</font><br>

</div>

<div>

<div class="m_-3539218541596294682m_-7736204380821454230h5">

<div></div>

<div>

<div dir="ltr">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.</div>

<div class="gmail_extra"><br>

<div class="gmail_quote">On Mon, Sep 25, 2017 at 12:44 PM, Milef, Nicholas Boris <span dir="ltr">

<<a href="mailto:milefn@rpi.edu" target="_blank">milefn@rpi.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>

<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">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?

<div style="font-family:Times New Roman;color:#000000;font-size:16px">

<hr>

<div id="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853divRpF320720" style="direction:ltr">

<font face="Tahoma" size="2" color="#000000"><b>From:</b> Sreekanth Arikatla [<a href="mailto:sreekanth.arikatla@kitware.com" target="_blank">sreekanth.arikatla@kitware.co<wbr>m</a>]<br>

<b>Sent:</b> Monday, September 25, 2017 12:16 PM<br>

<b>To:</b> Milef, Nicholas Boris<br>

<b>Cc:</b> Alexis Girault; <a href="mailto:imstk-developers@imstk.org" target="_blank">

imstk-developers@imstk.org</a>

<div>

<div class="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739h5"><br>

<b>Subject:</b> Re: [Imstk-developers] Multiple materials per import<br>

</div>

</div>

</font><br>

</div>

<div>

<div class="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739h5">

<div></div>

<div>

<div dir="ltr">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. 

<div><br>

</div>

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

</div>

<div class="gmail_extra"><br>

<div class="gmail_quote">On Mon, Sep 25, 2017 at 11:56 AM, Milef, Nicholas Boris <span dir="ltr">

<<a href="mailto:milefn@rpi.edu" target="_blank">milefn@rpi.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>

<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">@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.).

<div><br>

</div>

<div>

<div>

<div style="font-family:Tahoma;font-size:13px">@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.</div>

<div style="font-family:Tahoma;font-size:13px"><br>

</div>

<div style="font-family:Tahoma;font-size:13px">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.</div>

</div>

<div style="font-family:Times New Roman;color:#000000;font-size:16px">

<hr>

<div id="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853m_-4740301227001859167divRpF358465" style="direction:ltr">

<font face="Tahoma" size="2" color="#000000"><b>From:</b> Imstk-developers [<a href="mailto:imstk-developers-bounces@imstk.org" target="_blank">imstk-developers-bounces@imst<wbr>k.org</a>] on behalf of Sreekanth Arikatla [<a href="mailto:sreekanth.arikatla@kitware.com" target="_blank">sreekanth.arikatla@kitware.co<wbr>m</a>]<br>

<b>Sent:</b> Monday, September 25, 2017 11:15 AM<br>

<b>To:</b> Alexis Girault

<div>

<div class="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853h5"><br>

<b>Cc:</b> <a href="mailto:imstk-developers@imstk.org" target="_blank">imstk-developers@imstk.org</a><br>

<b>Subject:</b> Re: [Imstk-developers] Multiple materials per import<br>

</div>

</div>

</font><br>

</div>

<div>

<div class="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853h5">

<div></div>

<div>

<div dir="ltr">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).</div>

<div class="gmail_extra"><br>

<div class="gmail_quote">On Mon, Sep 25, 2017 at 11:01 AM, Alexis Girault <span dir="ltr">

<<a href="mailto:alexis.girault@kitware.com" target="_blank">alexis.girault@kitware.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">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.

<div><br>

</div>

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

<div><br>

</div>

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

</div>

<div class="gmail_extra"><br clear="all">

<div>

<div class="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853m_-4740301227001859167m_6037747778528189034gmail_signature">

<div dir="ltr">

<div>

<div dir="ltr">

<div>

<div dir="ltr">

<div>

<div dir="ltr"><span style="color:rgb(136,136,136);font-size:12.8000001907349px">Alexis Girault</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px">

<span style="color:rgb(136,136,136);font-size:12.8000001907349px">R&D Engineer in Medical Computing</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px">

<span style="color:rgb(136,136,136);font-size:12.8000001907349px">Kitware, Inc.</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px">

<br style="color:rgb(136,136,136);font-size:12.8000001907349px">

<a href="http://www.kitware.com/" rel="noreferrer" style="color:rgb(17,85,204);font-size:12.8000001907349px" target="_blank">http://www.kitware.com</a><br style="color:rgb(136,136,136);font-size:12.8000001907349px">

<font color="#999999"><a href="tel:(919)+969-6990+x325" target="_blank"><span style="font-size:12.8000001907349px">(919) 969-6990 x3</span>25</a></font><br>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

<div>

<div class="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853m_-4740301227001859167h5">

<br>

<div class="gmail_quote">On Mon, Sep 18, 2017 at 12:09 PM, Andinet Enquobahrie <span dir="ltr">

<<a href="mailto:andinet.enqu@kitware.com" target="_blank">andinet.enqu@kitware.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">I would think we will need a scene graph support at some point in iMSTK

<div><br>

</div>

<div>For example, </div>

<div><br>

</div>

<div><a href="https://www.sofa-framework.org/community/doc/main-principles/scene-graph/" target="_blank">https://www.sofa-framework.org<wbr>/community/doc/main-principles<wbr>/scene-graph/</a><br>

</div>

</div>

<div class="gmail_extra">

<div>

<div class="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853m_-4740301227001859167m_6037747778528189034h5">

<br>

<div class="gmail_quote">On Mon, Sep 18, 2017 at 11:39 AM, Milef, Nicholas Boris <span dir="ltr">

<<a href="mailto:milefn@rpi.edu" target="_blank">milefn@rpi.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>

<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">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).

<div><br>

</div>

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

<div style="font-family:Times New Roman;color:#000000;font-size:16px">

<hr>

<div id="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853m_-4740301227001859167m_6037747778528189034m_747261469178364450m_6395143672425168747divRpF403336" style="direction:ltr">

<font face="Tahoma" size="2" color="#000000"><b>From:</b> Sreekanth Arikatla [<a href="mailto:sreekanth.arikatla@kitware.com" target="_blank">sreekanth.arikatla@kitware.co<wbr>m</a>]<br>

<b>Sent:</b> Monday, September 18, 2017 11:03 AM<br>

<b>To:</b> Milef, Nicholas Boris<br>

<b>Cc:</b> <a href="mailto:imstk-developers@imstk.org" target="_blank">imstk-developers@imstk.org</a><br>

<b>Subject:</b> Re: [Imstk-developers] Multiple materials per import<br>

</font><br>

</div>

<div>

<div class="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853m_-4740301227001859167m_6037747778528189034m_747261469178364450h5">

<div></div>

<div>

<div dir="ltr">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?</div>

<div class="gmail_extra"><br>

<div class="gmail_quote">On Mon, Sep 18, 2017 at 10:52 AM, Milef, Nicholas Boris <span dir="ltr">

<<a href="mailto:milefn@rpi.edu" target="_blank">milefn@rpi.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>

<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">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?

<div><br>

</div>

<div>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?</div>

</div>

</div>

<br>

______________________________<wbr>_________________<br>

Imstk-developers mailing list<br>

<a href="mailto:Imstk-developers@imstk.org" target="_blank">Imstk-developers@imstk.org</a><br>

<a href="http://public.kitware.com/mailman/listinfo/imstk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/imstk-developers</a><br>

<br>

</blockquote>

</div>

<br>

<br clear="all">

<div><br>

</div>

-- <br>

<div class="m_-3539218541596294682m_-7736204380821454230m_7287046973266263739m_4735321368414952853m_-4740301227001859167m_6037747778528189034m_747261469178364450m_6395143672425168747gmail_signature">

<div dir="ltr">

<div>

<div dir="ltr">

<div>

<div dir="ltr">

<div>

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">Sreekanth Arikatla, Ph.D.,</div>

<div dir="ltr">Senior R&D Engineer,</div>