-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional scalar field attached to point cloud #13
Comments
Hi! The PointCloud struct is basically a convenience wrapper, and is nowhere used internally in the rest of the library (only in the usage examples). All algorithms work directly on data matrix maps (e.g., of vertices, normals, etc.), as they are defined in Unfortunately, there is currently no clean/seamless way to extend the PointCloud structure with arbitrary additional data fields. This is not straightforward, as all functionality should be preserved (point selection, transforming, downsampling, etc.). However, having this flexibility can be extremely useful. I will try to devise/implement some mechanism for this and update! For now, if you need to add a known scalar field, the straightforward thing to do is define a new struct with all the fields you need and take/adapt functionality from PointCloud. If you only need the point selection member functions, adaptation should be very easy. If your scalar field is transformation invariant, existing Thank you for your interest! |
OK nice, it seems really clear to me and convenient enough for my needs! Thank you for your help and your proposal, I'll keep you updated of my progresses. |
One potential way forward using C++17 could be to store scalar fields in a container (vector/map) using |
That would be interesting! And moving to C++17 would bring other benefits as well. A few months ago I had started writing a generic point cloud wrapper that would have exactly the fields (points and vector/scalar point attributes) needed by the user using variadic templates, so that we can have something roughly like |
@kzampog This issue is probably the only reason I am not trying this library. Secondary information such as normals, time stamp or reflectivity or intensity are just too important to ignore. |
@andre-nguyen thanks for your interest! This has been ranking high in the list of things to add for some time now and I expect to be able to resume working on it next month :) |
@kzampog |
Hey I'm very intersted by your lib.
Just one little question before I dug deeper into it...
I see that normals and RGB values are first class citizen in your PC data structure but for now what's the recommended way to deal with arbitrary additional data in cilantro?
The text was updated successfully, but these errors were encountered: