Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

toooooo slow test on the Freiburg RGBD dataset #13

Open
ayumizll opened this issue Sep 14, 2016 · 5 comments
Open

toooooo slow test on the Freiburg RGBD dataset #13

ayumizll opened this issue Sep 14, 2016 · 5 comments

Comments

@ayumizll
Copy link

ayumizll commented Sep 14, 2016

hi:
i test chisel on my desktop equipped with Intel® Xeon(R) CPU E3-1231 v3 @ 3.40GHz × 8, and i run the launch_freiburg_dataset.launch with fault parameters . every update frame i can get nice reconstruction result, but too slow( Almost 3 seconds). i have no idea if there are some important parameters need to be set, or some significant things to be all attention. thanks!

@ayumizll ayumizll changed the title toooooo slow on the Freiburg RGBD dataset toooooo slow test on the Freiburg RGBD dataset Sep 14, 2016
@mklingen
Copy link
Collaborator

If you run the bag file without running chisel, how fast does it play back? Also, are you compiling in Release mode?

@ayumizll
Copy link
Author

ayumizll commented Nov 1, 2016

hi mklingen,Thank you for your answer. I'm sure on the release model, and I think this is independent of
ROS bag time. I test the chisel, find the most time-consuming is the function int Chisel.h named IntegrateDepthScanColor,

@mklingen
Copy link
Collaborator

mklingen commented Nov 1, 2016

I made some changes recently which should make IntegrateDepthScan a bit faster. I will push these sometime this week, and I'll let you know. At the time when I was running this on the Freiburg dataset I was getting ~10Hz out of it in Release mode. (-DCMAKE_BUILD_TYPE=Release).

The parameters which will affect the performance the most are voxel resolution (voxel_resolution_m) and the frustum cutoff (far_plane_dist) use_voxel_carving and to a lesser extent use_color will also make it slower.

@ayumizll
Copy link
Author

ayumizll commented Nov 2, 2016

hi mklingen, i am looking forward to your updated version. I will try to change the parameters and test the time again.

@HubertYang
Copy link

In my test, Chunk's size is also important. When resolution is 5cm, it is the fastest that chunk's size is 4x4x4.
Each resolution, you should find the best chunk's size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants