Wrapping a pcl::PointCloud around raw data

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

Wrapping a pcl::PointCloud around raw data

Stephen McDowell
I am looking for suggestions on how to map raw data into a pcl::PointCloud, ideally without allocating new data each frame.  I would be targeting PointXYZ, PointXYZNormal, and PointXYZRGBNormal only.  I’m trying to enable users to be able to take data from my library and then call whatever they desire in PCL.  However, with how I have things setup, I don’t know if this is possible.

    std::vector<PointT, Eigen::aligned_allocator<PointT> > points;

This is the primary definition in pcl::PointCloud.  My library has data laid out as

    struct Data {
        alignas(16u) float4 *positions;// allocated with _mm_malloc or cudaMallocHost
        alignas(16u) float4 *normals;// AKA will always be 16 byte aligned
        alignas(16u) uint8_t *videoData;// either RGBA, or BGRA
    };

Where `float4` is defined accurately when CUDA is not available.  On that note, I’m only trying to enable host conversions.  My device memory is incompatible, since it does not `cudaMallocPitch` (because this can’t be done with OpenGL interoperability, at least not easily).

So since my data is laid out this way, in order to create a pcl::PointCloud, I have to allocate new data right?  The only one I think it *might* work with would be PointXYZ, since internally you actually do float data[4].  But once normals get in there, or color, there’s no way to share the memory because pcl::PointCloud would want something like

<p0_x, p0_y, p0_z, p0_w, n0_x, n0_y, n0_z, n0_w>

for point zero, where p0_w and n0_w are the padding, but my data would have all positions first, then all normals, etc.

Is this interpretation correct, or is there something I am overlooking that I can take advantage of?

Thanks for any suggestions!


_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrapping a pcl::PointCloud around raw data

Sérgio Agostinho
Hey Stephen,

I don't think there's a way of accomplish what you want with the PointCloud type because it relies on std::vector for handling the storage of points and std::vector cannot wrap around data it doesn't manage. 

Assuming you go with the Data type you propose, you're gonna have problems with most code of the library, because it expects XYZ related data to have defined x, y and z members respectively. 

Good luck

--

On Wednesday, Jan 31, 2018 at 12:09 AM, Stephen McDowell <[hidden email]> wrote:
I am looking for suggestions on how to map raw data into a pcl::PointCloud, ideally without allocating new data each frame.  I would be targeting PointXYZ, PointXYZNormal, and PointXYZRGBNormal only.  I’m trying to enable users to be able to take data from my library and then call whatever they desire in PCL.  However, with how I have things setup, I don’t know if this is possible.

    std::vector<PointT, Eigen::aligned_allocator<PointT> > points;

This is the primary definition in pcl::PointCloud.  My library has data laid out as

    struct Data {
        alignas(16u) float4 *positions;// allocated with _mm_malloc or cudaMallocHost
        alignas(16u) float4 *normals;// AKA will always be 16 byte aligned
        alignas(16u) uint8_t *videoData;// either RGBA, or BGRA
    };

Where `float4` is defined accurately when CUDA is not available.  On that note, I’m only trying to enable host conversions.  My device memory is incompatible, since it does not `cudaMallocPitch` (because this can’t be done with OpenGL interoperability, at least not easily).

So since my data is laid out this way, in order to create a pcl::PointCloud, I have to allocate new data right?  The only one I think it *might* work with would be PointXYZ, since internally you actually do float data[4].  But once normals get in there, or color, there’s no way to share the memory because pcl::PointCloud would want something like

<p0_x, p0_y, p0_z, p0_w, n0_x, n0_y, n0_z, n0_w>

for point zero, where p0_w and n0_w are the padding, but my data would have all positions first, then all normals, etc.

Is this interpretation correct, or is there something I am overlooking that I can take advantage of?

Thanks for any suggestions!

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

signature.asc (882 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wrapping a pcl::PointCloud around raw data

Stephen McDowell
Hey Sérgio,

Thanks for the response.  I think the best workflow here is just to encourage the use of `reserve` at the beginning and `emplace_back` the points they desire (width and height are fixed, it’s just range images).

I can actually write the conversion in a header file and take in a PointCloud reference, and just basically document it saying “only include this if you are using PCL” and a small sample CMake to accompany.

-Stephen

P.S. I remember seeing some issues discussing the eventual switch to C++11 for PCL, if there’s a bucket list, replacing all possible instances of `push_back` with `emplace_back` would offer some potentially good savings when operating on larger clouds.  The thought of actually implementing this, though, instills a particularly deep sense of forlorn.

On Feb 2, 2018, at 1:45 AM, Sérgio Agostinho <[hidden email]> wrote:

Hey Stephen,

I don't think there's a way of accomplish what you want with the PointCloud type because it relies on std::vector for handling the storage of points and std::vector cannot wrap around data it doesn't manage. 

Assuming you go with the Data type you propose, you're gonna have problems with most code of the library, because it expects XYZ related data to have defined x, y and z members respectively. 

Good luck

--

On Wednesday, Jan 31, 2018 at 12:09 AM, Stephen McDowell <[hidden email]> wrote:
I am looking for suggestions on how to map raw data into a pcl::PointCloud, ideally without allocating new data each frame.  I would be targeting PointXYZ, PointXYZNormal, and PointXYZRGBNormal only.  I’m trying to enable users to be able to take data from my library and then call whatever they desire in PCL.  However, with how I have things setup, I don’t know if this is possible.

    std::vector<PointT, Eigen::aligned_allocator<PointT> > points;

This is the primary definition in pcl::PointCloud.  My library has data laid out as

    struct Data {
        alignas(16u) float4 *positions;// allocated with _mm_malloc or cudaMallocHost
        alignas(16u) float4 *normals;// AKA will always be 16 byte aligned
        alignas(16u) uint8_t *videoData;// either RGBA, or BGRA
    };

Where `float4` is defined accurately when CUDA is not available.  On that note, I’m only trying to enable host conversions.  My device memory is incompatible, since it does not `cudaMallocPitch` (because this can’t be done with OpenGL interoperability, at least not easily).

So since my data is laid out this way, in order to create a pcl::PointCloud, I have to allocate new data right?  The only one I think it *might* work with would be PointXYZ, since internally you actually do float data[4].  But once normals get in there, or color, there’s no way to share the memory because pcl::PointCloud would want something like

<p0_x, p0_y, p0_z, p0_w, n0_x, n0_y, n0_z, n0_w>

for point zero, where p0_w and n0_w are the padding, but my data would have all positions first, then all normals, etc.

Is this interpretation correct, or is there something I am overlooking that I can take advantage of?

Thanks for any suggestions!

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users


_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrapping a pcl::PointCloud around raw data

Sérgio Agostinho
I feel like there was a logic jump our emails I might have not understood completely so apologies in advance I failed to grasp properly the points you mention. 

PCL at the moment is C++03 so there's no emplace operators just yet, which means you would need to ship your own custom pcl distribution. I can't provide more insightful comments without seeing some code to better understand what you're trying to do. 


There is a semi bucket list for that transition in here https://github.com/PointCloudLibrary/pcl/projects/1

To contribute ideas please open an issue on github. I'll add this one you mentioned to the "bucket list" in the meantime. 

It's worth noting that the effort now is to cleanup for the 1.9 release since it adds support for vtk8.  

Cheers

--

On Friday, Feb 02, 2018 at 5:16 PM, Stephen McDowell <[hidden email]> wrote:
Hey Sérgio,

Thanks for the response.  I think the best workflow here is just to encourage the use of `reserve` at the beginning and `emplace_back` the points they desire (width and height are fixed, it’s just range images).

I can actually write the conversion in a header file and take in a PointCloud reference, and just basically document it saying “only include this if you are using PCL” and a small sample CMake to accompany.

-Stephen

P.S. I remember seeing some issues discussing the eventual switch to C++11 for PCL, if there’s a bucket list, replacing all possible instances of `push_back` with `emplace_back` would offer some potentially good savings when operating on larger clouds.  The thought of actually implementing this, though, instills a particularly deep sense of forlorn.

On Feb 2, 2018, at 1:45 AM, Sérgio Agostinho <[hidden email]> wrote:

Hey Stephen,

I don't think there's a way of accomplish what you want with the PointCloud type because it relies on std::vector for handling the storage of points and std::vector cannot wrap around data it doesn't manage. 

Assuming you go with the Data type you propose, you're gonna have problems with most code of the library, because it expects XYZ related data to have defined x, y and z members respectively. 

Good luck

--

On Wednesday, Jan 31, 2018 at 12:09 AM, Stephen McDowell <[hidden email]> wrote:
I am looking for suggestions on how to map raw data into a pcl::PointCloud, ideally without allocating new data each frame.  I would be targeting PointXYZ, PointXYZNormal, and PointXYZRGBNormal only.  I’m trying to enable users to be able to take data from my library and then call whatever they desire in PCL.  However, with how I have things setup, I don’t know if this is possible.

    std::vector<PointT, Eigen::aligned_allocator<PointT> > points;

This is the primary definition in pcl::PointCloud.  My library has data laid out as

    struct Data {
        alignas(16u) float4 *positions;// allocated with _mm_malloc or cudaMallocHost
        alignas(16u) float4 *normals;// AKA will always be 16 byte aligned
        alignas(16u) uint8_t *videoData;// either RGBA, or BGRA
    };

Where `float4` is defined accurately when CUDA is not available.  On that note, I’m only trying to enable host conversions.  My device memory is incompatible, since it does not `cudaMallocPitch` (because this can’t be done with OpenGL interoperability, at least not easily).

So since my data is laid out this way, in order to create a pcl::PointCloud, I have to allocate new data right?  The only one I think it *might* work with would be PointXYZ, since internally you actually do float data[4].  But once normals get in there, or color, there’s no way to share the memory because pcl::PointCloud would want something like

<p0_x, p0_y, p0_z, p0_w, n0_x, n0_y, n0_z, n0_w>

for point zero, where p0_w and n0_w are the padding, but my data would have all positions first, then all normals, etc.

Is this interpretation correct, or is there something I am overlooking that I can take advantage of?

Thanks for any suggestions!

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

signature.asc (882 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wrapping a pcl::PointCloud around raw data

Stephen McDowell
Only a small one: my library is C++11 or later.  So in the wrapper method, I’ll be doing something like

    template <class PointT>
    void asPointCloud(const Data &data, pcl::PointCloud<PointT> &cloud) {
        // emplace_back points here into cloud, using data.positions, data.normals etc
    }

and in the documentation, I’ll be advising users to `reserve` memory first for the specified cloud so that they don’t need to allocate it every frame.  Since it’s an std::vector, even if PCL doesn’t have the ability to `emplace_back`, I do.

The main goal for creating the wrapper method is to set the width and height appropriately, since it’s easy to overlook and many algorithms either need or can use that information :)

Sounds good on the future TODO front.  I’m hoping to finish up my project soon, after 1.9 I’m down to jump in on the emplace_back thing.  It would be pretty easy to just comb through a couple files once a week sort of thing.

On Feb 3, 2018, at 12:24 AM, Sérgio Agostinho <[hidden email]> wrote:

I feel like there was a logic jump our emails I might have not understood completely so apologies in advance I failed to grasp properly the points you mention. 

PCL at the moment is C++03 so there's no emplace operators just yet, which means you would need to ship your own custom pcl distribution. I can't provide more insightful comments without seeing some code to better understand what you're trying to do. 


There is a semi bucket list for that transition in here https://github.com/PointCloudLibrary/pcl/projects/1

To contribute ideas please open an issue on github. I'll add this one you mentioned to the "bucket list" in the meantime. 

It's worth noting that the effort now is to cleanup for the 1.9 release since it adds support for vtk8.  

Cheers

--

On Friday, Feb 02, 2018 at 5:16 PM, Stephen McDowell <[hidden email]> wrote:
Hey Sérgio,

Thanks for the response.  I think the best workflow here is just to encourage the use of `reserve` at the beginning and `emplace_back` the points they desire (width and height are fixed, it’s just range images).

I can actually write the conversion in a header file and take in a PointCloud reference, and just basically document it saying “only include this if you are using PCL” and a small sample CMake to accompany.

-Stephen

P.S. I remember seeing some issues discussing the eventual switch to C++11 for PCL, if there’s a bucket list, replacing all possible instances of `push_back` with `emplace_back` would offer some potentially good savings when operating on larger clouds.  The thought of actually implementing this, though, instills a particularly deep sense of forlorn.

On Feb 2, 2018, at 1:45 AM, Sérgio Agostinho <[hidden email]> wrote:

Hey Stephen,

I don't think there's a way of accomplish what you want with the PointCloud type because it relies on std::vector for handling the storage of points and std::vector cannot wrap around data it doesn't manage. 

Assuming you go with the Data type you propose, you're gonna have problems with most code of the library, because it expects XYZ related data to have defined x, y and z members respectively. 

Good luck

--

On Wednesday, Jan 31, 2018 at 12:09 AM, Stephen McDowell <[hidden email]> wrote:
I am looking for suggestions on how to map raw data into a pcl::PointCloud, ideally without allocating new data each frame.  I would be targeting PointXYZ, PointXYZNormal, and PointXYZRGBNormal only.  I’m trying to enable users to be able to take data from my library and then call whatever they desire in PCL.  However, with how I have things setup, I don’t know if this is possible.

    std::vector<PointT, Eigen::aligned_allocator<PointT> > points;

This is the primary definition in pcl::PointCloud.  My library has data laid out as

    struct Data {
        alignas(16u) float4 *positions;// allocated with _mm_malloc or cudaMallocHost
        alignas(16u) float4 *normals;// AKA will always be 16 byte aligned
        alignas(16u) uint8_t *videoData;// either RGBA, or BGRA
    };

Where `float4` is defined accurately when CUDA is not available.  On that note, I’m only trying to enable host conversions.  My device memory is incompatible, since it does not `cudaMallocPitch` (because this can’t be done with OpenGL interoperability, at least not easily).

So since my data is laid out this way, in order to create a pcl::PointCloud, I have to allocate new data right?  The only one I think it *might* work with would be PointXYZ, since internally you actually do float data[4].  But once normals get in there, or color, there’s no way to share the memory because pcl::PointCloud would want something like

<p0_x, p0_y, p0_z, p0_w, n0_x, n0_y, n0_z, n0_w>

for point zero, where p0_w and n0_w are the padding, but my data would have all positions first, then all normals, etc.

Is this interpretation correct, or is there something I am overlooking that I can take advantage of?

Thanks for any suggestions!

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users


_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrapping a pcl::PointCloud around raw data

Sérgio Agostinho
My notion of wrapping data is creating an object around a certain block of data, which allows to use it in whatever operations necessary e.g, Eigen::Map. The fundamental concept is that data is never copied. Currently, that's (dare I say) impossible to do with PointCloud. 

This signature you're showing me, at best will create a PointCloud (copy) representation of your data, but it will not be a true wrapper. It will be a data type converter. 


Cheers

--

On Saturday, Feb 03, 2018 at 9:10 PM, Stephen McDowell <[hidden email]> wrote:
Only a small one: my library is C++11 or later.  So in the wrapper method, I’ll be doing something like

    template <class PointT>
    void asPointCloud(const Data &data, pcl::PointCloud<PointT> &cloud) {
        // emplace_back points here into cloud, using data.positions, data.normals etc
    }

and in the documentation, I’ll be advising users to `reserve` memory first for the specified cloud so that they don’t need to allocate it every frame.  Since it’s an std::vector, even if PCL doesn’t have the ability to `emplace_back`, I do.

The main goal for creating the wrapper method is to set the width and height appropriately, since it’s easy to overlook and many algorithms either need or can use that information :)

