Farseer Physics Engine 2.0 - Progress

Coordinator
Sep 28, 2008 at 5:34 PM
Edited Nov 4, 2008 at 11:27 AM
If you have not seen it yet, Farseer Physics Engine 2.0 Alpha has been released. Grab it here.
As I did before with the refactoring (seen here) I have created a thread where you can follow the development of Farseer Physics 2.0.

The list of features to be implemented:
  • Done: Increase performance/reduce memory footprint
  • Done: Rope/chain factory
  • Done: Path generator
  • Done: Texture2D to polygons
  • Done: Multithreading, object cache and resting bodies samples
  • Done: Broadphase collision event
  • Removed: Unified debug view for most platforms
  • Done: Write more documentation
  • Done: Bodies separation event - Thanks to AlexO for describing the implementation in the "Community requests - Farseer Physics 2.0" thread.
  • Removed: Extension to factories for setting bounciness
  • Done: Sensors (Collision event, no impulses)
Original thread with requests for features can be seen here. Thanks to everyone for their ideas and help!
This thread will be updated as features are implemented.
Coordinator
Sep 28, 2008 at 8:50 PM
Sensors is now done. Well, they were already done by crashlander, but somehow I did not see it.
The Geom class now have a new property: IsSensor

Set this to true and the Geom/Body will act as a sensor in your game. They will not react to other bodies and have impulses applied on them, but they will still fire the collision event when something touches it.
Coordinator
Sep 28, 2008 at 8:54 PM
The body seperation event is now done. Thanks to AlexO for the implementation details. I have tested the functionality and it seems fine.

Geom's now have a OnSeperation event that fires when Geom's seperate. The event is called on both Geoms (hint hint AlexO ;) ) and provides you with the 2 Geoms that seperated.
Sep 28, 2008 at 10:06 PM
Edited Sep 28, 2008 at 10:07 PM
Isn't this (sensor) achievable by setting a Geom's CollidesWith and CollisionCategories to CollisionCategories.None?
Developer
Sep 28, 2008 at 10:25 PM
@genbox - for bodies separation, is there any form of actual body separation? What I mean is Farseer sucks at separating bodies that are directly on top of each other. I would like would like some form of better separation when 2 geoms are created directly on top of each other. I've created something like this already but I feel it should be part of the engine.
Coordinator
Sep 28, 2008 at 10:48 PM
Edited Sep 28, 2008 at 10:50 PM
@Oranjoose - If you set those to none, it will not detect collisions at all. Sensors does collision detection, but does not compute impulses when a collision is detected. It can be achieved by setting the CollisionResponseEnabled (to false) and IsStatic (to true). CollisionResponseEnabled could be misunderstood as collisions is not checked, but it enable/disable impulse calculation instead.
I changed (created) the documentation of CollisionResponseEnabled to reflect this.

The new IsSensor property changes those settings for you.

@mattbettcher - If you are referring to the OnSeperation event, that's only fired when geoms are seperated from each other. What you are talking about is a whole different matter. I guess that creating 2 geoms on top of each other would cause them to get stuck in each other? Do you have a demo or some code snippet I can take a look at?
Coordinator
Sep 29, 2008 at 1:42 PM
Edited Sep 29, 2008 at 1:42 PM
I'm in the progress of writing more documentation for Farseer Physics 2.0.
It's about time we get a manual that contains the essential stuff. :)

If anyone is interested in helping me write the documentation, contact me and we will figure out what needs to be written.
Coordinator
Oct 1, 2008 at 10:51 AM
The multithreading sample has now been uploaded (source control), thanks to Laszlo Perneky aka Monster.

He changed the Getting Started samples demo4 to include multithreading. It might be subject to change since we want the samples to be as easy to understand as possible.
Oct 1, 2008 at 9:21 PM
Hey for Texture2D to polygons if you haven't done it already you might want to take a look at this per-pixel collision tutorial.  This may be a little confusing, but CalcHull gets the non-alpha edges of a Texture2D and stores it to a List of Vector2s (Points in this sample), but you could just make new Vertices.

 public void CalcHull()
        {
           
            uint[] bits = new uint[texture.Width * texture.Height];
            texture.GetData<uint>(bits);
           
            hull = new List<Point>();

            for (int x = 0; x < texture.Width; x++)
            {
                for (int y = 0; y < texture.Height; y++)
                {
                    if ((bits[x + y * texture.Width] & 0xFF000000) >> 24 <= 20)
                        continue;

                   
                    bool bSilouette = false;

                    //check for an alpha next to a color to make sure this is an edge
                    //right
                    if (x < texture.Width - 1)
                    {
                        if ((bits[x + 1 + y * texture.Width] & 0xFF000000) >> 24 <= 20)
                            bSilouette = true;
                    }
                    //left
                    if (!bSilouette && x > 0)
                    {
                        if ((bits[x - 1 + y * texture.Width] & 0xFF000000) >> 24 <= 20)
                            bSilouette = true;
                    }
                    //top
                    if (!bSilouette && y > 0)
                    {
                        if ((bits[x + (y - 1) * texture.Width] & 0xFF000000) >> 24 <= 20)
                            bSilouette = true;
                    }
                    //bottom
                    if (!bSilouette && y < texture.Height-1)
                    {
                        if ((bits[x + (y + 1) * texture.Width] & 0xFF000000) >> 24 <= 20)
                            bSilouette = true;
                    }
                    //bottom left
                    if (!bSilouette && x > 0 && y < texture.Height - 1)
                    {
                        if ((bits[x - 1 + (y + 1) * texture.Width] & 0xFF000000) >> 24 <= 20)
                            bSilouette = true;
                    }
                    //bottom right
                    if (!bSilouette && x < texture.Width - 1 && y < texture.Height-1)
                    {
                        if ((bits[x + 1 + (y + 1) * texture.Width] & 0xFF000000) >> 24 <= 20)
                            bSilouette = true;
                    }
                    //top left
                    if (!bSilouette && x > 0 && y > 0)
                    {
                        if ((bits[x - 1 + (y - 1) * texture.Width] & 0xFF000000) >> 24 <= 20)
                            bSilouette = true;
                    }
                    //top right
                    if (!bSilouette && x < texture.Width && y > 0)
                    {
                        if ((bits[x + 1 + (y - 1) * texture.Width] & 0xFF000000) >> 24 <= 20)
                            bSilouette = true;
                    }

                    Point p = new Point(x, y);
                    if(bSilouette && !hull.Contains(p))   
                        hull.Add(p);
                }
            }
        }
