This project has moved and is read-only. For the latest updates, please go here.

Animated Geoms

Topics: User Forum
Jun 6, 2009 at 1:42 AM
Edited Jun 6, 2009 at 2:08 AM

Hi, firstly thanks for making what so far seems to be a really nice physics engine.


I know this question has been asked before, mainly with regards to resizing Geoms, but I would like to animate a large number of 'frames' with the Geom Vertices in different places.  These Geoms are of course colliding with an existing Geom in the scene, in fact the 'animation' will be the deforming terrain.

My first tests were based on pre-creating all the Geoms, one for each 'frame' of the animation, in the initialisation.  Then I would dynamically change the CollisionEnabled flag in the Draw update.

This definitely works great for smallish numbers of frames, say around 10, where there is little increase in CPU.  However, with a larger number of frames, say around 50, the slowdown is very noticeable, even though supposedly there are only two Geoms present with collision enabled.  I wonder if there is a nicer way to exclude them from the Collision tests?  I'm guessing it is searching a list and checking this collision flag, but I would imagine something like an 'active list' would be speedier.  Any thoughts?


Also, it takes a long time to initialise so many Geoms.  I guess I do need to calculate the grid for each new set of vertices, but maybe I could serialise this the first ever time and save it to disc?  also, if the deformation is minimal maybe I can save work somewhere along the line?


Lastly, I was wondering if when I'm colliding a polygon-based terrain with a circle, is the circle considered a polygon Geom in the collision algo?  It seems the circle code simply generates vrtices, but circle collision is really fast and I'm hoping that I can avoid the verts for that shape.  Many thanks for any help, and sorry for the multiple questions, the last unrelated one just cropped up.

Jun 6, 2009 at 1:09 PM

Normally you will have to precreate all the different geometries you need and then replace them when needed. However, with the 2.1 (coming soon) version you also have SAT (along with distance grid) - it does not have to precompute anything and you can create geometries on the fly.
With that being said, there still is a overhead of constantly creating objects and removing them. Using pools is a good idea when doing something like that.

Just as a quick note: If you have several geometries with the same shape, you can clone them instead of creating new geometries. this will also clone the distance grid and cut down computing time.

As for the circles. All circles are threated like polygons for simplicity. This will change in the next version.

Jun 6, 2009 at 1:43 PM

That's brilliant, thanks for your answer.  Everything is clear now!