Sounds good on the future TODO front.  I’m hoping to finish up my project soon, after 1.9 I’m down to jump in on the emplace_back thing.  It would be pretty easy to just comb through a couple files once a week sort of thing.

On Feb 3, 2018, at 12:24 AM, Sérgio Agostinho <[hidden email]> wrote:

I feel like there was a logic jump our emails I might have not understood completely so apologies in advance I failed to grasp properly the points you mention. 

PCL at the moment is C++03 so there's no emplace operators just yet, which means you would need to ship your own custom pcl distribution. I can't provide more insightful comments without seeing some code to better understand what you're trying to do. 


There is a semi bucket list for that transition in here https://github.com/PointCloudLibrary/pcl/projects/1

To contribute ideas please open an issue on github. I'll add this one you mentioned to the "bucket list" in the meantime. 

It's worth noting that the effort now is to cleanup for the 1.9 release since it adds support for vtk8.  

Cheers

--

On Friday, Feb 02, 2018 at 5:16 PM, Stephen McDowell <[hidden email]> wrote:
Hey Sérgio,

Thanks for the response.  I think the best workflow here is just to encourage the use of `reserve` at the beginning and `emplace_back` the points they desire (width and height are fixed, it’s just range images).

I can actually write the conversion in a header file and take in a PointCloud reference, and just basically document it saying “only include this if you are using PCL” and a small sample CMake to accompany.

