What's the best way to represent 3D data when you might have a large area with sparse geometry? I'm thinking something like a visual SLAM system, where you build up a map of the surroundings while moving through it. In 2D it should be pretty straight forward, but using a 3D grid seems like it would get out of hand fast. Is it a KD-tree with voxels? Signed Distance Fields? How do robots and self driving cars store the dynamic maps they build from sensor data?
That is an interesting question! Whether a 3d grid gets out of hand depends how big you can make your cells. Tree based techniques are inflexible with respect to bounding volume changes, requiring some kind of complex rebalancing technique to stay efficient.
Cars or moving robots still move on a 2d surface, so projecting everything into a 2d plane works for these applications.
It's my understanding that a lot of self driving cars use LIDAR to localize themselves in a 3D map, so a 2D representation wouldn't work. Then there's bridges, tunnels, and so on. Maybe a better example is flying drones, there are consumer drones available that keeps track of the surrounding and the user. In this video[0] it looks like they use a sparse grid of some kind, but wouldn't that be a tree?
The problem with a grid is as you mention the cell size. If instead of cars we use a different example, like large scale photogrammetry, a small cell size is desirable, because you want as much detail as possible, but you might reconstruct a small city. With some tall houses you need a large grid in the z-direction, even if most of the volume will be empty, suggesting that a tree would be the better solution.
Are there any real life examples of how this problem has been solved? As far as I can tell, this project supports point clouds and mesh as the main data storage, and KD-trees from point clouds to do operations on it. I've found, but never used, Voxblox[1] and OpenVDB[2] that looks promising. Voxblox is made for robots but looks like it might use a lot of RAM for larger spaces, OpenVDB is made for visualization but maybe works for other things too? I don't really understand how it works though.
Are you thinking of a voxel grid when your are talking about a grid? A grid acceleration structure is different from that: each cell is a variable length list of the contents of the cell. So in case of a sparse voxel grid you would have a coarse grid with the cells pointing to voxel grids iff there is at least one non-empty voxel inside the volume. So you're only allocating memory for blocks that have some voxel information to store. The coarse grid itself is just a set of list headers which don't have a high memory requirement (a few MB maybe).
If you mean geometry, you can just store the points. If you mean voxels or dynamically loading and unloading of points, a kd-tree or octree is probably what you are looking for.
I mean building up geometry from scratch using different kinds of depth sensors in an expanding environment of unknown size. The data is probably in the form of point clouds to start with, but you can't really store them sequentially if you want to do any operations on it, like loop closure or rendering.
It seems like your library is much more integrated into Python than the point cloud library. I have been frustrated with the point cloud library and this seems much better to work with numpy also. Looks great !
Be careful guys. The original repo is open3d.org open-3d.org is a copy of open3d repo. This repo squashed all the commit history of open3d contributors.
1. Squashing the commit history is not a very nice thing to do IMO.
2. When you fork as in you actually plan on taking the code in another direction you should come up with a name of your own.
For example, GraphicsMagick forked from ImageMagick all the way back in 2002 and they came up with a name of their own as one should. The GraphicsMagick website even displays the following message prominently on their website http://www.graphicsmagick.org/ to this day:
> GraphicsMagick is originally derived from ImageMagick 5.5.2 as of November 2002 but has been completely independent of the ImageMagick project since then. Since the fork from ImageMagick many improvements have been made (see NEWS) by many authors using an open development model but without breaking the API or utilities operation.
That's the proper way to fork. You don't just take somebody else's project and stick with the name that they were using unless you have their blessing to do so.
The Open3D fork website at http://www.open-3d.org/ is giving the impression that maintenance of the project was handed over by its original creators;
> Although the Open3D project is currently maintained by the Open3D community, it was initiated by Qianyi Zhou and Jaesik Park, who have wrote a paper, and they ask you to kindly cite it!
Meanwhile in the GitHub issue at https://github.com/IntelVCL/Open3D/issues/321 that was linked in a sibling comment, one of the original authors of Open3D says, among other things:
> Only the code is under MIT license. The website is not. You should not use any materials from the www.open3d.org website without our permission.
and
> Open3D is a branded name we own. You can say your project is a fork of the Open3D project but you cannot claim your project is Open3D.
