-
Notifications
You must be signed in to change notification settings - Fork 421
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
Templatize FCL for scalar type #154
Conversation
# Conflicts: # test/test_fcl_octomap.cpp
Some failing tests with float scalar type are disabled for now. They will be addressed in the future commits.
- also try to resolve Eigen's mem alignment issues
Win64 VS 2015 RelWithDebInfoRe-run with your latest changes (had to fix a typo in spatial_hash.h). Results from above repeated; new ones marked with
Not back to 0.5 levels, but generally much better. |
Thanks for the comparisons! For fair comparisons, FCL 0.5 build should be updated with this, but I don't it would make a big difference, though. Hm, I don't know why this PR is slower than 0.5 on Windows.. I could to some investigation on my virtual Windows machine, but I would like to save it for future work. |
Enable Win32 build on Appveyor
Enable SSE2 by default
…ashing Fix redundant pair checking of SpatialHashingCollisionManager
See issue #160 for a subsequent change we could make to lighten the compilation load created by templatizing. |
The idea sounds good to me. I would like to save it for a future pull request, though. Also, I believe this PR is ready to merge. |
Definitely! Could be done any time later.
I agree. |
This PR templatize FCL objects on the scalar type so that we can take advantage of Eigen's automatic differentiation module as suggested by @sherm1 . A simple unit test that computes the gradient of distance w.r.t. the object position using Eigen's AutoDiff Module is included.
To make FCL working fine with
Eigen::AutoDiffScalar
, I had to templatize most of the FCL classes and global functions. Now there are only 7 files not templatized over ~180 files, which are not used anyways. I would suggest making FCL header only project as future change.In this work, the major challenge was the resolving circular dependencies as all the implementations of templated classes should be placed in the same file with the declarations. To resolve the problem, I split those header files in circular dependencies into several files. Also, some files are split for easier maintenance (e.g., geometric_shapes.h is split per each shape class).
One caveat is the increased compilation time, which is the nature of header only project.