-Stephen

P.S. I remember seeing some issues discussing the eventual switch to C++11 for PCL, if there’s a bucket list, replacing all possible instances of `push_back` with `emplace_back` would offer some potentially good savings when operating on larger clouds.  The thought of actually implementing this, though, instills a particularly deep sense of forlorn.

On Feb 2, 2018, at 1:45 AM, Sérgio Agostinho <[hidden email]> wrote:

Hey Stephen,

I don't think there's a way of accomplish what you want with the PointCloud type because it relies on std::vector for handling the storage of points and std::vector cannot wrap around data it doesn't manage. 

Assuming you go with the Data type you propose, you're gonna have problems with most code of the library, because it expects XYZ related data to have defined x, y and z members respectively. 

Good luck

--

On Wednesday, Jan 31, 2018 at 12:09 AM, Stephen McDowell <[hidden email]> wrote:
I am looking for suggestions on how to map raw data into a pcl::PointCloud, ideally without allocating new data each frame.  I would be targeting PointXYZ, PointXYZNormal, and PointXYZRGBNormal only.  I’m trying to enable users to be able to take data from my library and then call whatever they desire in PCL.  However, with how I have things setup, I don’t know if this is possible.

    std::vector<PointT, Eigen::aligned_allocator<PointT> > points;