Coordinator
Oct 1, 2008 at 9:32 PM
Thanks SomethingNew.
I think Sickbattery from this forum has an implementation that he wanted us to have a look at, I will take a look at it when we get to that item on the list :)
Coordinator
Oct 2, 2008 at 10:47 PM
Update:

Done: Broadphase collision event

There is now a OnBroadPhaseCollision event in all broad phase collision detectors. Just like the normal Collision event on Geom, you can cancel the broad phase collision.

Canceling the event means that you prevent an arbiter from being constructed. So no impulses are calculated on the geom. It is sort of like a ghost to the engine :)
Coordinator
Oct 4, 2008 at 5:25 PM
Just wanted to update the community on the status of documentation.
We have gotten a lot of requestions to create better documentation, so we are doing a huge effort to accomplish this. I'm getting some help from mattbettcher in writing a quality manual and extending the samples.

So far I have written 14 pages of info on the collision detection and impuse systems. It should provide a good overview on how the collision and impuse system work in Farseer Physics.

There is also a section on how to optimize performance (have gotten 11 emails about this :) ) and also a section with most common issues experienced with Farseer Physics. Mattbettcher is writing about the joints and we will merge his pages with mine, sometime this week. Thanks Matt !

I hope you will come to like the new documenation, as much as I do.
Coordinator
Oct 5, 2008 at 4:38 PM
Time for another update.

The documentation is still going good. Just need the joints part from mattbettcher, he said he will have it finished by Monday.

And another thank to mattbettcher for providing me with a helper to create chains. I have implemented it into Farseer Physics 2.0 as a ComplexFactory. Still need to make the code a little more flexible before it's done.
Coordinator
Oct 11, 2008 at 9:45 PM
I've created an AdvancedSamples sample project in Farseer to demonstrate the more advanced features of Farseer Physics 2.0.

The multithreading sample is moved from GettingStarted samples to the AdvancedSamples.

And an update:
Good news on the progress: I've finished creating an example of using pools. The pool used is the same as Farseer Physics uses internally, so no need to create your own.
The performance improvement of using pools can be huge, so we thought it was a great idea to create such a sample.
Coordinator
Oct 11, 2008 at 10:52 PM
Done: Multithreading, object cache and resting bodies samples

Just completed the resting bodies sample using the Inactivity Controller. Thanks to Daniel (dp2208) for the Inactivity Controller, and permission to use parts of his performance test demo, in the sample.

If you decide to take an early look at the inactivity controller sample, enable the debug view (Press F1) and look at the update time, in the performance panel. Once the bodies are resting, it goes down a lot. Great for improving performance in some situations.
Coordinator
Oct 13, 2008 at 12:05 AM
Status update:

Almost done!
: Write more documentation

We are almost done with the documentation. We just need some finishing touches before it's ready, so stay tuned :)
Developer
Oct 15, 2008 at 12:01 PM
genbox, no offence, but may I ask if you have too much free time ;) ?
Awesome. I can't wait till I'm at home to check it out.

... and hopefully I'm going to find some time to rewrite my Texture2D to Polygon functions.
I will send the code to you whenever you want me to, but I'd like to add some comments and clean it up a bit.
Also I wan't to add some stuff ...
Coordinator
Oct 15, 2008 at 1:23 PM
Edited Oct 15, 2008 at 10:15 PM
@sickbattery - Yep, too much spare time. I think it's because I don't own a Xbox360 ;)

It would be great if you could send me the Texture2D to polygon code. I don't know if you got my email about it.
If you focus on the functionality, I can clean it up for you. I'll have to revise it anyway :)
Coordinator
Oct 15, 2008 at 10:23 PM
Status update:

In progress:
Path generator
Removed: Unified debug view for most platforms
Removed: Extension to factories for setting bounciness

Matt Bettcher has a "path generator" in the works. We will publish more information on it when it's more refined.

Please don't send me hate mails about the unified debug view being removed :) It's a hard thing to accomplish (impossible to make 100% cross platform) I removed it only to add it to Farseer Physics Engine 2.1 change list.

I've had a look at the extension proposal to the factories. While it's a good idea, it needs to be something more than just adding a single variable. For now, we keep the factories clean and simple.
Developer
Oct 16, 2008 at 3:36 AM
Just to let everyone know my "PathGenerator" is coming along great. Just to give everyone an idea of what the potential of this is imagine needing only a set of vectors that define a curve. Then you can decide how many objects to place on the curve, whether or not to connect them together with a joint, and even making endless sets of bodies. With this set of methods and factories you will be able to create -

Curved chains
Curved rope
Endless chains
Tracks
Conveyor  belts
Bridges
and probably a lot more...

Also on a side note - Ian (genbox) is totally right about the Unified Debug View. It's impossible to create on multiple platforms and be the same. We are looking to get an imporved version of the XNA debug view with some documetation along with a simple startup project template.
Coordinator
Oct 16, 2008 at 9:10 PM
There you have a little taste off what's coming. You will have to wait until we release to see what it's all about. ;)
Our todo list is getting smaller, this means we are getting closer to releasing Farseer Physics 2.0.
Oct 16, 2008 at 9:11 PM
I am new to your physics engine...but not C#.  I just completed my first book on asp.net/c# with a focus on building social networking communities.  Perhaps I could help you with your documentation needs?
Coordinator
Oct 16, 2008 at 9:49 PM
Asiemer, that would be great. I will contact you in a moment.
Coordinator
Oct 17, 2008 at 4:05 PM
Edited Oct 17, 2008 at 4:07 PM
Status update:

In progress: Texture2D to polygons

The work on texture to polygon functionality has now begun. sickbattery from this forum is working on it, and we are looking forward to what he might have come up with.

As our goal is to be as cross platform as possible, we will try to get it to work on all platforms.

Edit:
Oh, almost forgot. The documentation is currently being proofread by asiemer Thanks a lot for doing this.
Coordinator
Oct 18, 2008 at 9:25 PM
Status update:

Done:
Texture2D to polygons

Well, it's not exactly Texture2D to polygon, it's uint[] array to polygon :) This way it's a lot more cross platform, but should still be very easy to use. I've been looking at the PhysicsHelper project for a silverlight version of "texture" to polygon code. He has ported Physics2D's polygon code to work on Silverlight UIelements. I will keep it in mind for now.

Thanks to sickbattery for providing this implementation. He has done some great work.
Developer
Oct 18, 2008 at 10:48 PM
Thanks Ian,

I've made a little demo for you guys:
http://sickbattery.name/images/Farseer/quick-and-dirty-p2t-demo.png

This is a standard detail demo (hullTolerance set to 2.0f).
Set the tolerance lower to get more detailed results.
A youtube vid will be up next week ^^ ... showing you which level of
detail you'll need to get the best results.

.. or I'll let the code calculate the complexity of the object and set it
automatically ;D.

Cheers ^^!
Coordinator
Oct 18, 2008 at 11:31 PM
@sickbattery: I've tested it and it works flawless.

Guys, this is really great. A lot of you will get a load of your shoulders with this functionality. Thanks again sickbattery!
Oct 19, 2008 at 9:41 AM
It's so great to see this kind of progress with the Farseer engine. Can't wait til its done.
Developer
Oct 19, 2008 at 11:13 AM
Oh my ... May I add:
I've tested it on my own today. Didn't have any nerve to yesterday.

And I've got to tell you that my old code took minutes(!) to compute very complex 1024² textures (I've a AMD64 X2 6000+ / Only one core is used).
This one gets done eleven in a second oO.

Textures like this one:
http://sickbattery.name/images/Farseer/Texture2Polygon 2008-10-19 13-01-58-18.png

... and I think there is still room for improvements.
Anyway, I'd say it's already usable for realtime calculations with smaller textures.

Isn't that great news for people who wanted to create games with destructable levels ^^ ? It should be possible if you have a texture splitter ...
Oct 19, 2008 at 4:31 PM
Destructable levels, yay!

In Farseer 1.0, i tried implementing a real-time geometry splitter, but came to realize that geometry should not be created at runtime in Farseer, since the "distance tables" takes too long to initialize.

Are we sure these distance tables are the best way to go? It would be great with some fast way to create new collision geometry at runtime.
Coordinator
Oct 19, 2008 at 5:10 PM
@Carlsen: There are other ways of doing narrow phase collision detection, but Farseer selected distance grids. There are both advantages and disadvantages of using distance grids. Other implementations also has just as many plusses and minuses 

We aim for simplicity in Farseer, and it's also a simple implementation. Making it interchangeable with another implementation could be done, but it's in the far future.

There are ways of getting around the distance grid calculation time. If your CPU is heavy loaded with sound, network, AI and other stuff. Putting the physics simulator on another thread is a posibility.

Also chunking up the landscape and using a pool for all the landscape parts will speed things up a lot. All this (and a lot more) is documented in the new manual.
Oct 19, 2008 at 10:12 PM
The new manual! Yes. Is very good!

From: [email removed]
Sent: Sunday, October 19, 2008 10:10 AM
To: [email removed]
Subject: Re: Farseer Physics Engine 2.0 - Progress [FarseerPhysics:36612]

From: genbox

@Carlsen: There are other ways of doing narrow phase collision detection, but Farseer selected distance grids. There are both advantages and disadvantages of using distance grids. Other implementations also has just as many plusses and minuses

We aim for simplicity in Farseer, and it's also a simple implementation. Making it interchangeable with another implementation could be done, but it's in the far future.

There are ways of getting around the distance grid calculation time. If your CPU is heavy loaded with sound, network, AI and other stuff. Putting the physics simulator on another thread is a posibility.

Also chunking up the landscape and using a pool for all the landscape parts will speed things up a lot. All this (and a lot more) is documented in the new manual.
Coordinator
Oct 19, 2008 at 10:34 PM
@asiemer: Haha. Learning anything from the new manual? And what is the status?
Oct 20, 2008 at 12:52 AM
As I knew nothing about your framework to begin with...everything new is well...new! So yes I have learned a lot. I can most certainly see potential in your framework as it pertains to the project I want to start building.
I completed it this weekend. I have to merge my findings into the manual and will send it to you guys shortly.
First I have to play a few rounds of call of duty with my kids!
Andy

From: [email removed]
Sent: Sunday, October 19, 2008 3:34 PM
To: [email removed]
Subject: Re: Farseer Physics Engine 2.0 - Progress [FarseerPhysics:36612]

From: genbox

@asiemer: Haha. Learning anything from the new manual? And what is the status?
Oct 20, 2008 at 3:13 PM
I've been following the progress of this release for just over a week now, and been playing with it since then too. I'm very happy with the power I can get from such simplicity - ie. its really easy to implement things. There are a few things I'd like to make things a little simpler though...

@ genbox: perhaps you could add these to your list or future release plans (if you think its worth the effort)?

1. A PDF version of the documentation? This is as simple as getting the 'Save as PDF' add-in for Word: http://www.microsoft.com/downloads/details.aspx?FamilyId=4D951911-3E7E-4AE6-B059-A2E79ED87041&displaylang=en
2. A way to 'merge' geometry into one polygon. I couldn't find a quick way to do this - and I'm not sure if its needed. At the moment I attach multiple Geoms to a body but I thought I may gain some benefit (performance / simplify things for the colliders) from removing extra vertices created by overlapping geoms. It also makes sense for tile-based levels, where a row of tiles could use 1 geometry instead of each tile having its own, which causes its own problems. I will most likely have to do this for myself anyway, so I'll share my code once its done, if you'd like.
3. I have 'ripped' the PhysicsSimulatorView and its associated drawing objects out of the demos and put it into its own project/assembly (FarseerGames.FarseerPhysics.Debug) for me to use for debugging in my own games. It may be helpful to others to do this?

Anyway, great work and progress so far - keep it up!

Coordinator
Oct 20, 2008 at 3:51 PM
@DrDeth: Thanks for the feedback! We are trying to make Farseer as simple as possible and still keep flexibility. Any new improvements are always welcome.

1. I will release a PDF version of the manual. The HTML version however, will be more "complete". More info on this later in the 2.0 release post.

2. Not too long ago, I posted a way of joining two geometries with a sample. I think it's up to the developer to do such things, but if someone manages to make a simple implementation that works (the one I posted had some issues) I would consider including it. It might be useful to a lot of people.

The post is here: http://www.codeplex.com/FarseerPhysics/Thread/View.aspx?ThreadId=33678

3. Yeah, I've had that in my thoughs too. I've also been thinking about splitting the demo up into 2 parts: basic and implementation. This way all our samples (currently we only have 2 sample projects) could share the same foundation. But as I said before, this would complicate things for those who are new to programming.

In 2.1, we have some plans of making a debug view for Silverlight. If the project gets too big or too complicated, we might split it up into it's own project. But right now it's stays as it is.
Oct 20, 2008 at 6:51 PM
As long as we always update the .docx version of the documentation we can always export to html, pdf, etc. I would suggest having a single source that is "complete" so that each other version is equally complete.
Andy

From: [email removed]
Sent: Monday, October 20, 2008 8:51 AM
To: [email removed]
Subject: Re: Farseer Physics Engine 2.0 - Progress [FarseerPhysics:36612]

From: genbox

@DrDeth: Thanks for the feedback! We are trying to make Farseer as simple as possible and still keep flexibility. Any new improvements are always welcome.

1. I will release a PDF version of the manual. The HTML version however, will be more "complete". More info on this later in the 2.0 release post.

2. Not too long ago, I posted a way of joining two geometries with a sample. I think it's up to the developer to do such things, but if someone manages to make a simple implementation that works (the one I posted had some issues) I would consider including it. It might be useful to a lot of people.

The post is here: http://www.codeplex.com/FarseerPhysics/Thread/View.aspx?ThreadId=33678

3. Yeah, I've had that in my thoughs too. I've also been thinking about splitting the demo up into 2 parts: basic and implementation. This way all our samples (currently we only have 2 sample projects) could share the same foundation. But as I said before, this would complicate things for those who are new to programming.

In 2.1, we have some plans of making a debug view for Silverlight. If the project gets too big or too complicated, we might split it up into it's own project. But right now it's stays as it is.
Coordinator
Oct 20, 2008 at 7:54 PM
Indeed asiemer. We'll keep the docx file and export pdf and filtered HTML from that. Unfurtutnaly it's HTML look like.... filtered hair or something. But it's still only 300kb when exported to HTML.
Developer
Oct 20, 2008 at 9:21 PM
@DrDeth: a function to 'Union' two geometries would be nice but could present some problems.

1. You would have to make sure the geometries are intersecting, otherwise your output would not be correct.
2. If the geometries intersected twice and leave a hole then the output would also fail, whereas two separate geometries would still work perfectly.

So to make what you request would require the function to find how many intersections are between the geometries and then choose the appropriate method, which might not change anything. And the performance gain would be minimal unless you have an ass load of geometries you are combining. I would recommend manually creating your geometries if performance is a huge issue. I will have a tool coming out in a few months for creating complex Farseer shapes that will give you a WYSIWYG output and even real time simulation testing and will output the end result in either C# code or a custom file format or maybe both (TBD).
Coordinator
Oct 26, 2008 at 12:14 AM
Status update:
It's time for another update. I still have some work to do on the manual. I have some new things to write about. Mostly coming from questions previously asked in the discussions. Answering common questions in the manual should lower the amount of duplicates.

It's all going pretty smooth. I don't have a lot of time at the moment, so the little time I have is used on answering questions by email and on the forums. I'll try to speed things up on the manual so we can get it done.

Mattbettcher is still working on his brilliant path generator and chains factory. It's a work in progress, but it should be done before the 2.0 release. He already have considered some improvements. More info on those when we are starting up work on Farseer Physics 2.1.

Matt wanted his implementation to be cross platform, so he build it against the Curve object from XNA and we then added the Curve class to Farseer internals, so that it can be used on all platforms. It's great news for all those Silverlight, Flash, DirectX and OpenGL users out there.

Jeff added a water sample for Silverlight. And as always it's very polished and user friendly. If you wan't a sneak preview of it, you can view it online here: Physics Powered Games Water demo. I'm having lots of fun with it.

The source code of the water sample will be released with Farseer Physics 2.0. Right now it's currently only Silverlight, but it should be easy to implement in XNA (or other platforms). If we get enough requests for a XNA version, we will consider adding one to 2.1.

That's about it. I will write more about the release date and details next week.
Oct 26, 2008 at 12:40 AM
If I could get a water demo for xna I would very much appreciate it! I am trying to land a xna book with one of my publishers and that would really make your engine look above and beyond anything else I have seen. Great job though! Andy

From: [email removed]
Sent: Saturday, October 25, 2008 5:14 PM
To: [email removed]
Subject: Re: Farseer Physics Engine 2.0 - Progress [FarseerPhysics:36612]

From: genbox

Status update:
It's time for another update. I still have some work to do on the manual. I have some new things to write about. Mostly coming from questions previously asked in the discussions. Answering common questions in the manual should lower the amount of duplicates.

