[Imstk-developers] Clearing surface mesh data on intialization

Thu Jul 27 18:07:44 EDT 2017

Yes. Like I said, the initialize does what it should imo, but shouldn't be
used after reading/setup, since that is when it should be initialized.
Could you point us to where this is happening? We should probably just
replace it by setting the correct fields again.

On Thu, Jul 27, 2017, 17:53 Milef, Nicholas Boris <milefn at rpi.edu> wrote:

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