This is the primary definition in pcl::PointCloud.  My library has data laid out as

    struct Data {
        alignas(16u) float4 *positions;// allocated with _mm_malloc or cudaMallocHost
        alignas(16u) float4 *normals;// AKA will always be 16 byte aligned
        alignas(16u) uint8_t *videoData;// either RGBA, or BGRA
    };

Where `float4` is defined accurately when CUDA is not available.  On that note, I’m only trying to enable host conversions.  My device memory is incompatible, since it does not `cudaMallocPitch` (because this can’t be done with OpenGL interoperability, at least not easily).

So since my data is laid out this way, in order to create a pcl::PointCloud, I have to allocate new data right?  The only one I think it *might* work with would be PointXYZ, since internally you actually do float data[4].  But once normals get in there, or color, there’s no way to share the memory because pcl::PointCloud would want something like

<p0_x, p0_y, p0_z, p0_w, n0_x, n0_y, n0_z, n0_w>

for point zero, where p0_w and n0_w are the padding, but my data would have all positions first, then all normals, etc.

Is this interpretation correct, or is there something I am overlooking that I can take advantage of?

Thanks for any suggestions!

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

signature.asc (882 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wrapping a pcl::PointCloud around raw data

Stephen McDowell
Yes, sorry I have been failing at communication here.  I ommitted an important viewpoint after your initial response: I am in complete agreement, sharing data is not possible.

As you state, the method I am showing above is copying.  AKA if anybody is reading this and wants to enable users to take raw data from your library / application and make it available for PCL, the best you can do is create a function that populates a pcl::PointCloud for them.

Thanks for the responses Sérgio, see you on the other side of 1.9 for the emplace_back extravaganza :)

On Feb 3, 2018, at 1:45 PM, Sérgio Agostinho <[hidden email]> wrote:

My notion of wrapping data is creating an object around a certain block of data, which allows to use it in whatever operations necessary e.g, Eigen::Map. The fundamental concept is that data is never copied. Currently, that's (dare I say) impossible to do with PointCloud. 

This signature you're showing me, at best will create a PointCloud (copy) representation of your data, but it will not be a true wrapper. It will be a data type converter. 


Cheers

--

On Saturday, Feb 03, 2018 at 9:10 PM, Stephen McDowell <[hidden email]> wrote:
Only a small one: my library is C++11 or later.  So in the wrapper method, I’ll be doing something like

    template <class PointT>
    void asPointCloud(const Data &data, pcl::PointCloud<PointT> &cloud) {
        // emplace_back points here into cloud, using data.positions, data.normals etc
    }

