Open rjanvier opened 5 years ago
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 data_containers.hpp
.
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 transform*
member functions should still work. Downsampling will require a little digging, as you might have to write a custom accumulator. If you plan to go that way for now, I can gladly help!
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. You can close the issue if you want.
One potential way forward using C++17 could be to store scalar fields in a container (vector/map) using std::variant<...ScalarTypes>
in the point cloud struct. This way one could iterate through all scalar fields while doing point selection, downsampling, etc.
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 PointCloud<PointTraits,NormalTraits>
if, e.g., we only need points and normals. This would also allow defining custom attributes, as long as the user specifies how they are transformed and downsampled, and performing linear operations (e.g., transformations, point selection) seamlessly in a single pass. I am planning to resume work on that when things get less busy... :)
@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 Is there any news on scalar fields ? I would love to see this !
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?