Community requests - Farseer Physics 2.0

Coordinator
Aug 31, 2008 at 8:41 PM
Edited Sep 28, 2008 at 1:50 PM
Hi all.

As you might know, we are working on Farseer Physics 2.0. This is the perfect oppertunity to get some of your requests into the engine.

If you have any requests for new features or some old code that you have developed for your game, that you would like to get into the new engine, then now is the time to dust it off and send it to us.

Any ideas you might have. Including but not limited to: Features, bugfixes, demos or documentation. Come forward and tell us what you think.

Update: This is what you have suggested so far:

  • Increase performance/reduce memory footprint
  • Rope/chain factory using path generator
  • Texture2D to polygons
  • Multithreading, object cache and resting bodies samples
  • Broadphase collision event
  • Unified debug view for most platforms
  • Write more documentation
  • Bodies seperation event
  • Extension to factories for setting bounciness
  • Sensors (Collision response, no impulses)

This list is still subject to change. If I missed one, please tell me :)
I would like to thank everyone for the suggestions!

Sep 1, 2008 at 12:03 AM
Anything you can do to increase performance (or reduce memory footprint) would be great.

If the engine still uses Collections (or otherwise creates/destroys objects constantly), perhaps we could use some kind of object pooling instead?
Developer
Sep 1, 2008 at 1:57 AM
Well I am working on a particle engine. Hopefully it will be done for release with Farseer 2.0.

I'm also gonna be working on some constructors for complex objects i.e.- chain, rope, fake soft bodies, and a path generator.

Chain - should be able to create chain like assemblies in one function call.

Rope - just like the chain but rendered as a path.

Soft Bodies - just some fake soft body stuff using springs, maybe soft circle, soft rectangle, and soft polygon.

Path Generator - just some utilities to create multiple bodies along a path linked with joints or not.
Coordinator
Sep 1, 2008 at 1:03 PM
@thatoneguy - I will take a look at it. Our aim is to provide the community with a simple physics engine. Alot of the changes that can be made to make the engine faster is rather complex and most of them belongs in the implementation of the game, not the engine. I could perhaps create some demo prototypes that use some of the performance enchancements, such as multithreading, local collision response (deactivate bodies far away) and object pools/cache

@mattbettcher - I look forward to anything you might have :) The suggestions you made with creating rope and the like sounds like a good idea. We could perhaps make some helper classes for creating complex elements such as ropes, chains and other mechanics. If you have a prototype of the ideas, I would be happy to take a look at it.
Developer
Sep 1, 2008 at 2:35 PM
I could provide some Texture2D to Plygon code.
You could put that into the XNA builds?

Yeah, that shouldn't be a part of the engine but somehow it's a missing component - and a pain in the ass to write ^^ ...

Well, I've seen now that my Texture to Polygon functions have to be rewritten and extended (performance, data compression, multiple parts, holes in textures, etc).
So it would take some time ... I'd have to play less Guitar Hero 3 and I don't know if I can make it oO. *joking

... but I'll give it a try ;D.
(If you want to have it?)
Coordinator
Sep 1, 2008 at 2:44 PM
The code is XNA specific. If we implement something, we want it to be on all platforms. BUT it is very nice to have, so it could make it into a XNA demo perhaps.

It's hard to make a texture mapper that works on all platforms. It's also very tricky to make a good automatic texture mapper.This reminds me that I'll have to post about a polygon mapper and some demos I made some time ago. I will get back to you when I have posted about it. (You will see why then)
Sep 1, 2008 at 6:22 PM
Edited Sep 1, 2008 at 6:25 PM
I could really use onCollisionEnded event. Fired after collision has ended(or while before, doesn't matter). I've posted about it in other topic, but no solution. This event is the most elegent solution I can think of.

BTW. FluidController is working? If not, I would love to see fluids in new release.
Sep 1, 2008 at 6:54 PM
"I could perhaps create some demo prototypes that use some of the performance enchancements, such as multithreading, local collision response (deactivate bodies far away) and object pools/cache"

This would be fantastic, because from what I gather, having the physics run on a separate thread offers a great performance boost.  I haven't yet figured out the best way to implement this, myself...

Unrelated question:  Is Farseer physics deterministic?  I guess it may help network synchronization a little bit, but mainly it allows for game recording/playback.  This isn't a feature request, I'm just wondering if this is the case.
Coordinator
Sep 1, 2008 at 7:57 PM
@garus - I have not tried it, but I think that detecting when a collision stops can be very tricky and possibly inaccurate. I think that the best way of doing this would be to mark a geom as "not collided" and then mark it as "collided when the collision event is fired. Then after some time (0.5 seconds or 5 physics engine updates) it would mark the geom as "not collided again". I will think a little about it. - This discussion should continue in the discussion you created. :)

@thatoneguy - There are many ways to implement multithreading. I have my mind on 2 things. The first one is putting the physics engine on a thread for it self and then marshaling over the position and rotation to the drawing elements. The second one is a surprise... ;) I will return with more into on the second one as soon as I have created a prototype.

To anwser your unrelation question: This might answer it.

@All - If you have any examples of multithreading, local collision response (deactivate bodies far away) and object pools/cache. You are welcome to send it to my email. (Use codeplex contact form at first ). I would appriciate any help. Your name will of course be in the code and documentation.
Sep 1, 2008 at 8:01 PM
Edited Sep 1, 2008 at 8:02 PM
@genbox  - I finally solved it so no need for this event anymore. I just check manually (I took intersection code from BruteForceCollider) if it's still colliding ;)

PS. Maybe I will release movie clip with my 'game'(not much of a game right now, but it's closely related to physics ;p)
Coordinator
Sep 1, 2008 at 9:20 PM
@garus - Very nice. I would like to see what you have come up with. We are always happy to see what Farseer Physics is being used for. :)
Sep 1, 2008 at 11:09 PM
How about a compact version for the zune with just circles, rectangles, polygons, and maybe some springs. The collision would still be there.  But in the end a trimmed down compact version.
Developer
Sep 1, 2008 at 11:43 PM
@genbox - when you say "put the physics engine on a thread by itself and then marshaling over the position and rotation" that would be deferred  rendering, right? Physics engine is always one frame ahead of the rendering engine?

I feel the simplest method for multithreading should be used even if it doesn't offer the greatest performance gains. And it should be really simple to use, as per Farseer's style. Maybe simply passing a boolean to the PhysicsSimulation at creation then in the rendering loop you wait for a physicsEngineDone flag and then render the list. Maybe I'm silly I haven't done any multithreading in C# only OpenMP in C++. Anyway I do think it should be kept simple.

I'll get working on some helper classes and send then to you genbox.
Developer
Sep 2, 2008 at 12:40 AM
Just thought of a good idea.I know this won't help us pros ;) but how about a good template complete with drawing system ready to go so new people can just test the engine out without writing so much code to draw stuff.
Sep 2, 2008 at 6:19 AM
Edited Sep 2, 2008 at 6:21 AM
I suggested this a long time ago, but I don't believe it ever made it in.  It would be nice to have a delegate to check to see if collision is possible while in the broadphase.  Sometimes the collision categories simply aren't enough, and there's no need to waste time doing a check and finding contact points in the narrowphase.  This is something I've found myself implementing each time I downloaded the engine.

Similar to Matt's last suggestion, as a side project, it would be nice to see a PhysicsSimulatorView that can easily be plugged into any application. (DirectX, XNA, WPF, and GDI+ versions?) Include a Matrix property to let the developer position, rotate, and rescale the view.  Make sure the physics engine itself is capable of relaying enough information to this seperate component to do its job.
Coordinator
Sep 2, 2008 at 3:43 PM
@SomethingNew - Farseer is very simple and does by default not contain any drawing specific code. So the engine will be very lightweight for Zune. If mean the samples that would be provided with Farseer for Zune, then they will be as lightweight as possible too. We always strive to be as simple as possible. When we get the Zune version in place I will take a look at it and see if I can make it lightweight.

@Mattbettcher - "that would be deferred  rendering, right?"
The physics engine gets updated before drawing, yes.

"Maybe simply passing a boolean to the PhysicsSimulation at creation then in the rendering loop you wait for a physicsEngineDone flag and then render the list."
It's not the plan to put it into the engine permanently. Not unless it's VERY simple and works flawless on all platforms. :)
There should not by to many problems with the syncronisation. But yeah, a fix to overcome syncronisation problems would be to wait until the physics is updated. This will be aparent in the testing of the prototype.

"I'll get working on some helper classes and send then to you genbox."
Very nice. I'm always happy to recive work as our workforce is very small and we don't have a lot of time :) Thanks.

"how about a good template complete with drawing system ready to go so new people can just test the engine out without writing so much code to draw stuff."
Good idea. But I think that it should be implemented in a sample that demostrates the use of a template engine. It should be like a plug and play system :)

@Yota - "It would be nice to have a delegate to check to see if collision is possible while in the broadphase."
Can you send me the code and tell me where to look? :) I don't think it would harm anything to have a small delegate. I will take a look at it.

"PhysicsSimulatorView that can easily be plugged into any application. (DirectX, XNA, WPF, and GDI+ versions?) Include a Matrix property to let the developer position, rotate, and rescale the view."
I had this in mind some time ago when I needed the PhysicsSimulatorView for a WPF application. I think I released the source here on the forums. (It might not be up anymore). I will take a look at it.

@All - Thanks for all your suggestions so far. I really appreciate it.
Developer
Sep 2, 2008 at 8:32 PM
@genbox - I'd just really like to have a simple multithreading setup. Maybe we should branch the engine into a multithread and non-multithread (I'd rather not though). All the samples I've seen on here are quite complex, I always shoot for code that is really easy to use.

As for the PhysicsSimulatorView really all that needs to be done is to encapsulate it in its own library and then add the nessessary #ifdefs to allow for drawing on all the different platforms. So my question to everyone is if I was to get the XNA version polished up and working great and add all the #ifdefs would someone else be willing to finish off the WPF, and GDI+ versions? Also do we need a DirectX version? I was under the immpression XNA replaced Managed DirectX and Managed DirectX was obsolete? Anyway I would be sure to add all the matrix stuff so any camera action you have going on will work. I also plan on adding an optional GUI system to control the drawing flags and the performance panel.

As for helper classes I'm almost done with the chain helper. Would you like me to just send you a demo and then you can decide how to insert it into the engine? I'm shooting for platform independent code in a single function, with multiple overloads for the various features. Also stuff like the rope and fake soft bodies will come with rendering examples. And I should hopefully have some code for you by the end of the week, at least a demo of where I am.
Coordinator
Sep 2, 2008 at 9:21 PM
Edited Sep 2, 2008 at 9:45 PM
@mattbettcher - "I'd just really like to have a simple multithreading setup"
So do I.. but it might not be possible. A solution made on the Windows platform might not work on the Silverlight platform. I have been talking to Crashlander about making a seperate branch that includes multithreading. But we don't want to confuse the users by releasing to many versions. Most users don't even know what multithreading is.

"As for the PhysicsSimulatorView really all that needs to be done is to encapsulate it in its own library and then add the nessessary #ifdefs to allow for drawing on all the different platforms"
It might not be that simple. WPF for one does not work in the same way as XNA or GDI+ when drawing to the screen. It has shapes that are added to the canvas only once. Then you will need to manage a reference to the shape and update it's position on every update. This way of controlling shapes is very slow and performance is only about half compared to XNA. Adding and removing bodies from the physicsengine also poses a problem. I requested a long time back that some events were added to Farseer (BodyAdded/Removed and so on) to fix this problem.
I still have a working version of the WPF debug view. Just checked.

"Also do we need a DirectX version? I was under the immpression XNA replaced Managed DirectX and Managed DirectX was obsolete?"
The mostly used platform in the gaming world is DirectX followed by OpenGL. MDX (Managed DirectX) used to be a wrapper in .net for the native DirectX libraries but became obsolete when XNA was released. XNA does not have the concept of surfaces as MDX and DirectX has. This makes the development on the platform easier.

By the way. We could create an abstract system that defines the structure a debugview need to have. (using interfaces). This way a solution could be coded against the interface instead of the implementation of Farseer. We don't have to use #if directives then (I don't like them :) They clutter code and should not be used for whole component implementations. Well defined structures should be used instead.) and should a new platform become avaliable (such as zune just did) then we already have the structure defined and little work is needed to make it work. The end of the week sounds great to me.

"As for helper classes I'm almost done with the chain helper. Would you like me to just send you a demo and then you can decide how to insert it into the engine?"
Very nice. I really look forward to have a look at what you have. I would like to see it all as a whole, so when you are done with most of the coding, I would like to see what you have come up with. 

I thank you for your hard work and interest in Farseer.
Developer
Sep 3, 2008 at 2:00 AM
@genbox - Sorry for my complete lack of knowledge on C# stuff. The only thing I've ever used with it is XNA. I do agree on the interface for the PhysicsSimulatorView but I'm not sure how to write an interface, guess I'll have to do a little research.

So you can use Unsafe DirectX in C#?  I do know how to program using DirectX and OpenGL, I just thought the goal was to keep everything managed so it will work on as many platforms as possible. Also what was the last version of MDX to be released?

If WPF is so slow (I've never used it), then why bother implementing it? What advantages does it offer?

If you could send me some ideas on how to start to approch the interface for the PhysicsSimulatorView I'd really appreciate it. My original goals were a very simple GUI box and performance panel along with all the drawing code. If we figure out how to layout a good interface I can write the code for the XNA version.

On multithreading, I do agree on how complex it can become. I wish we had OpenMP in C# :( anyway good luck on it I'm gonna try an use it no matter how complicated it gets cause my game is gonna need it bad ;)
Coordinator
Sep 3, 2008 at 1:42 PM
@mattbettcher - Don't be sorry. You gave a good idea. That's all that matters. :)

Yes, you can use unsafe DirectX in C#, but most developers would choose managed C++ instead of C# in professional games. Not because C# is a bad and C++ is better, but because that's what the industri knows and have experience with.

You might already have MDX installed. I have MDX installed with my DirectX 9/10 installation from the web installer. The last version to be release was MDX 2.0 before XNA took over.

I'm n o expert in WPF and I might have taken a less of ideal way of implementing it. The debug view for WPF is still usable in terms of performance. But if you have 50 shapes in the screen colliding, then you will be in trouble.

I have too much to do right now. But I will put the interface into my todo list.

About the multithreading, I'm going to take a look at it today when I'm done with the cleaned demos. My supprise will also be revealed soon ;)
Sep 4, 2008 at 6:03 PM
Edited Sep 4, 2008 at 6:21 PM

@genbox:
"Can you send me the code and tell me where to look? :) I don't think it would harm anything to have a small delegate. I will take a look at it."
I can't access it at the moment, but it was really simple.  Add a delegate to Geom that takes another Geom as a parameter and returns a boolean.  Then in the broadphase classes when it is iterating through geoms in the simulation, make a check like..
if(!(geom1.BroadphaseCollided == null || geom1.BroadphaseCollided(geom2)) || !(geom2.BroadphaseCollided == null || geom2.BroadphaseCollided(geom1))) continue // or return

Since it checks with both Geoms to see if it collides (both must return true for a collision), that delegate would be called at very high frequency.  With the BruteForceCollider, it has a best case of O(n) and worst of O(n^2).  The further back you place the code in the DoCollision loop, the less this delegate is called.  The sooner it is called, the less the broadphase collider will need to work.  Where you put it depends on how you think it will be used, I guess.

Edit: Actually, you could just make it check only with the first geom.  The developers can then make it check with the second geom from within their delegate methods if it is necessary to do so.

When I used it, it was for a ragdoll character I made, and just checks to make sure the body components don't collide with each other.  Low cost.  This couldn't be done with collision groups, since each ragdoll would require its own collision group.


As for the DebugView, I had some ideas.  The external library suggestion is most practical and probably the most efficient.  However, it's a little less extendable.  If someone were to deploy a new type of controller, they would need to make code for both libraries.  An alternative would be to have drawing classes for each type of object built in to the physics library.  These classes would be referenced be the controllers through metadata so they don't add needless bloat and memory usage to the controller classes themselves. (Could define a flag on the controller to determine if only one instance of the drawing class needs to be instantiated for each type of controller, or one for every instance of a controller.) Users could then deploy their new controllers as assemblies.  The negative side to this approach is figuring out how to get it to work with the different platforms. (XNA, GDI, etc)  There are options for this as well, like setting up a basic framework for drawing, and having pluggable classes to render what the drawing classes request.  I really don't want to get into this too much though.  This thread is for the physics engine itself, and I don't want to start another tangent, so let's shelf this.

By the way.  When I made that list earlier ("DirectX, XNA, WPF, and GDI+ versions?") I was thinking that 'WPF' would cover both WPF forms and Silverlight.  I forgot that Silverlight uses another type of .Net Framework.  An implementation in the .Net core framework for Silverlight would probably be higher priority than regular WPF.
Coordinator
Sep 4, 2008 at 8:23 PM
@Yota - Phew, those posts keep getting bigger ;)

I will take a look at the broadphase delegate. It's not excatly something that will be used by most people, but as I said, one small delegate does not hurt.

The ragdoll you made, was it seen from the side or front? I can't see why collision groups can't be used. Would all the geom that made up the ragdoll not just be the same collision group so that no bodypart collided with each other.
I would really like to see the ragdoll. A ragdoll is often used to demonstrate the use of a physics engine. It would be nice to have a small demo with a ragdoll.

About the debug view. If someone were to create a new controller, it would be very easy to visualize it. But... as you said; it then needs to be implemented on all the diffrent platforms as they have diffrent ways of drawing elements.
We could create a drawing manager that knows how to draw polygon shapes on each platform. Then the visualization of the new controller would simply be to make use of the buildin objects and then send them to the drawing helper.
I will take note of it when implementing it.

Yep. Silverlight does not work in the same way as normal .net. (simply put). I see that the current Farseer Physics release have a LOT of Silverlight downloads (1800 right now). Farseer is really easily ported to Silverlight. When I'm done with cleaning and make sure that the XNA release works properly, I will make a Silverlight branch that has all the Silverlight specific stuff in it. (including the demos).

Oh, BTW. Nice to see some algorithm complexity involved. First time on the Farseer forums if I'm not mistaken ;) For those who don't know what a broadphase collision detector is: Read here and here. The second link is one of the collision detectors that Farseer uses.
Sep 5, 2008 at 6:42 PM
@genbox: In the game I was working on, the ragdoll is seen from the side. (Like Diver, but a lot bigger.) Currently, it consists of a torso, four limbs (each broken into two for elbows/knees), and a head.  The collision rule was that it will accept collision from any geometry other than the ones that make up that instance of the ragdoll.  If I were to use collision categories, I'd have to give each piece of the ragdoll its own category.  Then, what would happen if two instances of the same ragdoll came into contact with each other?  Unless I'm misunderstanding how collision categories work, it sounds to me that RagdollA's forearm would only be able to collide with RagdollB's forearm. (And the same with each of the other parts.)

"Oh, BTW. Nice to see some algorithm complexity involved. First time on the Farseer forums if I'm not mistaken ;)"

Err... looking back at that, the Big-O notation I gave is inaccurate...  I had some train of thought when I posted that, but now it's making no sense to me. *sigh*  Never take me too serously. =D

Now on to the next question.  Currently, a Body's 'Rotation' property is clamped to (0 <= Roation < 2Pi).  In that project mentioned above, I found it a heck of a lot easier to control the ragdoll when I changed it to (-Pi <= Rotation < Pi).  Now this can really easily be adjusted on a per-project basis, (only requires a change in two of the Body's methods) but I'm wondering what sort of benefit the 0-2Pi setup has.  Are positive floats earier to process, or are they generally easier to manipulate.  I've only had to make use of the Rotation property in that one project, so I can't say from experience.  In my project, I found -Pi-Pi better because I needed to determine how much the body was tilting away from being perfectly upright, but I can understand how this isn't something most people would be concerned about. (This isn't necessarily related to the future of the engine, so don't think too much on it!!  It's just my curiosity.)
Coordinator
Sep 5, 2008 at 11:26 PM
Edited Sep 5, 2008 at 11:28 PM
There is a lot of ways to use the collision groups system.
There are 3 properties in the geom class:

CollidesWith - Default is CollisionCategories.All - Defines the categories that the geom will collide with
CollisionCategories - Default is CollisionCategories.All - Defines the categories that the geom is a member of.
CollisionGroup - Default is 0 - Defines the collision group that the geom is a member of.

CollisionGroup is the easiest to use. All geoms in the same group does not collide. GeomA of group 10 and GeomB of group 10 will not collide.
CollidesWith and CollisionCategories are the more advanced way of making collision groups. But works in kind of the same way.

The enum CollisionCategories is defined with the Flags attribute (info here) that enables you to use bitwise addition or substraction of categories.
Example (taken from demo 5 in the samples):

_agent = new Agent(ScreenManager.ScreenCenter);
_agent.CollisionCategory =
CollisionCategories.Cat5;
_agent.CollidesWith =
CollisionCategories.All & ~CollisionCategories.Cat4;
//collide with all but Cat4 (black)

_blackCircles3 =

new Circles(startPosition, endPosition, 10, 9, new Color(0, 0, 0, 200), Color.Black);
_blackCircles3.CollisionCategories =
CollisionCategories.Cat4;
_blackCircles3.CollidesWith =
CollisionCategories.All & ~CollisionCategories.Cat5;
//Collide with all but Cat5

EDIT: The current release of the Farseer source code (1.0.0.5) contains an error in the comments. It says "//collide with all but Cat5 (black)" - This is fixed in Farseer 2.0

As you see, the agent is in category 5 and collides with all other geoms but category 4. The black circles are in category 4 and collides with all but category 5. This enables advanced use of collision groups.

TODO: Might want to keep a reference to this info for later use in the Farseer manual.

Crashlander might be able to answer the question about the use of 2pi. :)

