You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Draco https://github.com/google/draco is a point cloud compression library that is often used. It's supposed to be less performant than our compressor (latency-quality-bandwidth wise) but it would still be nice to integrate it into the cwipc infrastructure, because it'll give us an easy comparison point.
On the cwipc side integration should be fairly simple: just creating a new submodule (cwipc_dracodec springs to mind) which implements subclasses of cwipc_encoder and cwipc_decoder, just like cwipc_codec does.
I have no idea of the structure of the Draco code. If one of the things it contains is a library that can be used by native C/C++ code life is easy. But on the other hand it may be very difficult/impossible if the only thing that is available is a command line tool to convert PLY files to Draco and vice versa.
@troeggla I'm assigning this to you more-or-less randomly, if you're not interested please assign back to me, or unassign.
The text was updated successfully, but these errors were encountered:
This repo (https://github.com/MatthiasDeFre/draco_example) has an example on how to use the Draco library in C++ for encoding/decoding a point cloud. The application has two modes to load a .ply file, either by using native Draco code or together with PCL. The PCL example is mainly to give an idea how you can construct a Draco point cloud from a different data source (e.g. PCL point cloud or depth/color frames).
If there are any questions, I'll be happy to answer them as the documentation for the Draco library is fairly lackluster.
Draco https://github.com/google/draco is a point cloud compression library that is often used. It's supposed to be less performant than our compressor (latency-quality-bandwidth wise) but it would still be nice to integrate it into the cwipc infrastructure, because it'll give us an easy comparison point.
On the
cwipc
side integration should be fairly simple: just creating a new submodule (cwipc_dracodec
springs to mind) which implements subclasses ofcwipc_encoder
andcwipc_decoder
, just likecwipc_codec
does.I have no idea of the structure of the Draco code. If one of the things it contains is a library that can be used by native C/C++ code life is easy. But on the other hand it may be very difficult/impossible if the only thing that is available is a command line tool to convert PLY files to Draco and vice versa.
@troeggla I'm assigning this to you more-or-less randomly, if you're not interested please assign back to me, or unassign.
The text was updated successfully, but these errors were encountered: