[Question] on page /source/tutorials/01_assets/run_articulation.html

[wdliu356]

Hi all. I'm new to IsaacLab and currently playing with the examples. For the run articulation example, I want to test how the physics_dt and render_interval would affect the simulation and find out something strange.I adjusted physics_dt to 1/1000 and render_interval to 1. I can observe the simulation runs super laggy because of a high demand of calculation power due to the high rate. This confused me since I'm using an RTX4090 which I think should be able to deal with the calculation real-time. But at least the performance (the frequency and duration) I see in the GUI is the same as what I see in the output of the main loop. The output is shown as follows:

With physics_dt = 1/1000 and render_interval to 50, I got output, shown as follows:

In this case, the simulation looks make sense as it is almost synchronized to real time due to a lower frequency of rendering. However, the frequency of the main loop is significantly reduced(shown in the second figure). Based on my understanding, the main loop in run_articulation.py is updating the physical simulation instead of rendering work, which is now conflict to what I observed. Is this a bug or is it designed to be like this?

[RandomOakForest]

Thank you for posting this. I'll move your question to our Discussions for follow up. Here is a summary to consider.

In the Isaac Lab run_articulation example, the parameters physics_dt and render_interval play crucial roles in determining accuracy, responsiveness, and performance.

physics_dt: The Physics Simulation Time-Step

• Definition: physics_dt (or sometimes just dt) defines the time duration of each physics simulation step, typically in seconds. For example, a physics_dt of 0.0167 corresponds to a 60Hz simulation rate (1/60 seconds per step).
• Effect on Simulation:
  • Smaller physics_dt (higher simulation frequency) results in more accurate and stable physics because there are more calculations per simulated second. This is particularly important for fast, dynamic motions or when simulating collisions and contacts.
  • Larger physics_dt (lower simulation frequency) can make the simulation run faster, but may introduce instability, inaccuracies, or artifacts (such as joints "snapping" or unstable robots)¹².
• Practical Considerations: A larger step size (>0.0333 seconds or <30Hz) is not recommended unless stabilization techniques are enabled, as it can degrade simulation fidelity².

render_interval: Steps Per Render

• Definition: render_interval specifies how many physics steps are performed for every rendered frame. For example, if render_interval is 4, the engine computes physics 4 times before updating (rendering) the screen once³.
• Effect on Simulation:
  • Higher render_interval: Reduces the rendering load, potentially improving simulation speed, but the visualization appears more "jumped"—the robot seems to move discontinuously between rendered frames, and quick events may be missed visually.
  • Lower render_interval (e.g., 1): The simulation is rendered at the same rate as the physics is stepped, making motion appear smooth and continuous. This is important for debugging, making videos, or human-in-the-loop applications.
• Impact on Control Policy and Articulations:
  • If your robot's control loop is tied to the rendering frame rate (as often is the case in the default setup), a higher render_interval can decimate control updates, potentially causing the robot to behave erratically or "jump" to new positions abruptly. Setting render_interval=1 supports smoother, more stable control responses³.

Relationship & Combined Effect

• The environment time-step—the time between environment or control loop updates—is the product of physics_dt and render_interval. For example, physics_dt=0.01 and render_interval=4 means the control loop runs at 40Hz (every 0.04s)⁴.
• Decoupling Physics and Rendering: You can optimize simulation performance by decoupling the physics step size from the rendering rate. For fast training or headless runs, use a high render_interval and a small physics_dt for accuracy⁵.

Best Practices

• For accuracy and stability: Use a small physics_dt (e.g., 0.005–0.016 seconds).
• For real-time visualization: Use render_interval=1 for smooth visuals and responsive articulation updates.
• For faster headless simulation: Increase render_interval to skip rendering most steps, but be cautious if your control loop depends on visual feedback or is synchronized with rendering.
• Tuning tips: If you observe unexpected joint jumps or unstable motion, try reducing render_interval to 1 and decreasing physics_dt for better behavior³².

Summary Table

Parameter	Meaning	Typical Value	Effect if Increased
physics_dt	Physics time-step per update	0.005–0.0167	Less accuracy, faster but less stable
render_interval	Physics steps per rendered frame	1–4+	Choppier visuals, faster simulation

Key Insight:
For the run_articulation example, physics_dt chiefly determines simulation fidelity, while render_interval manages how often you see the results—both affect performance and control behavior, and should be set based on the desired balance between speed, accuracy, and visualization quality³²⁴.

Example

If you set physics_dt to $ 1/1000 = 0.001 $ seconds (1 ms) and render_interval to 1 in Isaac Lab, here’s what you can expect:

