Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

avatar sitting as an optimization (Fw: [Opensim-dev] Load test today)

27 views
Skip to first unread message

to...@playsign.net

unread,
May 15, 2013, 12:32:22 AM5/15/13
to real...@googlegroups.com
Just for info about where the Opensimulator side is with regards to scalability and stability for meetings now,
 
and this particular point about sitting as a way to optimize is I think very clever and something that we could apply with avatars on realXtend too, no? just disable physics when sitting disables movement. IIRC also with Tundra and rex&meshmoon AV apps physics has been a bottleneck. I think Opensim adopted this from SL.
 
sitting-at-an-airportly yours,
~Toni
 
From: Diva Canto
Sent: ‎Wednesday‎, ‎May‎ ‎15‎, ‎2013 ‎2‎:‎34‎ ‎AM
To: opens...@lists.berlios.de
 
Thanks everyone who came to the load test today. We hit 121 people
(actual viewers) spread through 4 neighboring regions joined at a
corner, running on the same server, with practically no chat lag and no
sim crashes! People were chatting all the way through for 90 minutes.

The goal of these tests is to find out how many people can fit in a
virtual gathering scenario, so we ask everyone to sit down instead of
running around. Sitting down not only captures the scenario well, but,
technically speaking, the avatars are removed from physics, which makes
the sims not have to work so hard.

The test grid was running the latest code from the dev branch, with no
additional improvements.There were a few quirks here and there; we'll be
analyzing the logs in the next few days.

We'll be making a few more of these load tests in the next few months.
Next time, we'll announce it in advance and more widely.
We would like to reach the 200 people mark soon!

Diva
_______________________________________________
Opensim-dev mailing list
Opens...@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Jonne Nauha

unread,
May 15, 2013, 3:12:04 PM5/15/13
to realXtend
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.

Would be fun to get to 200 avatars with Tundra before OpenSim :) Of course it might be hard to compare the things you can do with your avatar, smoothness of movement etc. but still. OpenSim has quite the leg up on the optimization work, I think they've been doing it for years now (I remember in ~Naali times when they wanted 100 avatars and were working actively on that goal with Intel if i remember right).

Best regards,
Jonne Nauha
Meshmoon developer at 
Adminotech Ltd.


--
--
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+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

"Lasse Öörni"

unread,
May 15, 2013, 3:25:14 PM5/15/13
to real...@googlegroups.com
> 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


Reply all
Reply to author
Forward
0 new messages