Why actors slow down the simulation considerably

edit

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/...