> Yeah, sound like a reasonable thing to do. However I'm not sure how much > our av is loading the CPU side when they are stationary (physics should be > in "rest" mode), would need to investigate a bit. For us at Meshmoon I > need > to optimize many things in the js script side before doing things like > this, although this is a easy thing to add quickly. Mainly I'd need to > implement the few optimizations from the Tundra example avatar scripts. > Using only one script engine and using the EC_PhysicsMotor to drive the > movement on the c++ side. But our av script has lots of other optimization > the core example does not have, we have been running 30-40 avatars with > our > script without server breaking a sweat.
We profiled (moving) avatars some time ago with Jukka and some of the largest bottlenecks were avatar script execution, signaling of a moving avatar's transform change internally (EC_Placeable signals) and physics collision event handling calling to script code. When an avatar is sitting, the rigid body should already go to rest automatically, there are no more collisions or movement signaled, and the only significant overhead is the constantly executed script code. However it's good to verify that the rigidbody actually goes to rest and isn't being "forced" awake by any script code. In the Bullet library, physics simulation for a resting object is very cheap CPU-wise already. - Lasse -- -- http://groups.google.com/group/realxtend http://www.realxtend.org --- You received this message because you are subscribed to the Google Groups "realXtend" group. To unsubscribe from this group and stop receiving emails from it, send an email to realxtend+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