It's all going pretty smooth. I don't have a lot of time at the moment, so the little time I have is used on answering questions by email and on the forums. I'll try to speed things up on the manual so we can get it done.

Mattbettcher is still working on his brilliant path generator and chains factory. It's a work in progress, but it should be done before the 2.0 release. He already have considered some improvements. More info on those when we are starting up work on Farseer Physics 2.1.

Matt wanted his implementation to be cross platform, so he build it against the Curve object from XNA and we then added the Curve class to Farseer internals, so that it can be used on all platforms. It's great news for all those Silverlight, Flash, DirectX and OpenGL users out there.

Jeff added a water sample for Silverlight. And as always it's very polished and user friendly. If you wan't a sneak preview of it, you can view it online here: Physics Powered Games Water demo. I'm having lots of fun with it.

The source code of the water sample will be released with Farseer Physics 2.0. Right now it's currently only Silverlight, but it should be easy to implement in XNA (or other platforms). If we get enough requests for a XNA version, we will consider adding one to 2.1.

That's about it. I will write more about the release date and details next week.
Oct 26, 2008 at 1:35 PM
Edited Oct 26, 2008 at 1:56 PM
I just wanted to give an update on the Polygon Union I have talked about previously. I've been doing a lot of research into boolean operations on polygons, but having minimal math skills I haven't had the confidence to tackle doing my own implementation.

I've also played with zanders' PolyUnion function from XNA Wiki (as suggested by genbox). I did manage to get it working, and I've been doing some tests to determine in which situations it works and which not. I'll start a new thread with more detail once I've gathered my thoughts/notes into something cohesive so that others can help to get things working in more cases. I do realise that this doesnt have too much to do with Farseer, but I do think that the prospect of creating complex shapes from simple geometry objects add another 'pro' to the Farseer offering.

Another thought I've had is that Farseer already implements most of the functionality required to perform the polygon unions in the collision detection code, such as edge intersections etc.
Coordinator
Oct 26, 2008 at 1:59 PM
@DrDeth: Sounds great. If you manage to get an easy to use solution that works, I'll be happy to take a look at it. You might want to seek some help on the XNA forums (or another one such as GameDev.net). The original poster of the code might have some improvements for it.
If the solution are to be included into Farseer Physics, we need the following to be true:

1. Be simple. Everyone should be able to use it.
2. It should be able to live inside Vertices and take 2 vertices lists.
3. It need to have some kind of hole detection that removes any holes there might have been created.

That it, looking forward to see what you have come up with.
Oct 26, 2008 at 3:33 PM
@genbox: Currently I have an implementation that works - except in specific situations. I shall attempt to contact the original author to ascertain if there are any improvements.

1. This seems simple enough to me:
      Vertices v = square1.Union(square2);  // where square1 and square2 are Vertices.

2. Currently I've implemented the Union and Intersect methods as Extension Methods to the Vertices class. It should be simple enough to add.
3. The XNA Wiki page states that holes are 'ignored' but, from my tests, this does not seem to be the case currently.

I've submitted the code as it currently stands as a 'patch', though clearly there are some issues that need to be sorted out before it is ready to be included.
Oct 26, 2008 at 4:42 PM
Would you not want to have an overload to keep holes?
Vertices v = square1.Union(square2);
&
Vertices v = square1.Union(square2, false); // where false turns off the default for removing holes?
Why would you want to remove holes by default? Perhaps I am missing something?

From: [email removed]
Sent: Sunday, October 26, 2008 8:33 AM
To: [email removed]
Subject: Re: Farseer Physics Engine 2.0 - Progress [FarseerPhysics:36612]

From: DrDeth

@genbox: Currently I have an implementation that works - except in specific situations. I shall attempt to contact the original author to ascertain if there are any improvements.

1. This seems simple enough to me:
Vertices v = square1.Union(square2); // where square1 and square2 are Vertices.

2. Currently I've implemented the Union and Intersect methods as Extension Methods to the Vertices class. It should be simple enough to add.
3. The XNA Wiki page states that holes are 'ignored' but, from my tests, this does not seem to be the case currently.

I've submitted the code as it currently stands as a 'patch', though clearly there are some issues that need to be sorted out before it is ready to be included.
Coordinator
Oct 26, 2008 at 5:24 PM
@DrDeth: Yes, It seems simple enough now, but the code from the wiki page is not quite ready.

What would happen if I was to define 2 squares that are not touching each other? What would happen if they are perfectly overlaying each other? What would happen if only one vector of each vertices list, are touching each other?

All those scenarios needs to be covered and checked for/worked around. The users should get a consistent result that is the only logical outcome.
The API presented in the code, seems simple enough, but presenting a solution that covers the scenarios from before, might be more advanced.

And as for the holes. It's really hard to get a perfect algorithm that provides the expected result for all possible input. If you put a small circle on top of a larger rectangle, the union should not create a hole. This is very important.

@asiemer: Farseer works with convex and concave polygons. We can't have holes inside a polygon, it would just not make sense, as there is nothing that could collide with the hole. There are some scenarios where you need a "hole". An example would be an areana (a ring), to create a ring in Farseer, you need to make it from 2 or more arches.
Oct 26, 2008 at 9:44 PM
What about merging the shapes to have a mask (similar to a flash) where it looks like you can see though it...but it is actually there? Just a thought.
Andy

From: [email removed]
Sent: Sunday, October 26, 2008 10:24 AM
To: [email removed]
Subject: Re: Farseer Physics Engine 2.0 - Progress [FarseerPhysics:36612]

From: genbox

@DrDeth: Yes, It seems simple enough now, but the code from the wiki page is not quite ready.

What would happen if I was to define 2 squares that are not touching each other? What would happen if they are perfectly overlaying each other? What would happen if only one vector of each vertices list, are touching each other?

All those scenarios needs to be covered and checked for/worked around. The users should get a consistent result that is the only logical outcome.
The API presented in the code, seems simple enough, but presenting a solution that covers the scenarios from before, might be more advanced.

