Data disappears from point cloud when exporting at low decimation value #1368
Comments
|
How large is the area in meters? are you also setting a voxel size? The voxel filter has some limit, though we implemented a workaround to split space in order to apply the voxel filter (it should still work, only with some warnings). With a lot of points, that could be possible that you run out of RAM. You may keep an eye on RAM usage while it is exporting. A trick with large maps is to split the output in multiple exports, using this option: With cheers, |
|
The area is approximately 275 * 200 meters in area (not sure how to find surface area if that is what you mean). Forgot to mention it, but I don't voxelize as that adds more time to the export. I also don't think I'm running out of RAM. Cutting up the scan in different areas and exporting them separately is a good idea thanks, that might be a good workaround. |
I am then not sure what is happening. Out of curiosity, can you copy/paste output of: For that area size, 70 GB is a lot, I am curious about how much space the raw data is taken up from in the database versus the number of nodes in the map. |
The DB consists of several scans merged together with significant overlap, reprocessed with a higher than default number of features extracted per image. I guess that all contributes to the increased size. |
|
Thx for the info, I see. 63 mapping sessions merged together. In case RGB resolution doesn't matter too much in your case, you could set also For the original issue, did you try enabling Nodes Filtering? Maybe for some reason in the data you have there are points that are very far (because of poor depth estimation), you could try setting a maximum depth distance when exporting. That would filter these points. |
Yes hehe, quite a lot of work :) I use 4 meters as the max depth accepted when exporting, the problem persists. |
|
Well, in general I would say if you can share the database I would take a look to reproduce the issue here, however, 70 GB may be too large for you to do so. I don't know if you could reproduce the issue on one of the session (or by merging some of them) and only share that database (you can send me a private googledrive link if the data cannot be shared publicly, my gmail account is the same than my username here), that would be useful. |
|
I created some issues above to test more your data. In the mean time, I saw in the dataset that sometime there are traversals of the same path on different sessions but they are not connected together, so there are many double-walls in the map. That can be fixed by manually add new constraints with the "Constraints View" of rtabmap-databaseViewer. You may also set Here an example where I fixed two paths by adding a loop closure on some symbols on other wall seen by two point views from two different sessions: |
Hello!
I've got a pretty huge scan (the DB file is almost 70 GB large) which I'm generating point clouds of using rtabmap-databaseViewer.
What I find is that when exporting with decimation level 8 and no normal generation, I get all the data I want. If I export at lower decimation levels (4, 2, 1) I get progressively less and less data. With that I mean that portions of the scan disappear, seemingly at random and not related to when in time they were scanned.
Also, if I generate a scan with decimation level 8 and normal computation enabled, the entire thing disappears. The PLY is still large, so there should be data, but I can't see anything when opening the file in a point cloud viewer. I also see that the coordinate bounds of the scan reported by CloudCompare goes to orders of magnitude larger values than they normally would (10e36 is what I recall, although I don't have a broken file handy right now).
Not sure what could be causing this - is there a known upper limit to the size of point cloud that can be exported? Potential upstream issue? Any help greatly appreciated :)
The text was updated successfully, but these errors were encountered: