[Imstk-developers] Mesh load factor

[Sreekanth Arikatla]

Sounds good. Thanks.

On Fri, Sep 29, 2017 at 5:11 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Ok, now that makes more sense! I'll make an MR for this soon since this is
> pretty simple.
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Friday, September 29, 2017 4:50 PM
>
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Mesh load factor
>
> Sorry, all of my answers were assuming that preallocation to upper limit
> was not the strategy. If one preallocates to the limit load factor makes
> sense. I think it makes sense to set the upper limit to a certain factor of
> the original size.
>
> On Fri, Sep 29, 2017 at 4:30 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Sorry, I didn't mean in mechanical or aeronautics. I was more pointing
>> towards its use in CS, electrical, and passenger load factor. But if it's
>> confusing we can choose a new name (e.g., maxStorageFactor).
>>
>> The limit doesn't change with each resize if that's what you're saying.
>> You specify an upper limit (either an absolute limit or a scale from the
>> original geometry, not sure which one is more appropriate). Then once you
>> reach that limit, you get a warning and no more vertices can be added.
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Friday, September 29, 2017 4:13 PM
>>
>> *To:* Milef, Nicholas Boris
>> *Cc:* imstk-developers at imstk.org
>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>
>> I know what load factor means in mech/aero fields. There is a common
>> theme to the definition of load factor in different fields and that doesn't
>> seem to be applicable here. 'Load factor' definition in comp sci there
>> seems to be in the context of hash tables, which seems apt.
>>
>> What I mean is if you end up with 20k verts from 10k with resizing 100
>> times is different from that with resizing once. To overcome all of this
>> one generally, does a preallocation with the upper limit of the
>> expected size.
>>
>> On Fri, Sep 29, 2017 at 4:01 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>> wrote:
>>
>>> What do you mean by this?
>>> ------------------------------
>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>> *Sent:* Friday, September 29, 2017 4:00 PM
>>>
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* imstk-developers at imstk.org
>>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>>
>>> The number of different instances the resizing happened also influences
>>> the fragmentation.
>>>
>>> On Fri, Sep 29, 2017 at 3:56 PM, Sreekanth Arikatla <
>>> sreekanth.arikatla at kitware.com> wrote:
>>>
>>>> sounds good. Can we call it 'resizing factor' then?
>>>>
>>>> On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>>>> wrote:
>>>>
>>>>> Well, I was thinking of just having a limit. So if you load a mesh
>>>>> that's 10k vertices, and it's load factor is 2x, then you can't add more
>>>>> than 20k vertices.
>>>>> ------------------------------
>>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>>> *Sent:* Friday, September 29, 2017 3:50 PM
>>>>> *To:* Milef, Nicholas Boris
>>>>> *Cc:* imstk-developers at imstk.org
>>>>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>>>>
>>>>> Can you explain a bit more? Do you plan to do a fresh allocation when
>>>>> resizing mesh beyond a certain size to prevent fragmentation?
>>>>>
>>>>> On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>>>> > wrote:
>>>>>
>>>>>> What do you all think about a mesh load factor? I would like to add
>>>>>> one to prevent a range of allocations issues (fragmentation, invalid
>>>>>> allocations, etc.) when resizing a mesh. This would be able to be
>>>>>> customized by the user of course.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>
>>>
>>
>>
>> --
>> 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/20170929/a9c33714/attachment-0001.html>