Sep 9, 2008 at 1:39 AM
Edited Sep 9, 2008 at 1:45 AM
Hi genbox,
Earlier in the year I took on the task of porting Farseer Physics to the Blitzmax programming language. I noticed there was a request from garus for collision event handling for the event of two bodies 'separating'. I've come across this need on several projects that I fiddled with in both C# and the Blitzmax version. I believe I came up with a decent solution at the engine level to detect the 'separation' of two bodies. I illustrated it in a demo app I created that could found here:

Farseer Physics BMX
(demo #13)

it used both the 'on collided' and 'on separation' events to toggle the 1 to a 0 and so forth. This was one of the 'additions' I made while porting to Blitzmax.

The implementation for this was in the ArbiterList class. under the method "RemoveContactCountEqualsZero" after I remove the arbiter from the pool i call geomerty A's onSeparation event Handler. (more correctly I should call both...oops). The logic behind this was that arbiters were 'removed' once there were no contact points in the arbiter (they've separated). It's worked well in most of my cases where it was used for more 'platformer' physics. This may work for most but again like you said, may not be the most accurate if arbiters aren't instantly removed once their contact points are zero.


Coordinator
Sep 9, 2008 at 8:35 AM
@AlexO - I think that the best way of doing it might be what you have done. Checking when contacts are removed from the Geoms sounds like a good idea.

Thanks. I will take a look at it.
Developer
Sep 17, 2008 at 11:18 AM
Ok, here is a nice one for 2.0:
I'd like to set the elasticity of a body.

You know, a rubber ball behaves different then an iron ball with the same mass.

.. and sorry, I can't help you with that.
If I could I'd probably already have my own physics engine :-p ...
Coordinator
Sep 17, 2008 at 11:28 AM
We could create an extension to the factories that create a ball depending on an enum. We can't emulate a rubber ball 100%, but we could make a tennis ball, a bowling ball and so on. I might take a look at it and see if there is any potential.

Thanks for the idea :)
Sep 18, 2008 at 4:03 PM
AlexO - that is exactly what I meant ;) Nice one.
Coordinator
Sep 20, 2008 at 12:12 PM
Damn, there is a lot to read it this thread.

Thanks for all the suggestions and ideas.

About the 2.0 release, genbox, do you think it would be a good idea to first focus on a release that contains just the refactored code and simple/obvious bug fixes, then once that is out and tested for all platforms start adding the new bigger features for a 2.1 release?

I think this would make it easier to find any bugs or issues related to the code-refactoring and it'd be easier to get things running on the other platforms.

I'm going to let you decide what you think is best for version 2.0 since I obviously don't get a lot of time to help, just wanted to throw that out as a suggestion.

-Jeff

Coordinator
Sep 20, 2008 at 1:52 PM
Hi Crashlander

I have been testing the refactored code a lot by now. I've been running the demos in XNA and WPF. I have also tested some simplified versions of my own games.

There might be some small bugs I have not been able to test against, but with the source control, it's a lot easier to track them down. I think that the 2.0 release should be with the new changes. If we find any bugs, we just revert back to a version without the changes (if it's hard to track and not obvious). I will implement the 2.0 version with one feature at the time. This makes it easy to track changes (for the public) and track bugs related to new features.

