Runtime creation of physic objects

Jun 18, 2008 at 8:14 AM

I am working on a small Farseer demo, where I need to create new bodies and geoms at runtime. I got it up working yesterday, but observered servere lag upon creating two new body/geom pairs in a single frame. Maybe about 1 second of wait. Anyone had succes with runtime creation of new bodies and geoms can give me some advice? I will look into it some more later this week, and find out exactly where the performance go.
Jun 18, 2008 at 9:47 AM
After reading up abit, I can see that Farseer has to precompute a distance grid per Geom in order to perform its runtime collision detection. Hence, Farseer is not suited for runtime creation of new geoms..

In my little demo, I have implemented a geometry cutter (polygon clipper) for cutting up geometry at runtime. I got this up and working with the Farseer physic objects, but its very slow to create the new geoms when making a cut.

I don't know if I can do anything to get rid of this distance grid computation overhead.. Since the new geoms are actually made from the old geoms, maybe they can somehow reuse parts of the old distance grid, and only make some corrections to it? May be way too advanced ;)
Jun 18, 2008 at 8:48 PM
Only simple "solution" is to reduce the collision grid cell size from the defualt 1, to 2 or 3.. Then it apparently becomes much faster.. I have yet to observe how many collision errors I will get from this.
Jun 19, 2008 at 10:04 PM
Edited Jun 19, 2008 at 10:05 PM
This problem is not just with Farseer, it's a common problem in game development.

The most widely used solution to this problem, is to instantiate the objects before use. This gives two performance (perceived performance by the observer):

1. Instantiation is not done at runtime. You can do all your computations while the application (in this case, the game itself) is idle (at game startup/loading a level). This prevents the lags at runtime.
2. While you instantiate the objects beforehand, you could also use this opportunity to create a caching mechanism. When you create a object and do all your computations, you put the object into a collection for later use.
When you need the object, you pull it out of the collection, use it and -reuse- it. The reuse is the important part, there is no need to create 100 objects, use them and destroy them. Instead, you cache them, use them, and reuse them... over and over again.

Hope this helps you with your problem.

EDIT: Oh, and also remember that it's necessary to create a new thread for the creation of the objects, or your application will freeze while creating them.
Jun 20, 2008 at 9:23 AM
Box2d (on which Farseer is based) has no problems with runtime creation of geoms, since collision is not based on a initializing a distance grid.

Notice, I wrote that I have to create new geoms at runtime, i.e. since the player/user can cut in the geometry at runtime.. I cannot create my objects before hand, since I naturally do not know how the cuts will be. I could create the geoms in a bew thread, still resulting in a delay in the cut, but hopefully wont stall the entire game.

It is a limitation of the collision method used in Farseer, not in physics engines in general.

While Farseer is great, we need a port of the latest Box2d to XNA :)
Jun 22, 2008 at 9:04 PM
Edited Jun 22, 2008 at 9:08 PM
Arh, okay. I did not understand your intentions fully.

Is it necessary to have a collision support on your objects while they are being edited?

When you write that you need a port of the latest box2d, I assume that you already know about
Jun 23, 2008 at 10:00 AM
Don't know what you mean by "Is it necessary to have a collision support on your objects while they are being edited?"..

Imagine er game where you can cut geometry in parts while you play.. Thats what I am doing. I already got it up and working with physics in Farseer, but suffer from the discussed performance issue. My polygon clipping algorithms can however easily be moved to another engine.

Thanks for the link. Already seen it, and it sounds like it is in early beta.