Normal Estimate Example

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Normal Estimate Example

williamlai3a
Hi,

I am testing the normal_estimation example on a 124915192 points point
cloud.
jet_fitting with k=34 finished smoothly,
but after that when attempting to run MST to orient the normals with K=34 (I
tried default18, same thing happens),
the algorithm eats all 64GB main memory and used up all 16GB swap space (in
ubuntu).
I am wondering if it is caused by storing a too big minimum spanning tree in
main memory?
Would further lower down the number of K helps? but would that trade off the
quality of the result?
Any advise?

Thank you very much.

William



--
Sent from: http://cgal-discuss.949826.n4.nabble.com/

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Normal Estimate Example

williamlai3a
Hi,

[Update]
I have tried k=6, where it also used 43660 Mb main memory.
But the resulting point cloud only being erased to one single point by the
code block:

  // Optional: delete points with an unoriented normal
  // if you plan to call a reconstruction algorithm that expects oriented
normals.
  points.erase(unoriented_points_begin, points.end());





--
Sent from: http://cgal-discuss.949826.n4.nabble.com/

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Normal Estimate Example

Simon Giraudot-2
Hello,

> [Update]
> I have tried k=6, where it also used 43660 Mb main memory.
If I understand correctly, the code stores a graph that would k*N in
size (with N your number of points). I've tried on a 6 million points
and k=19 and the RAM usage goes to 7GB, so I'm not really surprised by
your results on such a large point cloud. I'll have a look into the code
to see if something can be improved…

For the record, what do you need oriented normals for? Many algorithms
only require unoriented normals (I can mostly think of Poisson
reconstruction in CGAL which does require orientation).
> But the resulting point cloud only being erased to one single point by the
> code block:
>
>    // Optional: delete points with an unoriented normal
>    // if you plan to call a reconstruction algorithm that expects oriented
> normals.
>    points.erase(unoriented_points_begin, points.end());
I'm not sure I understand what's your problem here: does this erase ALL
of your points except for one? Or something else?

I don't know if this is your case, but just a note: algorithms that are
applied to K nearest neighbors can give incorrect and unexpected results
if the point cloud is highly non-uniform (for example, if you have very
dense scanlines with a high space between each scanline).

Best,

--
Simon Giraudot, PhD
R&D Engineer
GeometryFactory - http://geometryfactory.com/


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Normal Estimate Example

williamlai3a
Hi Simon,

Thanks for your reply.

In my case, the massive point cloud is a laser scan of an indoor
environment.
At a later procedure, I will have to call Advanced Front Face Reconstruction
(I guess in my case, it is a better choice than Poisson, because I want to
fit planes and cylinders)
But the next step I am going to do is shape detection and structuring.
I am still thinking if I should do simplification and edge aware upsampling.

>> And yes, if I set k=6, it seems MST can only manage to orientate one
>> point, so the code block erase all other points except one single point.
>> But setting a bigger K, say 12, already eat up all of my main memory and
>> swap space.

Would you have any advise for my case, if I could just step normal
orientation?

Thanks a lot.

William


Simon Giraudot-2 wrote

> Hello,
>
>> [Update]
>> I have tried k=6, where it also used 43660 Mb main memory.
> If I understand correctly, the code stores a graph that would k*N in
> size (with N your number of points). I've tried on a 6 million points
> and k=19 and the RAM usage goes to 7GB, so I'm not really surprised by
> your results on such a large point cloud. I'll have a look into the code
> to see if something can be improved…
>
> For the record, what do you need oriented normals for? Many algorithms
> only require unoriented normals (I can mostly think of Poisson
> reconstruction in CGAL which does require orientation).
>
>> But the resulting point cloud only being erased to one single point by
>> the
>> code block:
>>
>>    // Optional: delete points with an unoriented normal
>>    // if you plan to call a reconstruction algorithm that expects
>> oriented
>> normals.
>>    points.erase(unoriented_points_begin, points.end());
> I'm not sure I understand what's your problem here: does this erase ALL
> of your points except for one? Or something else?
>
> I don't know if this is your case, but just a note: algorithms that are
> applied to K nearest neighbors can give incorrect and unexpected results
> if the point cloud is highly non-uniform (for example, if you have very
> dense scanlines with a high space between each scanline).
>
> Best,
>
> --
> Simon Giraudot, PhD
> R&D Engineer
> GeometryFactory - http://geometryfactory.com/
>
>
> --
> You are currently subscribed to cgal-discuss.
> To unsubscribe or access the archives, go to
> https://sympa.inria.fr/sympa/info/cgal-discuss





--
Sent from: http://cgal-discuss.949826.n4.nabble.com/

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Normal Estimate Example

Simon Giraudot-2
Hello again,
> In my case, the massive point cloud is a laser scan of an indoor
> environment.
> At a later procedure, I will have to call Advanced Front Face Reconstruction
> (I guess in my case, it is a better choice than Poisson, because I want to
> fit planes and cylinders)
> But the next step I am going to do is shape detection and structuring.
> I am still thinking if I should do simplification and edge aware upsampling.
You only need unoriented normals for all of these algorithms (except
Poisson but as you said, it might not be the best choice), so if I were
you, I would save some time and I wouldn't orient them.
>>> And yes, if I set k=6, it seems MST can only manage to orientate one
>>> point, so the code block erase all other points except one single point.
>>> But setting a bigger K, say 12, already eat up all of my main memory and
>>> swap space.
This is very weird, but then again, I can imagine something going wrong
depending on the uniformity/density of your point cloud.

One thing you could do first would be to extract a small portion of your
point cloud and see if the parameters work well on it (k=6, k=12, etc.).
This way, at least, you can do some tests without the memory issue.
Separating the point cloud in smaller subparts and applying orientation
to each is an option, but of course, in that case, there is not
guarantee that orientation will be consistent from one point cloud to
another.

Best regards,

--
Simon Giraudot, PhD
R&D Engineer
GeometryFactory - http://geometryfactory.com/


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss