Gazebo Performance Tuning Guide

[kscottz]

I know I've run into GZ performance issues with the TB4, and [others seem to have the same problems](#Gazebo General > Performance of gazebo harmonic vs newer versions).

There is a laundry list of potential modifications to stock Gazebo that can address these issues, including:

• Swapping Ogre for Ogre 2
• Swapping the physics engine to Bullet Featherstone
• Using simpler models
• Adding hardware acceleration for various functions.
• Performing LIDAR simulation on a GPU
• Disabling PBR
• Many more that I am probably not aware of.

Desired behavior

We should create a guide that walks users through enabling these changes to improve their Gazebo performance / RTF.

[peci1]

Pretty good guide here: https://www.blackcoffeerobotics.com/blog/gazebo-simulator-5-ways-to-speedup-simulations .

[kscottz]

Thanks Martin!

[ammaarrahmed]

hey @kscottz , I came to this issue from your message to the GSoC Zulip chat channel , I looked through the docs repo structure and the linked Black Coffee Robotics article.

Proposed plan for a first pass (intentionally small scoped) :

• Target Jetty and Harmonic first, instead of trying to cover every supported release in one PR. The docs site is already release-scoped, and some tuning advice is version-sensitive.
• Add one release-specific page under the existing tutorial tree for each release
• Organize the guide by bottleneck / tuning area rather than by subsystem ownership. Tentative outline
• Use the Black Coffee Robotics article as source material only, not as direct content. It has some useful concepts to adapt, but it also includes Gazebo Classic-era examples that should be rewritten into Gazebo docs style.
• Reuse and cross-link nearby existing docs instead of duplicating them
• For issue items that need validation before documenting them as recommendations, I would explicitly gate them during drafting.

My preference would be to keep the first PR focused on supported, clearly documented Gazebo tuning levers, and put experimental or third-party items into either:

• a short “optional / ecosystem references” section, or
• a follow-up issue / PR if they need deeper validation.

Out of scope for the first PR, unless there is strong preference otherwise:

• a new top-level cross-version landing page
• benchmarking or new performance measurements
• backporting the guide to every supported release in one shot

If this scope sounds reasonable, I can draft the Jetty + Harmonic pages with a shared structure and keep release-specific differences only where they actually matter.

[kscottz]

@ammaarrahmed feel free to take a shot at this. Please keep it simple for your first contribution. We're aiming for "better" not "perfect and comprehensive".

It sounds like the AI is telling you to do a lot of things that are unnecessary. I would target Jetty only and just list the possible performance tweaks I listed. We can back port this to older versions of Gazebo in subsequent PRs. If a tweak is well documented somewhere else just link to it with a brief description. We can always add more material later.

For issue items that need validation before documenting them as recommendations, I would explicitly gate them during drafting.

I don't understand what you are trying to say here.

[ammaarrahmed]

@kscottz Makes sense, thanks.

I don't understand what you are trying to say here.

By that line I just meant I didn't want to turn every possible tweak into a strong recommendation without checking it first on my local setup.

I'll keep the first PR simple: Jetty only, short guide, straightforward performance tips, and links out where something is already documented elsewhere. Then we can expand it later if needed.