-
Notifications
You must be signed in to change notification settings - Fork 94
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
Adding mesh double description #450
Adding mesh double description #450
Conversation
src/shape/geometric_shapes.cpp
Outdated
if (other.neighbors) { | ||
neighbors = new Neighbors[num_points]; | ||
std::copy(other.neighbors, other.neighbors + num_points, neighbors); | ||
} else | ||
neighbors = nullptr; | ||
|
||
if (other.nneighbors_) { | ||
std::size_t c_nneighbors = 0; | ||
for (std::size_t i = 0; i < num_points; ++i) | ||
c_nneighbors += neighbors[i].count(); | ||
nneighbors_ = new unsigned int[c_nneighbors]; | ||
std::copy(other.nneighbors_, other.nneighbors_ + c_nneighbors, nneighbors_); | ||
} else | ||
nneighbors_ = nullptr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the strategy for own_storage_
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the moment the ConvexBase/Convex<PolygonT>
always owns its normals
and offsets
.
However I can do the same strategy as for points
.
For it to make sense though, this requires adding a constructor to Convex<PolygonT>
or at least a function buildDoubleRepresentation
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jcarpent I can put a function buildDoubleRepresentation
in ConvexBase
and remove the normals construction from ConvexBase::convexHull
.
Then, either the user calls buildDoubleRepresentation
or we force the call to buildDoubleRepresentation
at the end of convexHull
(in the future, we might systematically need the double representation information for witness points after calling GJK/EPA).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first glance, the double description should not be computed when creating the objects to avoid any computational burden.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I agree but since we call Qhull inside ConvexBase::convexHull
, we get the double representation for free. Computing the double representation later would result in computationnal burden (need to call Qhull again).
I will restructure the code so that ConvexBase::convexHull
still constructs the double representation but buildDoubleRepresentation
can still be called later i.e for Convex
objects which have not been constructed by the ConvexBase::convexHull
function.
Does this sound ok for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, adding a method hasDoubleDescription() could help by checking the content of the pointers (if they are not NULL for instance)
src/shape/geometric_shapes.cpp
Outdated
if (other.normals) { | ||
normals = new Vec3f[num_normals_and_offsets]; | ||
std::copy(other.normals, other.normals + num_normals_and_offsets, normals); | ||
} else | ||
normals = nullptr; | ||
|
||
if (other.offsets) { | ||
offsets = new FCL_REAL[num_normals_and_offsets]; | ||
std::copy(other.offsets, other.offsets + num_normals_and_offsets, offsets); | ||
} else | ||
offsets = nullptr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same question applies here.
@jcarpent what do you think about changing |
Looks good to me. I do think we need to transition from raw pointers to smart ones in all the code. |
6ceb435
to
4a8a162
Compare
651813c
to
08d2dd5
Compare
python/collision-geometries.cc
Outdated
typedef Eigen::Map<RowMatrixX3> MapVecOfDoubles; | ||
typedef Eigen::Ref<RowMatrixX3> RefVecOfDoubles; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not totally correct. This is just a copy-pasting of previous lines.
python/collision-geometries.cc
Outdated
typedef Eigen::Matrix<double, Eigen::Dynamic, 1, Eigen::RowMajor> | ||
VecOfDoubles; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would call it VectorX.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Row::Major is not needed. You can also use Eigen::VectorXd
python/collision-geometries.cc
Outdated
typedef Eigen::Matrix<double, Eigen::Dynamic, 1, Eigen::RowMajor> | ||
VecOfDoubles; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Row::Major is not needed. You can also use Eigen::VectorXd
The default in Eigen is column-major (https://eigen.tuxfamily.org/dox/group__TopicStorageOrders.html) but `Matrixx3f` and `Matrixx3i` are used to store coordinates of points and neighbors. Row major is more appropriate.
and `primitive_indices`.
for `normals` and `offsets`.
for more information, see https://pre-commit.ci
f0161a4
to
a89bd24
Compare
[pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci
0926120
to
3ea3001
Compare
A polytope can be seen as either a set of vertices or a set of planes (normals + offsets).
The double description is normals + offsets.
In GJK/EPA we only use the vertices of polytopes. However, for computing normals/witness points, having the double description may be usefull in the future.