Add Cone as a primitive parametric shape.

[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:

• Add Cone as a primitive parametric shape. gz-gui#620
• Add Cone as a primitive parametric shape. #593
• Add Cone as a primitive parametric shape. gz-msgs#441
• Add Cone as a primitive parametric shape. gz-physics#638
• Add Cone as a primitive parametric shape. gz-rendering#1001
• Add Cone as a primitive parametric shape. gz-sim#2404
• Add Cone as a primitive parametric shape. sdformat#1415

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]

did you add cpp tests?

[bperseghetti]

did you add cpp tests?

Just added it now.

[bperseghetti]

@azeey what's the process for getting this merged in and available for everything else that depends on it?
IE: gazebosim/gz-physics#638

[scpeters]

@azeey what's the process for getting this merged in and available for everything else that depends on it? IE: gazebosim/gz-physics#638

For features involving pull requests to multiple repositories, I think the development process is easier to initially target the main branches (currently Ionic) and then backport. The reason it is easier is that we build nightly debians for Ionic on Ubuntu and build dependencies from source for macOS (windows is always built from source). When targeting a stable release, we would need to make a stable release or prerelease for the lower-level packages like gz-math in order to get working CI for higher-level packages like gz-physics. It especially can become a problem if we quickly merge and release a low-level package and then want to change its API/ABI based on insights from reviewing a higher-level pull request. Landing the whole feature on main first will hopefully stabilize the desired API so it can be backported.

EDIT: this is a policy that we had discussed recently but not added to our contributor documentation, so I have proposed adding it to our recommendations in gazebosim/docs#440

[bperseghetti]

@ahcorde @scpeters here's the backport.

Review has been addressed

[bperseghetti]

Thanks, @scpeters @azeey can I get this released so the other CIs can work?

[scpeters]

Thanks, @scpeters @azeey can I get this released so the other CIs can work?

@bperseghetti the first step to making a release involves making a pull request to bump the version number and update the Changelog (see step 2 in the Gazebo Release Instructions - For Each Release). If you're interested to learn this process, that would be a good place to start.