I hope all is going well Jeff, don't work your self to death ;)
Coordinator
Sep 20, 2008 at 5:08 PM
Posting here to notisfy everyone with email/rss subscriptions that the original post has been updated.
Sep 23, 2008 at 4:25 AM
Please update grid.cs to include this safety check. It would be really good if you could do that please.$0$0$0$0http://www.codeplex.com/FarseerPhysics/Thread/View.aspx?ThreadId=29090$0$0$0$0$0$0Thanks.$0
Coordinator
Sep 23, 2008 at 8:04 AM
That's already done in Farseer Physics 2.0 by Daniel Pramel. (called dp2208 here) Thanks Daniel.
Developer
Sep 23, 2008 at 8:48 AM
We could create an extension to the factories that create a ball depending on an enum. We can't emulate a rubber ball 100%, but we could make a tennis ball, a bowling ball and so on. I might take a look at it and see if there is any potential.

Thanks for the idea :)

Uhm. Isn't the RestitutionCoefficient what I was looking for ^^ ?
http://www.codeplex.com/FarseerPhysics/Thread/View.aspx?ThreadId=36085

I'm at work so I'll have to check it out later.
Coordinator
Sep 23, 2008 at 8:57 AM
@sickbattery - I think it was. At least that's what I thought you were thinking about. :)

When I said we can't emulate a rubberball 100%, (I was thinking about soft bodies.. When I think about it, a tennis ball is also very soft. hehe) But yes, we can make a ball more bouncy with RestitutionCoefficient.
Coordinator
Sep 25, 2008 at 8:49 PM
I want to hear your opinions on this.

What about creating a detector/sensor functionality?
A lot of times games want some method of checking if a character has reached goal. (Think Mario and the flagpole).

Such a sensor would behave just like a static body, but would not be included in the impulse calculations (Other objects don't bounce off the sensor, only detect collision is enabled).

I was reading the Box2D wiki and saw this sensor thing, thought it was a good idea, but what do you think?
Sep 26, 2008 at 12:58 AM
Edited Sep 26, 2008 at 1:02 AM
I think this a great idea, currently in my pinball game I've got about 20 of my own sensors which are just 5 or more vert circles that don't colide with any thing and have a custom collision handler.  I think this is a great feature to add-on shouldn't be really that difficult to implement.  Can't wait to see the finished product especially multi-threading.
Developer
Sep 26, 2008 at 6:49 PM
Sounds great ;D.
Coordinator
Sep 26, 2008 at 7:31 PM
Great! :) I'll put it on the TODO list.

Thanks for your feedback guys (Well, it's only you 2, but it's better than nothing)
Developer
Sep 26, 2008 at 8:56 PM
Sorry, for the lack of feedback. There is a ton of things we could add to Farseer, but only a few people have the know-how or time to do it.
Oct 19, 2008 at 2:03 PM
About sensors, i would also recomend a trigger/probe system. Should be easy to implement, and very useful in most types of games.
Coordinator
Oct 19, 2008 at 2:07 PM
@Carlsen - How should this work?

The current sensor triggers when something touches it. It's also possible to probe on every update if they collide.
Oct 19, 2008 at 5:27 PM
A probe is a "sensor" that can only detect triggers. So, for example, your main character could have a probe attached, and you could place trigger boxes in your level, to trigger different events. A trigger sends an event, when triggered by any probe, including a reference to the probe that triggered it.

Having a such system, you would rarely need to use events from the actual collision geoms, and hence have a more intutive seperation of object geometry, and "sensors" that actually triggers some game related event.

This can of course simply be implemented on top of Farseer, but since Farseer is a physics engine specifically for games, it might make sense include something of sort.
Coordinator
Oct 19, 2008 at 6:23 PM
If I understand it correctly, there should be no difference between the current implementation and the one you propose.

If a geometry collides with a sensor object, the sensor and geometry collision event is fired. Your geometry could be in the same scope as the event registration, so you will have a reference to the object. But if you decide to change it so that you can't reach the object, you can use the Tag property of geometries to contain your object.

If you are thinking about performance, Farseer will at least check all geoms once for collisions. The broadphase collision detector algorithm makes sure that only objects close to each other gets checked in the narrow phase. Creating a seperate trigger/probe system would take the workload from checking against 1, 2 or n many geoms, but the trigger/probe system would still have to check for collisions between trigger and probe.

There is also a new Collision event in the broad phase that speed things up even more. This event fires at "raw" collisions in the broadphase.

Try playing with Farseer Physics 2.0 when it's released, if you still think a seperate sensor system should be implemented, give me a hint and I will have a look at it.
Oct 19, 2008 at 6:38 PM
Will do Genbox. Looking forward to the release.

Have not played with the alpha yet, so the trigger/probe were merely a thought from playing around with Farseer 1.0 some time ago.