And as for the holes. It's really hard to get a perfect algorithm that provides the expected result for all possible input. If you put a small circle on top of a larger rectangle, the union should not create a hole. This is very important.

@asiemer: Farseer works with convex and concave polygons. We can't have holes inside a polygon, it would just not make sense, as there is nothing that could collide with the hole. There are some scenarios where you need a "hole". An example would be an areana (a ring), to create a ring in Farseer, you need to make it from 2 or more arches.
Developer
Oct 26, 2008 at 10:09 PM
@genbox - you are exactly right. There are a ton a crazy variables that could happen in a Union method. 

I think with the deadline for 2.0 final release coming up very soon we should add this to 2.1's list. 

@DrDeth - not saying to quit working on it just letting you know it might get pushed back to 2.1 unless it's very solid by say the end of the week ;)

@asiemer - from your latest post I'm not quite sure what you mean.

TO ALL - I would suggest we move this to it's own thread.
Coordinator
Oct 26, 2008 at 11:52 PM
Quick status update:
Mattbettcher has done an incredible job on the path generator / chain factory. We just need some polishing and extensibility on it and then it should be ready for 2.0. We are also trying to show the true powers of the path generator in a sample. For more details, you will have to wait until we release 2.0 ;)

We are now at our 1000 download of Farseer Physics 2.0 Alpha. That's great considering it's an alpha.
Oct 27, 2008 at 9:07 AM
@DrDeth: Yes, It seems simple enough now, but the code from the wiki page is not quite ready.
I agree - its far from complete. I've started a new thread to start listing the various scenarios for improvement, and so that we stop contaminating the progress updates. :)
Coordinator
Oct 29, 2008 at 12:05 AM
Announcement soon!
Tomorrow I'm going to write info about the Farseer Physics Engine 2.0 release. I'm also going to tell you when we expect to release 2.0. (Hint: Very soon).
I will cover some of the new functionality, show you some screenshots and maybe give you some info about the future of Farseer Physics Engine (2.1 and other future releases).

Stay tuned. ;)
Coordinator
Nov 2, 2008 at 9:49 PM