Physics_dt = 0.001 (1 ms, or 1,000 Hz)

• This is an exceptionally small physics step size—much smaller than the typical values (like 0.0167 for 60 Hz or 0.0083 for 120 Hz).
• Simulation Accuracy:
  • Extremely fine time-stepping means you’ll have very high-fidelity physics—collisions, contacts, and rapid dynamics can be resolved with great precision.
  • There’s lower risk of numerical instability or unrealistic artifacts, even for very fast or stiff systems.
• Performance Impact:
  • The simulation will perform 1,000 physics calculations per simulated second, so your computation will be at least 10–16× heavier than a standard 60–100Hz simulation.
  • For complex scenes, many robots, deformables, or image-based observations, you will almost certainly experience a major slowdown in real-time performance. Isaac Sim and Isaac Lab may be unable to keep up, especially on consumer or even many workstation GPUs⁶⁷⁸.
• Practical Considerations:
  • It's usually not recommended to use such a small physics_dt unless you absolutely require it (e.g., rare high-frequency control, critical contact events in high-speed tasks).
  • If your system cannot compute these steps fast enough, your simulation time may lag behind real time, or even freeze with large workloads⁷⁶⁹.

Render_interval = 1

• This means that for every single physics update, there is also a render update—so you'd attempt to render at 1,000 frames per simulated second.
• Visual Effects:
  • You get the smoothest possible visual trace of all simulation activity, with no events visually “skipped."
• Performance Impact:
  • Rendering at this frequency is not feasible on almost any hardware.
  • The simulation will likely not be able to render at this rate, so “visual real time” will slow down dramatically—or the render loop will become a bottleneck⁸¹⁰.
• Recommendation:
  • For most uses, render_interval values higher than 1 are used to decouple heavy physics stepping from visual updates and maintain actual interactivity.

Combined Effect

• You are requesting 1,000 physics updates and 1,000 rendered frames per simulated second. In practice:
  • Your simulation will be extremely slow compared to real time unless your scene is trivial and your hardware is exceptionally powerful.
  • Neither most real robots nor most RL/control policies need such high-fidelity physics or visualization. You generally only need physics_dt this small for rare, high-speed contact-rich cases—otherwise, this parameter set will waste computation with little added accuracy.
  • For RL or policy learning, the agent may be bottlenecked on simulation speed, slowing training to a crawl¹⁰⁸.

When/Why You Might Use These Settings

• Ultra-high-speed robotic dynamics (e.g., simulating impacts or high-speed actuators not stable at coarser time-steps).
• Researching discretization effects or calibrating the simulation against very fine ground truth.
• Debugging tiny details in dynamic scenes (though in practice you would usually just decrease render_interval for debugging short windows, not for full training runs).

Summary Table

Parameter	Setting	Expected Result
physics_dt	0.001	Very accurate, but very slow simulation; high computational load679.
render_interval	1	Continuous visuals; but overwhelming rendering load and intense slowdown810.

Best Practice:

• For most applications, use a larger physics_dt (0.008–0.016 s) and a higher render_interval (4–32) for fast training or large scenes, only briefly switching to small step/rate for special debugging or accuracy needs⁸⁶¹⁰.

Footnotes

1. https://forums.developer.nvidia.com/t/questions-about-physics-dt/249254 ↩

2. https://github.com/isaac-sim/IsaacLab/issues/1708 ↩ ↩² ↩³ ↩⁴

3. https://isaac-sim.github.io/IsaacLab/main/source/api/lab/isaaclab.sim.html#simulation-context ↩ ↩² ↩³ ↩⁴

4. https://forums.developer.nvidia.com/t/h1-control-policy-not-working-in-custom-environment/331071 ↩ ↩²

5. https://isaac-sim.github.io/IsaacLab/main/source/api/lab/isaaclab.envs.html ↩

6. https://docs.isaacsim.omniverse.nvidia.com/4.5.0/reference_material/sim_performance_optimization_handbook.html ↩ ↩² ↩³ ↩⁴

7. https://forums.developer.nvidia.com/t/isaac-sim-too-slow-for-real-time-synchronization/260923 ↩ ↩² ↩³

8. https://isaac-sim.github.io/IsaacLab/main/source/how-to/simulation_performance.html ↩ ↩² ↩³ ↩⁴ ↩⁵

9. https://forums.developer.nvidia.com/t/how-can-i-raise-the-frame-rate-of-physics-simulations/218309 ↩ ↩²

10. https://isaac-sim.github.io/IsaacLab/main/source/overview/reinforcement-learning/training_guide.html ↩ ↩² ↩³ ↩⁴