Adding cone primitives.

[bperseghetti]

🦟 Bug fix

Summary

This helps add the missing cone geometry for primitive/basic parametric shapes:

And is also valuable for visualizations of emitters/source that typically have conic-based spread as seen in this acoustic attack on an IMU by showing the affected area:

Associated PRs:

• Adding cone primitives. gz-gui#621
• Adding cone primitives. gz-math#594
• Adding cone primitives. gz-msgs#442
• Add Cone as a collision shape gz-physics#639
• Adding cone primitives. gz-rendering#1003
• Adding cone primitives. gz-sim#2410
• Adding cone primitives. #1418

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[ahcorde]

Do you mind to add the Python binding ? or if you dont' have time just open an issue.

[ahcorde]

And additional note. Probably you should close all PR which are targeting harmonic, then we will backport them as required. @azeey. other thoughts on this ?

[bperseghetti]

Do you mind to add the Python binding ? or if you dont' have time just open an issue.

Added all the pybind and a bunch of tests for everything as well:
d9154be

[ahcorde]

Just some small nits, but LGTM

[azeey]

Can you merge from main to fix CI?

[bperseghetti]

Can you merge from main to fix CI?

Done!

[codecov]

Codecov Report

Attention: Patch coverage is 98.24561% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 92.48%. Comparing base (7af63cb) to head (07c1573).
Report is 16 commits behind head on main.

❗ Current head 07c1573 differs from pull request most recent head 3cd4b3b

Please upload reports for the commit 3cd4b3b to get more accurate results.

Files	Patch %	Lines
python/src/sdf/pyCone.cc	94.11%	1 Missing ⚠️
python/src/sdf/pyGeometry.cc	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1418      +/-   ##
==========================================
+ Coverage   92.45%   92.48%   +0.03%     
==========================================
  Files         134      137       +3     
  Lines       17820    17954     +134     
==========================================
+ Hits        16475    16605     +130     
- Misses       1345     1349       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[azeey]

Has the issue with COM being different from the geometric center been addressed?

[bperseghetti]

Has the issue with COM being different from the geometric center been addressed?

Not sure, @scpeters any particular thoughts?

[scpeters]

Has the issue with COM being different from the geometric center been addressed?

Not sure, @scpeters any particular thoughts?

apologies, I was working on it and then decided I wanted to implement gz sdf --print --expand-auto-inertials in #1422 instead of manually computing a bunch of inertial values

I see two options for defining the origin of the cone shape for purposes of object placement in SDFormat (a different origin may be assumed in other parts of our API, but this is just focusing on SDFormat):

1. Shape origin at the center of the cone's bounding box (or bounding cylinder). In this case, placing a cone with length L with base down on a ground plane at Z=0 can be done by setting the initial Z pose of the cone to L/2. This would allow the cone to be placed in the same way as a cylinder. (Example world file placing multiple unit shapes with the same initial Z poses in scpeters@3ad5655).

2. Shape origin at the centroid of a cone with uniform density. For a uniform-density cone with length L, the centroid is L/4 above the base, or L/4 towards the base from the center of the bounding cylinder.

I prefer option 1 for the following reasons:

• I think option 1 is more intuitive for placing geometry since it allows similar placement of a cone and cylinder with the same poses (it will place the base of a cone in the same location as a cylinder base).

• While option 2 does not require specifying an //inertial/pose value when the code has uniform density, I think is not worth the trade-off for making geometry placement less intuitive by not following the pattern used by the cylinder, the most similar shape to a cone. This has little value for static shapes (which have no inertial properties) and for objects with non-uniform density (which will need the //inertial/pose to be specified anyway).

[scpeters]

sorry I missed updating one test

[bperseghetti]

sorry I missed updating one test

No worries, thanks for helping!