and in the documentation, I’ll be advising users to `reserve` memory first for the specified cloud so that they don’t need to allocate it every frame.  Since it’s an std::vector, even if PCL doesn’t have the ability to `emplace_back`, I do.

The main goal for creating the wrapper method is to set the width and height appropriately, since it’s easy to overlook and many algorithms either need or can use that information :)

Sounds good on the future TODO front.  I’m hoping to finish up my project soon, after 1.9 I’m down to jump in on the emplace_back thing.  It would be pretty easy to just comb through a couple files once a week sort of thing.

On Feb 3, 2018, at 12:24 AM, Sérgio Agostinho <[hidden email]> wrote:

I feel like there was a logic jump our emails I might have not understood completely so apologies in advance I failed to grasp properly the points you mention. 

PCL at the moment is C++03 so there's no emplace operators just yet, which means you would need to ship your own custom pcl distribution. I can't provide more insightful comments without seeing some code to better understand what you're trying to do. 


There is a semi bucket list for that transition in here https://github.com/PointCloudLibrary/pcl/projects/1

To contribute ideas please open an issue on github. I'll add this one you mentioned to the "bucket list" in the meantime. 

It's worth noting that the effort now is to cleanup for the 1.9 release since it adds support for vtk8.  

Cheers

--

On Friday, Feb 02, 2018 at 5:16 PM, Stephen McDowell <[hidden email]> wrote:
Hey Sérgio,

Thanks for the response.  I think the best workflow here is just to encourage the use of `reserve` at the beginning and `emplace_back` the points they desire (width and height are fixed, it’s just range images).

I can actually write the conversion in a header file and take in a PointCloud reference, and just basically document it saying “only include this if you are using PCL” and a small sample CMake to accompany.

-Stephen

P.S. I remember seeing some issues discussing the eventual switch to C++11 for PCL, if there’s a bucket list, replacing all possible instances of `push_back` with `emplace_back` would offer some potentially good savings when operating on larger clouds.  The thought of actually implementing this, though, instills a particularly deep sense of forlorn.

On Feb 2, 2018, at 1:45 AM, Sérgio Agostinho <[hidden email]> wrote:

Hey Stephen,

I don't think there's a way of accomplish what you want with the PointCloud type because it relies on std::vector for handling the storage of points and std::vector cannot wrap around data it doesn't manage. 

Assuming you go with the Data type you propose, you're gonna have problems with most code of the library, because it expects XYZ related data to have defined x, y and z members respectively. 

Good luck

--

On Wednesday, Jan 31, 2018 at 12:09 AM, Stephen McDowell <[hidden email]> wrote:
I am looking for suggestions on how to map raw data into a pcl::PointCloud, ideally without allocating new data each frame.  I would be targeting PointXYZ, PointXYZNormal, and PointXYZRGBNormal only.  I’m trying to enable users to be able to take data from my library and then call whatever they desire in PCL.  However, with how I have things setup, I don’t know if this is possible.

    std::vector<PointT, Eigen::aligned_allocator<PointT> > points;

This is the primary definition in pcl::PointCloud.  My library has data laid out as

    struct Data {
        alignas(16u) float4 *positions;// allocated with _mm_malloc or cudaMallocHost
        alignas(16u) float4 *normals;// AKA will always be 16 byte aligned
        alignas(16u) uint8_t *videoData;// either RGBA, or BGRA
    };

Where `float4` is defined accurately when CUDA is not available.  On that note, I’m only trying to enable host conversions.  My device memory is incompatible, since it does not `cudaMallocPitch` (because this can’t be done with OpenGL interoperability, at least not easily).

So since my data is laid out this way, in order to create a pcl::PointCloud, I have to allocate new data right?  The only one I think it *might* work with would be PointXYZ, since internally you actually do float data[4].  But once normals get in there, or color, there’s no way to share the memory because pcl::PointCloud would want something like

<p0_x, p0_y, p0_z, p0_w, n0_x, n0_y, n0_z, n0_w>

for point zero, where p0_w and n0_w are the padding, but my data would have all positions first, then all normals, etc.

Is this interpretation correct, or is there something I am overlooking that I can take advantage of?

Thanks for any suggestions!

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users

_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users


_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users