Performance (Scaling/Inactivity)

Dec 6, 2009 at 12:05 PM

Hi,

I see things in the manual regarding scaling so that if fps drops below 60 it will slow down the physics simulator, but the methods and properties don't seem to be in fpe 2.1.3!

 

Same with the inactivity stuff, basically the physics I'm trying to improve are similar to the stacked boxes in farseer simple examples... except there's a load more boxes!! and they keep jiggling around, they never sit still.. I think this may be the problem.

 

 

Switching from SAT back to DistanceGrid seems to have improved it massively, but, still, not enough when there's 100+!

Coordinator
Dec 6, 2009 at 3:11 PM

The scaling controller is included in 2.1.3. You just create a new ScalingController, set it's properties and add it to the PhysicsSimulator object. It's decoupled from the PhysicsSimulator in 2.1.3.

The inactivity controller needs a lot of tweaking to get just right. It is not incorporated into the engine itself, so it does not know when forces are applied. This decreases the quality of the controller and makes it "dumb". Are you trying to stack 100+ boxes?

Dec 6, 2009 at 8:36 PM
Edited Dec 6, 2009 at 8:46 PM
genbox wrote:

The scaling controller is included in 2.1.3. You just create a new ScalingController, set it's properties and add it to the PhysicsSimulator object. It's decoupled from the PhysicsSimulator in 2.1.3.

The inactivity controller needs a lot of tweaking to get just right. It is not incorporated into the engine itself, so it does not know when forces are applied. This decreases the quality of the controller and makes it "dumb". Are you trying to stack 100+ boxes?

First things first, thanks a lot for taking the time to read and respond to my question genbox, I really appreciate it.

Second I guess I should have given my implementation of farseer a bit of context, my game is a map maker, this gives a lot of power to the end-user as to how many geoms/bodies exist, they can use the map maker to create world items, i.e crates, springs, and during testing a user noticed that if he just starts dropping crates everywhere, for example just dumping 40 to 100 on the screen and letting them fall/collide/stack they just keep jiggling and colliding, causing a lot of slow down.

I noticed  that switching from SAT back to DistanceGrid (even though I would prefer SAT) improved it massively, however I need to find a way of solving this, the crates at the bottom jiggle so slightly when they would be fine just becoming still, the physics don't need to be perfect, it's just a 2d platformer.

Thanks in advance.

 

also using the FPS counter it only shows 60fps max, the demos go up to 100, how do I achieve this and will it help?

Dec 8, 2009 at 2:32 PM

No ideas anyone?

Coordinator
Dec 8, 2009 at 3:42 PM

A 100 creates should be possible on a modern computer, but it is next to impossible to stack them perfect. The 4th demo in the SimpleSamples (I think it is the 4th - it is the pyramid) shows how to stack boxes with good performance.

You can use the inactivity controller to disable non-moving objects, but it can cause more problems that it solves, so you might need to analyze where to enable the controller and where to disable it.

Dec 8, 2009 at 3:51 PM

I don't understand what's going wrong in my implementation.

 

 

All my geoms seem to be putting their weight over to one side, i.e. the 4 collision points on the base of the rectangle only have the left 3 in red, the bottom right is black most of the time, this gives me the impression they're always leaning to one side

 

why is this?

Coordinator
Dec 8, 2009 at 5:53 PM

The weight is at the center of the geometry (centroid). The reason you see this behavior is that we only detect a certain amount of contacts (the black dots) and only resolve a smaller amount of contacts (the red dots). The loop that iterates the geometries start from one side. This causes the first couple of contacts to be resolved and the rest to be ignored.

You can change the amount of contacts detected and resolved using properties on the PhysicsSimulator object. Detecting more and resolving more causes a more precise simulation, but it will also be slower (use more CPU time and memory).