[Imstk-developers] Clearing surface mesh data on intialization

Milef, Nicholas Boris milefn at rpi.edu
Fri Jul 28 12:27:06 EDT 2017


At that point, shouldn't the user be required to set all the components themselves instead of calling initialize() again? That's basically what they're doing anyway since they have to set all of their components when they call initialize() again. VTK kind of does it this way for a lot of things where you set a bunch of components and then Modify() (or in our case initialize()) the object so that everything gets done in the correct order to avoid too much global state.

I know you can do this after initialization, but the problem is that the user has to remember to do this, and in the correct order too. If they compute the seams before setting the normals, they won't get the correct results. I realize I can do this properly in the readers, but for people who make their own meshes, this isn't automatic, when imo it should be. It just complicates things for the users, but there's no reason this shouldn't be done for every surface mesh. I'll probably just use Sreekanth's suggestion for this with another overloaded function (I thought this was being used elsewhere besides the readers, so I wasn't sure if this had an impact). It's possible that we'll need to do this for other things in the future, so I wanted to avoid overloading as much as possible.

In SoFMIS, one of the problems people had from a usability perspective was that they had to call a lot of mesh post-processing manually after reading in a mesh, but it wasn't always clear what should be done and when it should be done especially as we add more dependent steps (such as calculating tangents), so they often didn't got correct rendering. Do you recalculate normals after the tangents or before? When do you call the UV seams function? What happens if you don't call a certain function? This has surprisingly caused a lot of headaches when it came to proper mesh display, so it would have been nice if this was all done properly on initialization since every surface mesh needs these.
________________________________
From: Alexis Girault [alexis.girault at kitware.com]
Sent: Friday, July 28, 2017 11:31 AM
To: Milef, Nicholas Boris
Cc: Sreekanth Arikatla; imstk-developers at imstk.org
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

It is a legit a safety measure: if someone calls initialize, he will modify vertices and connectivity. In that case, any other mesh data won't be consistent and should be disregarded.

If you get the normals from the reader, set them after initializing and you can still compute the UVs seam following the initialization, no need to do it multiple times.

If someone purposefully re-initialize a mesh explicitly, he will get a clean mesh with new vertices and connectivity, and that's his job to set/compute what he needs following that.

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 Fri, Jul 28, 2017 at 11:22 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
It's not a problem with adding the normals. It's a problem with computing the UV seams as these depend on the normals. Ideally, you would do this in the initialization function because this should only be done once as it's not super cheap to compute the UV seams.

We can have the users explicitly call this, but this is another function that needs to be called every time you make a surface mesh. If the initialize function only ever gets called once (in the reader or when you create the surface mesh), then clearing the data members doesn't make sense in this case.
________________________________
From: Alexis Girault [alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>]
Sent: Friday, July 28, 2017 11:11 AM

To: Milef, Nicholas Boris
Cc: Sreekanth Arikatla; imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

I don't see the issue then: Initialize is called first to setup vertices and connectivity, then additional fields can be manually added (like normals). Could you just make sure you keep adding the normals after initializing the 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 Fri, Jul 28, 2017 at 11:08 AM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
@Alexis
It's here, but I set up the normals afterwards right now since they get cleared on initialization:
https://gitlab.kitware.com/iMSTK/iMSTK/blob/master/Base/Geometry/Reader/imstkAssimpMeshIO.cpp#L101

@Sreekanth
They can't really be recomputed afterwards. At that point, it would be up to the user to specify or recompute this once they can ensure the normals are correct. It can only be computed before the iMSTK normal calculation takes place. Otherwise the important information is lost.

We could require the user to explicitly call the compute UV seams, but I have a feeling people just won't do this :)
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Thursday, July 27, 2017 9:17 PM

To: Milef, Nicholas Boris
Cc: Alexis Girault; imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

Hi Nick,
            When you set new data shouldn't the seam vertices from the prior data be cleared too since they are invalid? If needed the seam vertices should be recomputed for the new data?

On Thu, Jul 27, 2017 at 7:31 PM, Alexis Girault <alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>> wrote:
Not where `clear` is called, where `initialize` is called. (What calls that functio<https://gitlab.kitware.com/iMSTK/iMSTK/blob/master/Base/Geometry/Mesh/imstkSurfaceMesh.cpp#L27-29>n after you set up the normals: )

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 Thu, Jul 27, 2017 at 6:44 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Yeah:
https://gitlab.kitware.com/iMSTK/iMSTK/blob/master/Base/Geometry/Mesh/imstkSurfaceMesh.cpp#L31
https://gitlab.kitware.com/iMSTK/iMSTK/blob/master/Base/Geometry/Mesh/imstkSurfaceMesh.cpp#L50

________________________________
From: Alexis Girault [alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>]
Sent: Thursday, July 27, 2017 6:42 PM
To: Milef, Nicholas Boris; Sreekanth Arikatla

Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization


Could you point us out in the code to where initialize is called which deletes your normals?

On Thu, Jul 27, 2017, 18:37 Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
The issue is still there. I can put the UV seam code before all of the clears, but if the user for some reason calls this function and gives different vertices/triangles, then it won't work properly with the new data. This is because the normals and the UV seam vertices won't correspond to each other.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Thursday, July 27, 2017 6:26 PM
To: Milef, Nicholas Boris

Cc: Alexis Girault; imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization
Not a problem!

On Thu, Jul 27, 2017 at 6:22 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Yeah, sorry about that!
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Thursday, July 27, 2017 6:20 PM

To: Milef, Nicholas Boris
Cc: Alexis Girault; imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

I see, it must have reported Initialize methods from physics that are not related to this.

On Thu, Jul 27, 2017 at 6:14 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
@Alexis But why should it be overwriting the normals? That's not derived data.

@Sreekanth I wasn't reading carefully enough. I tried to find all references, but apparently Visual Studio finds everything with the same name as the method, not necessarily the surface mesh's method. Sorry about that.

________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Thursday, July 27, 2017 6:04 PM
To: Milef, Nicholas Boris
Cc: Alexis Girault; imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>

Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

Initialize is called at the setup phase by readers as well as when the user creates the data. It is supposed to be only called only for initialization and reinitialization with new data. Can you point me where it is called in the physics?

On Thu, Jul 27, 2017 at 5:57 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Actually, to clarify, I don't think it's a big deal if it's used in the physics classes, as long as it doesn't modify an already built mesh as I describe in the previous message. I don't know what type of impact the normals have in the physics classes.
________________________________
From: Imstk-developers [imstk-developers-bounces at imstk.org<mailto:imstk-developers-bounces at imstk.org>] on behalf of Milef, Nicholas Boris [milefn at rpi.edu<mailto:milefn at rpi.edu>]
Sent: Thursday, July 27, 2017 5:53 PM
To: Alexis Girault

Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

If it were only called in the readers, I wouldn't have a problem with it. But it's called in some of the physics classes too. It also clears data such as normals that's been set (i.e., by the readers). I need some of that data though to fix the UV seams.

For meshes, Assimp is told to generate smooth normals and to join identical normals. For most vertices, this works as intended, but for vertices on UV seams, they can't be joined. Assimp smooths those vertices by treating them as a single vertex, which I would want as the intended behavior. So I need to go through all of the vertices and find the ones with the same normals and positions, but the normals get cleared by the initialize function. Assimp's behavior is correct (I can't think of another way we would want it to deal with these problems).
________________________________
From: Alexis Girault [alexis.girault at kitware.com<mailto:alexis.girault at kitware.com>]
Sent: Thursday, July 27, 2017 5:26 PM
To: Milef, Nicholas Boris
Cc: Sreekanth Arikatla; imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

Is `initialize` only used in the readers currently? I believe the goal of that function was just to set vertices, triangles, or any other topology information needed in a single function. It should only be used after the constructor as a utility as far as I understand, so there shouldn't be data already set in the mesh at that point.

When/where is this function currently called and creating an issue in your case?

Also, I think the `clear `should only delete the derived data computed by the initialization input. Is it doing more than that now which would explain why it deletes your data?

I think having an `initialize` function that clears derived data fields and set core parameters is good, we need to make sure it is called at a good place and does not remove some unexpected fields (but I just think it should be called before you try to set any data in it)

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 Thu, Jul 27, 2017 at 5:03 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
For now, I can just put the seam computation before the clear. However, this will break if the vertex order changes or something like that. Basically, what I'm trying to say is that I would want users to know explicitly if they're messing up their data. A reinitialize function doesn't convey this imo.
________________________________
From: Imstk-developers [imstk-developers-bounces at imstk.org<mailto:imstk-developers-bounces at imstk.org>] on behalf of Milef, Nicholas Boris [milefn at rpi.edu<mailto:milefn at rpi.edu>]
Sent: Thursday, July 27, 2017 4:47 PM
To: Sreekanth Arikatla

Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

I guess where I'm stuck at is why we have an initialize function to begin with. I still can't think of a use-case where we can't either 1) make a new mesh or 2) modify the components of the old mesh.
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Thursday, July 27, 2017 4:37 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

Hi Nick,
            If you want to preserve the normals, you can add normals to the Initialize function arg. If the normals are supplied, initialize clears the previous data before assigning.

On Thu, Jul 27, 2017 at 4:01 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
No, I don't. I need to preserve the original normals that ASSIMP imports because ASSIMP calculates the normals correctly. Otherwise, I can't identify the UV seams.

I can just do this computation in the SurfaceMeshRenderDelegate, but I'm not sure if the normals are used elsewhere after reinitializing the meshes. But isn't reinitializing a mesh dangerous in a multithreaded environment anyway?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Thursday, July 27, 2017 3:55 PM

To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

It could be used in some cases depending on the scenario. Do you plan to call this at every frame?


On Thu, Jul 27, 2017 at 3:53 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
Is that a useful use case though? Why not just make a new mesh?
________________________________
From: Sreekanth Arikatla [sreekanth.arikatla at kitware.com<mailto:sreekanth.arikatla at kitware.com>]
Sent: Thursday, July 27, 2017 3:52 PM
To: Milef, Nicholas Boris
Cc: imstk-developers at imstk.org<mailto:imstk-developers at imstk.org>
Subject: Re: [Imstk-developers] Clearing surface mesh data on intialization

Hi Nick,
            This is cleared in case one wants to reinitialize the mesh with a different data. Initialize should only be called at initilization or at runtime if the mesh data itself changes.

On Thu, Jul 27, 2017 at 3:31 PM, Milef, Nicholas Boris <milefn at rpi.edu<mailto:milefn at rpi.edu>> wrote:
I'm modifying the SurfaceMesh class currently, but why is all the data cleared on initialization? Is this necessary? I ask because I need this data to correct for the normals seams.

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


_______________________________________________
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/20170728/e0dc235b/attachment-0001.html>


More information about the Imstk-developers mailing list