Home | Tutorials | Wiki | Issues
Ask Your Question
0

Why actors slow down the simulation considerably

asked 2018-07-31 11:16:24 -0600

okan gravatar image

Although actors in Gazebo simulation is not simulated as a physical object, why they are slowing down the simulator considerably. The default walking animation with 20 actors reduce the real time factor of the simulator from 0.96 to 0.40 on average. I think this is quite limiting to use swarm of actors in a world. Is there way to speed up the processing?

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
1

answered 2018-07-31 12:49:03 -0600

updated 2018-07-31 13:01:03 -0600

Check out this blog post by Michael Huang:

Excerpt:

In this design, to animate each Actor in the scene, the poses (position and rotation angles) of each bone in the skeleton are calculated on the server side, then updated to the client side one by one. The client side then uses the bone poses to transform the mesh vertices. Although the final rendering of the transformed mesh with textures is done on the GPU, this design causes significant communication overhead for large crowds. In addition, it slows down other parts of simulation because all bone pose calculations are done by the CPU. As a result, the overall simulation performance is not satisfactory. I was only able to get 10 FPS for 16 Actors for real time simulation (1:1 ratio of simulation time to real time).

My first attempt to improve the design was to remove the communication overhead. To do that, I rewrote the Actor implementation on the server side to just send the Actor pose (output from Menge simulation) at each time step to the client side. The client side was also modified to directly use the Ogre3d library functions to update the individual bone poses based on the actor’s pose and simulation time, “software skinning” in Ogre3d terms. With this improvement, we could simulate up to 64 actors at real-time speed and interactive frame rate. The design shown in picture below:

Then to further improve the performance, I implemented “hardware skinning” in which all the animation related calculations are done on GPU. This design, shown in Figure below, utilizes the GPU vertex shader to offload vertex transformation calculations from CPU. The gzclient code on CPU then only controls the frame of the bone animation data to be used at a particular iteration (simulation time step). This greatly improves the performance, and allowed up to 625 characters to be rendered in real time simulations. The shader program is written in Cg language, similar to the hardwareSkinningFourWeights_vp in Ogre3D sample code, only slightly modified to handle more bones.

Michael Huang also shared his forks of Gazebo and the SDFormat library:
https://bitbucket.org/michaelhuang16/...
https://bitbucket.org/michaelhuang16/...

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2018-07-31 11:16:24 -0600

Seen: 127 times

Last updated: Jul 31