[Imstk-developers] Clearing surface mesh data on intialization

Sreekanth Arikatla sreekanth.arikatla at kitware.com
Thu Jul 27 18:20:46 EDT 2017


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170727/a77cc4a0/attachment-0001.html>


More information about the Imstk-developers mailing list