BTW, I was thinking about making some kind of inherited Geom class which contained multiple frames of vertices, which only computed collision with the current frame.  This would then save on looping through Geoms added to simulation, finding which need to be computed based on Collision Enabled (the inherited Geom class would have just a global CollisionEnabled flag).  It could also automatically save the precomputed grids to disc to save loading, but I don't know whether this would work with the 360.  I'm guessing from the sound of it SAT might allow deformations (I'm not familiar with it), in which case this work might be pointless.  It seems like I should hold off trying to write a workaround until the new version is out.

Again, thanks for your prompt help and good luck with development (or project management!).  Cheers,



Jun 6, 2009 at 1:52 PM

Instead of looping the list of geometries and checking each for the CollisionEnabled flag (not that big of a deal tho) you could just maintain your own list of enabled/disabled geometries. Geoms are classes and if you store the geom in your own list, you just store the reference to the geometry. Very cheap in memory and depending on your implementation (looping, checks, other stuff) you could gain some in performance.

SAT does allow deformations since it has no precomputation of data. You can download the latest source code checkin from the "Source Code" tab here on Codeplex. Open the AdvancedSamples and switch the preloading demo to use SAT instead of DistanceGrid. (PhysicsSimulator.NarrowPhase = new SAT(PhysicsSimulator);) As you will see, the preloading is (almost) useless because of SAT.

Jun 6, 2009 at 2:31 PM

@rhumba: I would really like to see how you have done your animation. If you don't mind please send me your test case so I can review it and try to find the best solution. I am also working on animating geoms, but I am trying to use the SAT collider and bones just like 3D models.

Jun 6, 2009 at 7:34 PM

Hi Matt, bones eh?  It sounds like your implementation will be a lot more elaborate and certainly more efficient.  Mine is just as you would imagine, a very simple swap of which frame has CollisionEnabled, and no attempt is made to cope with any issues related to the jumps in vertex positions - it just relies on the distance moved being minimal.  To avoid polluting this space I have put the code online at my site:

(case sensitive)

The code is in the format of a demo, which I added on to the SimpleSamplesXNA demo in the main 2.01 branch, just for testing.  It takes a while to initialise, its still using the old Distance Grid method.  For now the terrain is simply scaling up and down, but I will need to implement much more complex deformations at a later date.  I also envision having many hundreds of frames, unless I can programmatically change the verts instead of precomputing them all.


BTW: I tried out the SAT branch, but just running the demos seems to max out my CPU.  I thought it was a VSync issue, but changing SynchroniseWithVerticalRetrace to true had no effect, and the timestep is fixed.  Nonetheless, the demos do run on my machine (2.8GHz dual core AMD64 4Gb RAM) albeit below 60Hz refresh.  The dynamic geometry creation seems to be really nice, I was thinking about using that as a base for deforming geometry but I decided against it when I noticed the framerate and CPU... probly just my mistake tho..

All the best



Jun 6, 2009 at 8:34 PM

The demos you ran are just the unedited ones from our source control? We did change some parameters, but it should not run at 100% cpu all the time. Can you tell me a little more details about it?

Jun 6, 2009 at 9:48 PM

@rhumba: Thanks very much for showing me your technique. The reason it wasn't working with SAT is because SAT requires convex geoms only. Your half pipe is very much concave. I am going to modify it a tiny bit to see if SAT can help with your loading times. I'll definitly post my code when I get time to work on it.

Jun 6, 2009 at 11:58 PM

@rhumba: Your technique was impossible to change to SAT. That's not to say that it's simply impossible, just impossible the way you have it set up. I think I will definitly have to write some code to try and use animated geometry in Farseer. I always say how easy it should be but I never have an example to show how it's done. Give me some time (maybe a few weeks) and I'll see what I can get working.

Jun 7, 2009 at 6:07 PM
Edited Jun 7, 2009 at 6:12 PM

Hi, this is interesting..

I just got a chance to download a clean version, the latest 54093 changeset, and the same thing happened for me (50% CPU on a dual core, ie. maxed out) when I compiled and ran the SimpleExamplesXNA projects for the two branches (main and FP2.1SAT).  I noticed there were some differences in the constructors between the two FarseerPhysicsGame.cs files.  The main branch has:

_graphics.SynchronizeWithVerticalRetrace = true;

TargetElapsedTime = new TimeSpan(0, 0, 0, 0, 10);
IsFixedTimeStep = true;


The differences in the SAT branch are simply SynchronizeWithVerticalRetrace set to false, and the targettime TargetElapsedTime set to 25ms.  Changing VSync to true for the SAT version had no effect on the CPU, but when I changed the TargetElapsedTime from 25ms to 10ms, suddenly CPU was a pleasant 1-5% again.  I also got the correct 60Hz refresh, as I do with the main branch SimpleExamplesXNA demos.  But this is strange to me, decreasing the TargetElapsedTime should make it try to run the physics updates more rapidly, which should use more CPU... no?!  Seems like maybe the updates are getting behind and trying to catch up or something, timing issues?  but that would make it an XNA thing I guess...

Anyway, I can also try to test it on a Vista laptop when I get time, but for now here are the details of my system:


XP Pro 32-bit

2.8GHz dual core AMD64



XNA 3.0


Hope this helps.


@mattbettcher : That's great, I would certainly love to see some nice animated geometry demo, of course have all the time in the world =)  Yes I love concave shapes even if they are a pain, but I don't really mind splitting them anyway, even if it would have to be split at every edge for a shape like that..

good luck with development guys!

Jun 7, 2009 at 7:39 PM

Oh, that helps a bit :)

The source code under SpecialBranch is not used anymore. We merged the changes into the main tree and some changes has gone into the main branch SAT implementation since then.
Use the normal branch and take a look at the AdvancedSamples that uses SAT.