[Imstk-developers] Clearing surface mesh data on intialization

Thu Jul 27 18:26:47 EDT 2017

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/dff6388b/attachment-0001.html>