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


Topics: Developer Forum, User Forum
Jul 10, 2009 at 3:39 PM
Edited Jul 10, 2009 at 3:41 PM

Hey genbox or matt (or anyone) i just found this random physics engine on the net that i have never seen before called physics 2d

After some searching around about it i found out that thats where our SelectiveSweep comes from.
But anyway i was wondering if you knew how in the 2.0 version of that from early 2008 how it can make 7500 balls that can all collide with each other with gravity run at 20 fps.

It just didnt make sense how come its so fast or is there something im missing (like is it really inaccurate or something) 7500 objects just seems like a huge amount.
Anyway i just found it suprising because i always thought farseer was quite fast and was just wondering what everyone elses thoughts where.

Also it had particle physics i think that worked differantly to its reguler stuff.

Is there anything that would be useful from this in farseer? I dont know what are your thoughts.

Jul 10, 2009 at 5:27 PM

I know Physics2D (called now) very well. We share a lot of stuff as you can see on the acknowledgment wiki page (Bioslayer).

When it comes to balls-only you can create some very fast algorithms for both determining if they are near each other, especially if they are the same size. I've never seen 7500 geometries being simulated at the same time with real physics. Iterations solvers like the ones used in both and Farseer Physics are linearly in complexity. Reducing the accuracy in the solvers does not improve performance a lot. Never aimed to get 7500 balls simulated at the same time, so I'm not sure what exactly has been done to make it possible.

Do you have a link to the demo with the balls?

As for Farseer Physics, we are very fast but also very inefficient. That might sound crazy but let me explain:

Our algorithms are optimized for speed. Each algorithm is also as simple as they get. We optimize them in terms of garbage generation, data copying (cache coherence) and the like. But, because our algorithms are so simple they can also tend to be inefficient. There is a lot of places where we could use faster algorithms and a lot of places where we could cache the results for later use (like warmstarting).

So why don't we update all our algorithms to the more efficient ones? well, our aim was a simple and powerful physics engine that anyone could learn and use. I write "was" because we are kinda going away from that aim in Farseer Physics 3.0. In 2.x you could download our source code and use it as a reference in your own project. If you want to build your own physics engine, Farseer Physics is great source of simple code ready to use. 3.0 on the other hand will be a little more complex and will contain a lot more efficient algorithms.

As said before, the 3.0 version will be based on Box2D and 2.x was based on Box2D Lite. The difference is huge. Box2D is very well optimized (in C++ tho) and has state of the art algorithms to simulate physics (that feels like real physics) while keeping performance at its highest.

Anyway, back to the topic. The particles you talk about is something I've been wondering a lot about. I eventually came to the conclusion that Particle Systems are not a job for physics engines and that is why I also joined the Mercury Particle Engine project. Mercury now has a Farseer Physics modifier that makes it possible to integrate physics and particle systems into one system. We could support particles (a single point) that support colliding with polygons. That is useful for raindrops or other small particles that should react to the environment.

Jul 11, 2009 at 3:09 AM

Thanks for the reply.

I have been playing with the Mercury Particle Engine for the last few weeks.
I like it alot and its very fast, which is good :)

Is there anyway of spawning a new particle of a certain type when one dies?

Also for the 7500 balls they were all the same size and they are in the sample project (2nd last one i think)
and while it only got 20 fps i was impressed.

Also i was playing around with the 3.0 in the svn and i couldnt get it to render anything but when you click its spawning objects ya?
with 1500 objects i still got 40fps in that testbed which is a huge improvment i thought, so great work on that.

As for farseer 3.0 would it be possible to support particles (single points) that support colliding with polygons. (even if they only supported colliding with boxes and circles for speed)
Would there be many optimizations that could be done for single point physics?

Jul 11, 2009 at 6:11 PM

To spawn new particles of a certain type, you have to create two emitters. If you for example want fireworks that consist of a trail and explosion, you will need an emitter for both the trail and the explosion. You simply fire off the trail emitter for 5 seconds in a random upwards direction and when the 5 seconds are up, you dispose the emitter and fire the new one (the explosion one).

Oh, I've never run that sample, simply because it never wanted too on my machine. I had a lot of trouble with the samples because I run 64bit. Even building the project in 32bit would not make it work.

The FarseerPhysicsIntegration sample has just been reworked. Matthew (from MPE) had an idea of making a pooltable and he just finished it. There was a bug where nothing would render (nothing in MPE at all), that is fixed now.

The testbed you ran is a huge improvement over Farseer Physics. It has a lot more features, is more accurate (improved stacking, more real physics) and very efficient. I might make a ball sample some day, just to compare.

and yes, it would indeed be possible to support particles that support colliding with both edges, polygons and circles. In 3.0 we use the SAT (Separate Axis Theorem) narrow phase algorithm to determine the normal, depth of penetration and the like of a collision. Engines that use the distance grid narrow phase collider have some advantages compared to SAT based engines. One is that you have a grid you simply compare your polygons against and then you have the required data. Pretty simply and pretty fast if you precompute the grids and reuse them. (the in the ball sample). The distance grid is also very good for particle physics since you are basically comparing a single point against a grid all the time (with polygons) - that is exactly what particles are! So supporting particles with the distance grid comes naturally.

There is a great article over at polygonal labs (the guy who made motor2) about this:

He calls it a signed distance field and that is more descriptive that distance grid (and its real name), but distance grid is easier to comprehend.