OpenSimulator Virtual World Server Case Study (part 3): Virtual World Server Power Savings by Dynamic Physics Tuning

Download Article

Download Virtual World Server Power Savings by Dynamic Physics Tuning [PDF 266KB]


As server data centers grow to support virtual world experiences, one concern is the expense of powering the servers. Most server applications can be idle when there are no connected users, but the requirements of a real-time, continuous, realistic world means world simulation continues even when there is no one to observe the interactions. The continuous operation of the virtual worlds introduces a new pattern of work that does not present an idle application for usual power management policies.

One question that arises is: how can a virtual world simulator be designed or implemented differently to enable power savings opportunities? In this article, we explore one potential method of power savings: lowering physics execution frequency to introduce more idle time. Reducing physics simulation frequency may introduce errors in the physics simulation, so we look at the tradeoffs between physics simulation correctness and platform power usage.

Tuning Physics

OpenSimulator ( is an open source project building a general purpose virtual world simulator. An Intel Labs project has been using OpenSimulator as a test case to understand the design requirements for the server portion of a multi-user virtual world system. The last article described stress tests applied to OpenSimulator and examined some of the implications of the server's design. This article explores tuning the virtual world server to reduce overall server power use.

One of the major components of virtual world simulation is the physics engine. The physics engine evaluates the positions and interactions of all the objects in the virtual world and computes collisions, gravity effects, and other physical properties of the virtual world. If there were a technique of throttling or 'turning down' physics calculations when no client was observing, there could be overall computation savings. But reducing the physics calculations might impact the accuracy of physical interactions in the virtual world.

Open Dynamics Engine ("ODE") is an open source physics engine that has been integrated into OpenSimulator as the default physics engine. OpenSimulator invokes ODE periodically to simulate a period of time - a simulation step or frame. If ODE is called 10 times per second, for instance, each call simulates one tenth of a second of real time. If the physics engine is invoked 5 times a second, it must simulate one fifth of a second. This results in more idle time (more time between the invocations), but reduces the opportunities for interactions between the physics operations and events in the virtual world. Thus there is a tradeoff between a higher rate of physics simulation steps for conflict reduction and increased accuracy, and a slower rate for computation savings.

Physics Correctness

There are many ways of testing correctness of physics engine computations. Most physics engines have a test suite to verify the operation of specific portions of the physics simulation. In order to capture long-term physics interactions, the testing method used for this analysis is to build a Galton box (see Figure 1) where balls are dropped on the top and bounce to one side or the other of the slats in an increasingly wide distribution. As the balls fall through the Galton box, the interaction of gravity and the collisions captures the overall operation of the physics engine.

The 100-level Galton box in the virtual world

Figure 1.The 100-level Galton box in the virtual world.

Physical Galton boxes have a mechanism to drop balls into the top of a uniform array of pins. The balls bounce through the pins and end up in a set of buckets at the bottom of the pins (see Figure 2). There will be more balls in the buckets in the center of the array and fewer and fewer balls in buckets at the edges. The traditional analysis of a Galton box for uniform-sized balls has the balls coming out of the last level of the slats with a binomial distribution which approximates a normal distribution.

This ideal distribution of balls leaving the Galton box is expected from a perfect, high-fidelity physics simulation. Modification of physics parameters such as frame rate will cause errors in gravity calculations or collisions that will show up as perturbations in the distribution of the balls as they exit the Galton box. Variance from the ideal distribution will be variations introduced by the physics engine and/or the operational setting on the physics engine.

Simple pictorial of a 2D Galton box.

Figure 2.Simple pictorial of a 2D Galton box.

Dropping the Balls

To quantify power saving benefits and simulation correctness, we used a 100-level Galton box, varied the physics frame rate, measured distribution of balls, and measured the power consumption of each run on a dual-processor Intel® Xeon® E5540 server system running Windows* Server 2008. The runs shown in Figure 3 are for 10,000 balls dropped through the 100-level Galton box.

The distributions shown in Figure 3 graph the ideal distribution (dashed line) and the measured bucket ball count (solid line). Higher physics frame rates correctly simulate the Galton box since the measured distribution closely matches the ideal distribution. As the physics frame rate is decreased (simulating longer periods of time with longer idle periods between), the measured distribution begins to vary from the ideal distribution. At 33 physics frames per second (Figure 3b), the simulation of the Galton box is reasonably accurate. By 22 physics frames per second, though, the simulation of the Galton box is failing and not resulting in a correct distribution.

Ideal and measured distribution of balls at the bottom of the Galton box

Figure 3.Ideal (dashed red) and measured (solid blue) distribution of balls at the bottom of the Galton box. (a) is 55 physics frames per second ("pFPS"), (b) is 33 pFPS and (c) is 22 pFPS. At (c), the distribution differs from the ideal distribution.

Saving Platform Power

The wall socket power for a whole system was measured while idle and while running the various Galton box simulations. Table 1 shows the number of watts expended for the physics calculations. This was computed by taking the idle platform wattage subtracted from the wattage measured while running a particular 10,000 ball experiment.

Physics Frames Per SecondWatts above idle

Table 1.Platform wattage to simulate Galton box at different physics frames per second

Looking at Table 1, the wattage required to perform the different frame rates reduces as the frame rate reduces. As can be seen, 33 physics frames per second shows itself to yield both correctness in simulating the Galton box and reduced power usage.

This demonstrates that, for this test, physics can be varied from high physics frames per second for accuracy and interaction correctness to a lower frame rate for power savings.


This article describes one way of saving platform power for physics operations by simulating physics at full speed when clients are in the virtual world, and reducing the simulation rate when there are no observers. There are many other mechanisms that can be reduced in frequency when there are no observers. For instance, sensors can reduce their testing frequency when there is probably nothing to sense, or artificially intelligent bots can become less responsive when there are no clients in the area.

Data center power is probably not one of the top design requirements for virtual world simulator designers, but as data centers and data center expenses grow, power savings will become important. The general technique of reducing the frequency of operation when there are no observers will lead to overall power savings in a data center running virtual world servers.

Related Articles

About the Author

Robert Adams is a software engineer in Intel Labs and is a member of the Virtual World Infrastructure team investigating systems architectures for scalable virtual environments.

For more complete information about compiler optimizations, see our Optimization Notice.


robert-adams's picture

The assets in OpenSimulator are stored as procedural shapes or meshes. The procedural shapes (modeled after the Second Life(r) 'prims') would be hard to generate from RGBD data. The meshes are possible although you'd have to create tools to load them into the asset store. So the answer is 'yes, but the glue to put the generated meshes into the world might be difficult".

Chris L.'s picture


Is there a way to leverage the RealSense or Kinect technology to dynamically build the OpenSimulator's virtual environment? I have been looking at the best open source virtual world simulators to use as a base for developing this capability.

With thanks,




sandeep-p's picture

thanks for the info...

wahid's picture

solar power is needed once for virtual world

brightonboy1's picture

hey I am building a server to host 1000 avatars on my photo realistic open simulator virtual world built by using Google street maps. I am going to buy an i7 extreme core processor and 12 gig ram and build a RAID 1 system. Am I on the right track PLEASE HELP!!

anonymous's picture

hey I am building a server to host 1000 avatars on my open simulator photo realistic virtual world built by using Google street maps. I am going to buy an i7 extreme core processor and 12 gig ram and build a RAID 1 system. Am i on the right track PLEASE HELP

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.