[Imstk-developers] Clearing surface mesh data on intialization

Thu Jul 27 19:31:53 EDT 2017

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
(919) 969-6990 x325

On Thu, Jul 27, 2017 at 6:44 PM, Milef, Nicholas Boris <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]
> *Sent:* Thursday, July 27, 2017 6:42 PM
> *To:* Milef, Nicholas Boris; Sreekanth Arikatla
>
> *Cc:* 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> 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]
>> *Sent:* Thursday, July 27, 2017 6:26 PM
>> *To:* Milef, Nicholas Boris
>>
>> *Cc:* Alexis Girault; 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>
>> wrote:
>>
>>> Yeah, sorry about that!
>>> ------------------------------
>>> *From:* Sreekanth Arikatla [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
>>> *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>
>>> 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]
>>>> *Sent:* Thursday, July 27, 2017 6:04 PM
>>>> *To:* Milef, Nicholas Boris
>>>> *Cc:* Alexis Girault; 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>
>>>> 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] on
>>>>> behalf of Milef, Nicholas Boris [milefn at rpi.edu]
>>>>> *Sent:* Thursday, July 27, 2017 5:53 PM
>>>>> *To:* Alexis Girault
>>>>>
>>>>> *Cc:* 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]
>>>>> *Sent:* Thursday, July 27, 2017 5:26 PM
>>>>> *To:* Milef, Nicholas Boris
>>>>> *Cc:* Sreekanth Arikatla; 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
>>>>> (919) 969-6990 x325
>>>>>
>>>>> On Thu, Jul 27, 2017 at 5:03 PM, Milef, Nicholas Boris <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] on
>>>>>> behalf of Milef, Nicholas Boris [milefn at rpi.edu]
>>>>>> *Sent:* Thursday, July 27, 2017 4:47 PM
>>>>>> *To:* Sreekanth Arikatla
>>>>>>
>>>>>> *Cc:* 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]
>>>>>> *Sent:* Thursday, July 27, 2017 4:37 PM
>>>>>> *To:* Milef, Nicholas Boris
>>>>>> *Cc:* 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> 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]
>>>>>>> *Sent:* Thursday, July 27, 2017 3:55 PM
>>>>>>>
>>>>>>> *To:* Milef, Nicholas Boris
>>>>>>> *Cc:* 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> wrote:
>>>>>>>
>>>>>>>> Is that a useful use case though? Why not just make a new mesh?
>>>>>>>> ------------------------------
>>>>>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>>>>>> *Sent:* Thursday, July 27, 2017 3:52 PM
>>>>>>>> *To:* Milef, Nicholas Boris
>>>>>>>> *Cc:* 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> 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
>>>>>>>>> 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
>>>>>> 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.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170727/643f0de4/attachment-0001.html>