[vtk-developers] Fwd: A question regarding the most efficient way to merge neighbouring points in an iterative method

Robert Maynard robert.maynard at kitware.com
Mon Mar 18 12:40:05 EDT 2013


Forgot to send this email to the mailing list.

I have updated the point generator implementation to be more fair. The
first pass was quickly done on the airplane, and caused the points to fall
on a straight line in space causing some really bad octree behavior. Now I
get the vector implementation being roughly 4 times faster.


On Mon, Mar 18, 2013 at 2:15 AM, Philippe Pébay
<philippe.pebay at kitware.com>wrote:

> Sorry, I did not notice that the .h also contained the implementation.
>
> Thanks
> P
>
>
> On Mon, Mar 18, 2013 at 7:14 AM, Philippe Pébay <
> philippe.pebay at kitware.com> wrote:
>
>> Thanks Robert, this is most useful. On the github web interfact I can
>> only see the headers, how can I look at the implementation files?
>>
>> Thanks again
>> P
>>
>>
>> On Mon, Mar 18, 2013 at 7:08 AM, Robert Maynard <
>> robert.maynard at kitware.com> wrote:
>>
>>> For DAX we have had good success with sort, unique and than lower bounds
>>> to reduce a vector of points into the unique points.
>>>
>>> To can check out the benchmark code I wrote here:
>>> https://github.com/robertmaynard/PointMergingBenchmark to try out
>>> both an incremental octree point locator and the sort code.
>>>
>>> On 10 million points with 66% of them being duplicates under release
>>> mode ( which is very important ), I get the lower bounds methods
>>> being ~9 to 10 times faster.
>>>
>>>
>>>
>>>
>>> On Sun, Mar 17, 2013 at 8:25 AM, Philippe Pébay <
>>> philippe.pebay at kitware.com> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I have a question regarding the most efficient way to insert points in
>>>> an iterative method creating those as the algorithm progresses.
>>>>
>>>> Naively I am using a locator to insert each new point and possibly
>>>> merge it on the fly if it is epsilon-close to a pre-existing one. This is
>>>> convenient  and memory-wise this is efficient because the code does not
>>>> grow a list of replicated points.
>>>>
>>>> However, if we put memory aside and focus on speed, then it seems to be
>>>> more effective to merge points in a single pass, once they have all been
>>>> created. Especially as the complexity of the mesh increases.
>>>>
>>>> If anyone has looked into this issue I would appreciate any elements of
>>>> discussion.
>>>>
>>>> Thank you
>>>> Philippe
>>>>
>>>> --
>>>> Philippe Pébay, PhD
>>>> Director of Visualization and High Performance Computing /
>>>> Directeur de la Visualisation et du Calcul Haute Performance
>>>> Kitware SAS
>>>> 26 rue Louis Guérin, 69100 Villeurbanne, France
>>>> +33 (0) 6.83.61.55.70 / 4.37.45.04.15
>>>> http://www.kitware.fr <http://www.kitware.fr/>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Robert Maynard
>>>
>>
>>
>>
>> --
>> Philippe Pébay, PhD
>> Director of Visualization and High Performance Computing /
>> Directeur de la Visualisation et du Calcul Haute Performance
>> Kitware SAS
>> 26 rue Louis Guérin, 69100 Villeurbanne, France
>> +33 (0) 6.83.61.55.70 / 4.37.45.04.15
>> http://www.kitware.fr <http://www.kitware.fr/>
>>
>
>
>
> --
> Philippe Pébay, PhD
> Director of Visualization and High Performance Computing /
> Directeur de la Visualisation et du Calcul Haute Performance
> Kitware SAS
> 26 rue Louis Guérin, 69100 Villeurbanne, France
> +33 (0) 6.83.61.55.70 / 4.37.45.04.15
> http://www.kitware.fr <http://www.kitware.fr/>
>



-- 
Robert Maynard



-- 
Robert Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130318/a1ce35ae/attachment.html>


More information about the vtk-developers mailing list