Sphere-terrain optimization.
Posted: Sun May 22, 2011 1:55 pm
Hi Norbo, you dropped by on this thread the other day:
http://www.olhovsky.com/2011/05/physics ... sion-done/
You seemed to suggest that 400 spheres takes 25ms to update on the XBOX.
So I did some testing to see how performance works out on the XBOX 360 in my own simulator, and in BEPU.
I documented some of my testing here:
http://www.olhovsky.com/2011/05/my-own-physics-or-bepu/
In particular, I modified the terrain demo to add spheres with the following code, and removed the adding of boxes.
I found that adding 392 spheres this way caused physics updates to take about 80ms once the spheres hit the terrain. It takes a couple of minutes before this speeds up very much (and it gets worse first).
Can you help me figure out what is costing the most time, or if perhaps I am doing something wrong?
I don't care very much about rotation, would adding a special case for spheres that don't rotate help performance significantly? Is the sphere-terrain collision expensive -- maybe I could start optimizing there?
I'm willing to give up some detection precision. Mostly these spheres will not be moving too quickly. Maybe I should cap the number of sphere-cast steps. I care very little about time of impact precision. Maybe TOI sorting is costing a lot?
I'm not familiar with your broadphase technique. It seems that about 80 active spheres takes about 20ms to update on the XBOX (obviously this depends greatly on their positioning). I might be able to get away with that if I can simultaneously have ~200-300 inactive spheres at the same time. I'm off to go test that next.
EDIT:
I tested BEPU with a much flatter terrain, and updates took 30ms with 392 spheres. Holy crap, that's awesome! So BEPU clearly wins in the fight against my simulator. I'll start transitioning everything over to BEPU in the next day or two.
http://www.olhovsky.com/2011/05/physics ... sion-done/
You seemed to suggest that 400 spheres takes 25ms to update on the XBOX.
So I did some testing to see how performance works out on the XBOX 360 in my own simulator, and in BEPU.
I documented some of my testing here:
http://www.olhovsky.com/2011/05/my-own-physics-or-bepu/
In particular, I modified the terrain demo to add spheres with the following code, and removed the adding of boxes.
Code: Select all
Random rand = new Random();
for (int i = 0; i < 7; i++)
{
for (int j = 0; j < 7; j++)
{
for (int k = 0; k < 8; k++)
{
Vector3 position =
new Vector3((float) rand.NextDouble()*10 + i*128,
400 + -j*2,
(float) rand.NextDouble()*10 + k*128);
float radius = (float) rand.NextDouble() + 1;
Space.Add(new Sphere(position,
radius,
radius * radius * radius));
}
}
}
I found that adding 392 spheres this way caused physics updates to take about 80ms once the spheres hit the terrain. It takes a couple of minutes before this speeds up very much (and it gets worse first).
Can you help me figure out what is costing the most time, or if perhaps I am doing something wrong?
I don't care very much about rotation, would adding a special case for spheres that don't rotate help performance significantly? Is the sphere-terrain collision expensive -- maybe I could start optimizing there?
I'm willing to give up some detection precision. Mostly these spheres will not be moving too quickly. Maybe I should cap the number of sphere-cast steps. I care very little about time of impact precision. Maybe TOI sorting is costing a lot?
I'm not familiar with your broadphase technique. It seems that about 80 active spheres takes about 20ms to update on the XBOX (obviously this depends greatly on their positioning). I might be able to get away with that if I can simultaneously have ~200-300 inactive spheres at the same time. I'm off to go test that next.
EDIT:
I tested BEPU with a much flatter terrain, and updates took 30ms with 392 spheres. Holy crap, that's awesome! So BEPU clearly wins in the fight against my simulator. I'll start transitioning everything over to BEPU in the next day or two.