Status update:

  • Done: Increase performance/reduce memory footprint
  • Almost Done: Rope/chain factory
  • Almost Done: Path generator
  • Done: Write more documentation

    As you can see, we are very near our release. Only the path generator needs it's last touchups.
    The documentation came out very nice. I'm sure it will be a help to a lot of people. There might still be some areas that are missing, but I think that Farseer Physics have the most complete documentation I've ever seen for a physics engine. ;)

    I've tried to increase the performance and reduce the memory footprint. Crashlander did a very good job on optimizing Farseer Physics for performance. I've only managed to find small micro optimizations. Even the factories are lazy loaded, so they are not loaded unless you use them.

    Anyways, I ran a performance test on 1.0.0.5 and on 2.0. Even though we added a lot of features, they are equal in in terms of performance. Memory usage are larger in 2.0 depending on how many features you use. This can't be avoided ;)

  • Developer
    Nov 4, 2008 at 7:57 AM
    Edited Nov 4, 2008 at 9:32 AM
    I have a question about the path generator :).

    Are the objects - that move along the curve - moved by impulses and/or forces or do you set the position "manually"?

    edit:
    I thought about creating a path generator, too. A long time ago ... but the movement of the objects looks fake. Wouldn't it be better to give an object a destination point and move it by forces to that point? You could then create a list of destinations and ... ... you know? Just a thought ^^ ...
    Coordinator
    Nov 4, 2008 at 9:00 AM
    @sickbattery:

    Well, it's really up to you as the game developer to figure out how you move your objects. But using the physics system to move things, are the preferred way.
    In the new Path Generator demo from Advanced Samples uses the friction from the circles (wheels) to make the track move.

    The Path Generator itself does not move anything or have any mechanism for moving. You could create a rope bridge or a conveyor belt with the Path Generator. Making the conveyor belt move would require you to make some driving mechanism that makes the Path go around. 
    Developer
    Nov 4, 2008 at 10:46 AM
    Oh. Ok. I've downloaded the latest version and looked into the code and documantation. Now I know the features a very new but ...

    To understand the PathGenerator I had to look into the code. The documentation didn't help. The doc sounds like a short overview here. The first thing mentioned is that the PathGenerator can be used for "Creating tank tracks", well fine, but ... how? Which functions will help me? FindMidpoint and FindEdgeNormal should be at least mentioned.

    I would like to rewrite the polygon from texture part. May I? :). It's the universal documentation as far as I can see and it doesn't explain uint[] for example; which bits in the unsigned 32-bit integer are used for alpha (for edge finding). The documentation should hold informations like that - at least in my opinion oO.

    I haven't read all the other stuff in the doc (Farseer Physics Engine 2.0 Manual.docx), but the stuff I just read is way to meager. As said I know the features are very new, but then again the doc shouldn't be set to "done" yet oO.

    No offence guys ;).
    Coordinator
    Nov 4, 2008 at 10:55 AM

    Thanks for your feedback sickbattery.

    You are right about the Path Generator documentation. This functionality is very new and made it into the engine very late in our development cycle. I will write it down and create more documentation later.

    You are welcome to rewrite the texture to polygon feature. As long as it get's better quality and not worse ;) (Not that its bad quality now. it's great)
    Your notes on the uint array have been noted.

    The manual is directed as people new to Farseer. We can't overload them with information and implementation details :)
    I think the manual is very extensive in some areas (Collision detection system and the like). Some parts need more information, but then again, we need to keep it as simple and precise as possible for new users.

    If you have more constructive criticism, you are welcome to contact me or write on the forums.

    Developer
    Nov 4, 2008 at 11:28 AM
    Yes. Simple is great, but here I have to analyze the engine's code and that's not simple. I will rewrite the polygon part.

    My LOD aim:
    - Overview of the functionality.
    - Explanation of the public functions and their parameters.
    - Examples and further explanations.
    - As short as possible.

    (That's also what I'm expecting of a documentation oO.)

    Agreed :) ?
    Coordinator
    Nov 4, 2008 at 11:32 AM
    Are the path generator and texture to polygon sections the only ones you are missing examples from?
    As I wrote in the 2.0 Release post, I have just noticed that it's an old version of the manual lying in the source control (and online). I will upload a new one when I come home.
    Developer
    Nov 4, 2008 at 12:29 PM
    I don't miss examples. I miss the documentation on these components. There is just a short overview; what they are good for and in Polygon From Texture an example for XNA only.

    The Polygon From Texture part has an example but doesn't explaint the 32Bit integer and that's important. Well, shame on me I myself didn't add enough info in the code ^^ ... "Creates a list of vertices from unsigned integer (32-Bit; 8 bit for each color) array." I should say which bits are for alpha ^^ ...

    Ok, I'll wait for that. I'm at work, too.
    Developer
    Nov 4, 2008 at 3:14 PM
    I've seen the Online Docs now and read a little bit more. It's very nice and the Silverlight examples are great :). I'm just talking about the docs of the new features and I hope everyone got that right. I post to ensure ...
    Nov 4, 2008 at 6:10 PM
    I would agree that the docs were severely lacking in good demo code. But perhaps that is the purpose of the demos? So..is there/ can we get a good demo of a bridge, a track, the path generator, etc.?
    Andy

    From: [email removed]
    Sent: Tuesday, November 04, 2008 3:46 AM
    To: [email removed]
    Subject: Re: Farseer Physics Engine 2.0 - Progress [FarseerPhysics:36612]

    From: sickbattery

    Oh. Ok. I've downloaded the latest version and looked into the code and documantation. Now I know the features a very new but ...

    To understand the PathGenerator I had to look into the code. The documentation didn't help. The doc sounds like a short overview here. The first thing mentioned is that the PathGenerator can be used for "Creating tank tracks", well fine, but ... how? Which functions will help me? FindMidpoint and FindEdgeNormal should be at least mentioned.

    I would like to rewrite the polygon from texture part. May I? :). It's the universal documentation as far as I can see and it doesn't explain uint[] for example; which bits in the unsigned 32-bit integer are used for alpha (for edge finding). The documentation should hold informations like that - at least in my opinion oO.

    I haven't read all the other stuff in the doc (Farseer Physics Engine 2.0 Manual.docx), but the stuff I just read is way to meager. As said I know the features are very new, but then again the doc shouldn't be set to "done" yet oO.

    No offence guys ;).
    Nov 4, 2008 at 6:12 PM
    Is it possible to use something like SandCastle to generate some docs that would give better insight into how the code works?

    From: [email removed]
    Sent: Tuesday, November 04, 2008 5:29 AM
    To: [email removed]
    Subject: Re: Farseer Physics Engine 2.0 - Progress [FarseerPhysics:36612]

    From: sickbattery

    I don't miss examples. I miss the documentation on these components. There is just a short overview; what they are good for and in Polygon From Texture an example for XNA only.

    The Polygon From Texture part has an example but doesn't explaint the 32Bit integer and that's important. Well, shame on me I myself didn't add enough info in the code ^^ ... "Creates a list of vertices from unsigned integer (32-Bit; 8 bit for each color) array." I should say which bits are for alpha ^^ ...

    Ok, I'll wait for that. I'm at work, too.
    Developer
    Nov 4, 2008 at 6:54 PM
    I guess I will write additional docs on the Path generator stuff when I get a chance. That stuff is meant for advanced users that can just go into the demo code and quickly gain the basic concept of how it works. I do apologize for not documenting it as thoroughly as I hoped to but I have been having to write a ton of papers lately for school.
    The private functions FindMidPoint and FindEdgeNormal are only included because I didn't want to create a whole Vertices list. Both those functions exist in the Vertice class and the ones I am using are only slighty different. I suggest sticking with the Vertice class.

    The Path generator lets you create a path on which to place bodies. You define a set of Vectors describing the path. Then it can place body's on that path for you. Path doesn't move body's on a curve. The guts on the path class are quite complicated and I would love to explain it but I just don't have time right now. Besides that when Farseer 2.1 is released a much better and robust Path class will be waiting.

    Honestly it's still in the early stages as I didn't get enough time to finish it fully. We decided to include it in this release as a teaser to what will hopefully be included in 2.1.
    Developer
    Nov 4, 2008 at 7:05 PM
    I feel bad I didn't get time to fully document the Path class or ComplexFactory (as basically everything in there is mine). In the future I will release a separate demo and documentation for each item I complete. After it is critiqued we (Me, Ian, and maybe Jeff, he's busy like me ;) will decide when to officially add it to the engine or not. I will continue to add and modify directly to the source code tree for those that are ready to use my code. Just check the comments in the source control and decide if your ready to try it out.

    As a side note I will not have time to write any documentation until 10-11-08 at the earliest. Honestly I don't have time to be posting in here this week.
    Coordinator
    Nov 4, 2008 at 7:20 PM
    @asiemer: We have created an Advanced Samples package that demonstrates the use of path generator. Demo 5 shows off 4 different types of chains/rope using the path generator. Demo 6 shows off how to use the path generator to generate tracks for a tank using a bunch of control points.

    As for the Sandcastle documentation, while it's nice to have when you develop in an editor without intellisense, I don't think I would be nessecary to create such a documentation when we do have stuff like Intellisense. Sandcastle only documents what is written in the code. I have made the comments in code sandcastle compatible by using references and the like, but right now we focus on functionality and improvements.

    Thanks for the suggestion though.
    Developer
    Nov 4, 2008 at 8:08 PM
    Hey mattbettcher, didn't want to make you feel bad oO. I guess I just didn't understand the PathGenerator right (all I knew at my first post was the name and some infos that were posted here). Isn't the name a little bit confusing? Well, maybe just for me because I'm to dull to understand path as a line that will be transformed into a chain and not as a path you walk and move along. That's why I suggested that the documentation should tell the user something about FindMidPoint and FindEdgeNormal. I thought it was a path you can move the objects along and the two functions would give you the position on the line.

    So the word "path" was a little bit confusing to me and I didn't see anywhere this functionality that I thought of and of course big-mouth sickbattery had to post. Sorry. Sometimes I shoot the guy before asking the questions :/ ...
    Nov 4, 2008 at 8:37 PM
    Wow! Great job on the documentation, it's pretty comprehensive! Keep it up!
    Coordinator
    Nov 4, 2008 at 9:08 PM
    @sickbattery: Indeed. We will try to clarify the functionality more.
    We had some trouble naming the thing. I guess that Matt described it as a path generator and I just picked up the name :) Never got around finding a proper name for it. I suggested linkedbodies, but it's much more than that.

    @AlexO: Thanks a lot for your feedback. Happy to hear you like it.
    Developer
    Nov 5, 2008 at 6:03 PM
    Hey guys,

    I think I'll have some spare time this weekend. So, I think I'll code a little bit for farseer (if you want to have this feature) ... I have a "level" collision generator (called BigTexture2D; yeah it's more then just a collision generator :P ...) and I want to develop it a bit further. You know, I could use it just for myself but: Why? If I don't get my game done (I will!) then maybe someone else will be happy to find that function in farseer ^^.

    I would like to add a new function to the ComplexFactory and I would call it CreateLevel (or CreateStaticBodies?) and you would have to put in either a uint[] or a list of uint[]s into it. How about that? (damn my beer is empty; nooooo ... why? god *cry ...)

    It would create a list of static bodies (maybe automatically added to the PhysicsSimulator?).

    Of course you might think that this isn't realy complicated ^^ ... but in fact it is a little bit: If you splitt your level texture then you'll probably get out textures which consist of multiple parts (even more if you don't splitt, duh!) and that's something that the Vertices.CreatePolygon function doesn't support. So, Vertices.cs would get a new funcion ...

    For 2.1 with documentation oO? genbox?
    Coordinator
    Nov 8, 2008 at 11:09 PM
    @sickbattery: Can you describe a little more what this CreateLevel functionality would do?

    Are you thinking about one texture that consists of multiple graphics - that would be cut out and each of them made into a body?
    Developer
    Dec 16, 2008 at 2:49 PM
    Edited Dec 16, 2008 at 3:08 PM
    My job is stressing me out. Sorry for the long pause ...

    The short answer to your second question is: Yes.

    ...but:
    I've some new ideas for the "CreateLevel" function and ... it could get really intresting. I just thought about it again (on paper, for quite some hours now) ...

    I think "CreateStaticSurface" sounds better then "CreateLevel". StaticSurface would take care of all the needed geoms and CreatePolygon would be extended. The only problem is that the user might set a static geom from the surface to not static and destroy the surface ... I'd have to label the geom somehow (Geom.Tag?). As I said, I've thought about it for some hous and I've developed a way to detect holes and separations in textures. Of course this will take more cpu, but that's not avoidable.

    Basically the user would call a function like this:
    StaticSurface CreateStaticSurface(ref List<uint[]> textureBitsList, int textureWidth, int textureHeight, int surfaceWidth, int surfaceHeight, byte alphaTolerance, float hullTolerance)

    textureBitsList could contain sixteen 256x256px texture uint[]s to create a surface with a size of 4096x4096px - for example.

    Ok. That's nice but I want to have destructable levels :).

    CreateStaticSurface returned a StaticSurface with which the user will be able to set new data from a single texture:
    bool StaticSurface.SetFragment(int index, ref uint[])

    Changes will have to be applied with:
    void StaticSurface.Update()
    void StaticSurface.Update(float detail)
    void StaticSurface.Update(float detail, rect surfaceArea)

    You might ask yourself why I don't update the geoms after the data was set. Well, imagine an explosion destroys the surface on more then just one fragment and the damage is very small. With this you can update that small area without updating the two damaged fragments. If you have multiple explosions and the damage isn't shared by the fragments, then set the new data and call update with the coords of the damaged area in surface coordinates.

    I think I have a good solution for a fast check for changes, that's why there is also a float detail parameter.

    Ok ... my eyes burn -.- ... and I'm tired.
    I have thought about this too much :).

    Oh and if this is a too complex feature then you'll sure tell me.
    I know what I wrote in the "Farseer Physics Engine 2.1" thread :) ...
    Developer
    Dec 16, 2008 at 3:13 PM
    Edited Dec 16, 2008 at 3:19 PM
    Maybe this would be better:
    bool StaticSurface.SetFragment(ref uint[], rect surfaceArea)

    I'll think about it later :) ... ...

    Edit:
    ... I don't want to store the whole uint[]. I'll convert it to bool[].
    Dec 16, 2008 at 3:20 PM
    @sickbattery:
    It sounds like you would recreate all the level geometry with every explosion? Thats not a very good idea IMO.
    I would, and this is just my opinion, only use the 'CreateStaticSurface' function once to create the initial geometries. Then, when explosions (or anything that changes the level structure) happen, I'd do [much faster] polygon boolean operations on the affected geometries.
    Drawing, in my mind, would be achieved by an intelligent 'polyogn shape filling' shader.



    Developer
    Dec 17, 2008 at 8:48 AM
    "It sounds like you would recreate all the level geometry with every explosion? Thats not a very good idea IMO."
    Nope.

    Update(float detail, rect surfaceArea) would get the surface area specified in the rect parameter and update only the polygons in that area. That means: I'd look for polygons in this area and call a function like ContinuePolygon() and generate only that part with CreatePolygon()-like code.

    I've seen your thread but I didn't come to test the demo. Sounds very intresting :) ...
    I guess I'll have to take a look. It might save me a lot of time and it sure will make it less complicated to update the surface.

    Let's move to:
    Farseer Physics Engine 2.1