Farseer Physics Engine 2.1

Dec 3, 2008 at 1:57 PM
As some of you might know, Farseer Physics Engine 2.0 was released not that long ago. I was quite pleased with the community responses and requests, so I'm doing the same as the last time and ask you guys what you think should be included in Farseer Physics Engine 2.1.

We have a large TODO list in the workings and believe me when I say that it contains some rather big improvements. (Both in features and performance). More details of what this includes comes later.

If you have any requests, improvements, fixes or the like. You are welcome to give us a piece of your mind.
Dec 3, 2008 at 10:38 PM
Noob question, but where can we find the current todo list?
Dec 4, 2008 at 4:24 AM
Hey genbox....once again, loving the engine...it's made my life so much easier. Here's the two things I've run into that have caused me headaches so far:

1 - Forces applied to object that are already collided can cause them to penetrate. If I apply a great force to an object resting on my landscape in the direction of the landscape (say my ship collides with an object at rest) it can cause this object at rest to penetrate the landscape even though it is already colliding with it...it only happens with large forces, such as those imparted with full speed collisions or with explosions.

2 - Rotation, Velocity Clamping. I'm still running into NaN errors when objects have large forces imparted that cause wild collisions...automatic clamping of rotation and velocities to the max values that a float can represent would be nice (and fix all of my current 'crash' bugs).

3 - Also, it would be nice to be able to specify the Terminal Velocity of an object. I currently clamp the object's velocity manually during the update, but it doesn't quite produce the effect that I'm after...I'd like an object to fall no faster than it's terminal velocity UNLESS it's under an outside force. This way I can accellerate beyond terminal velocity through the use of "engine thrust" but when the thrust is cut off, frictional drag should cause me to return to terminal velocity.

4 - A demo of a "warm-up" state where the physics sim runs at a longer timestep to bring objects to rest to setup an "initial state" for the physics sim when the game begins. I find my biggest slowdown comes when I first start a level and I have that initial period where all the objects are colliding and coming to rest before they hit the "auto-sleep". Currently I run the sim until it hits my target framerate underneath the "loading" screen. The problem I have is that on slower PC's, I may never hit that target framerate, so it'd be nice if I had another way to determine when the sim was ready for me to start. This should be possible with all the current features, I just think it would be nice to have a demo on what method would be best at detecting a favorable sim state for starting. Does this make sense?

I think that's it...otherwise, wonderful engine. It does just about everything I could possibly ask for in a rigid body physics engine! Thanks again to your entire team for all your hard work!

Oh...the last thing. If you could find an easy way to store the "state" of the physics sim and iterpolate between states...this would be helpful for multithreading...but I would put that low on the list as the engine is already very speedy if you turn on the "auto-sleep" for object...I've got around 110 objects in scene and I'm still averaging over 70fps.
Dec 4, 2008 at 9:10 AM
Edited Dec 4, 2008 at 9:27 AM
@daswampy: I'll write the TODO list in this thread later when I have more info from the other team members.

@seiggy: Hi. Thanks for the feedback.

1. This is normal behavior. I know that sounds stupid, but that's just how things are right now :) We actually have some features planned for 2.1 that will prevent/reduce this.

2. We have no checks inside iterated properties as it reduce performance. Using high force values can blow up the engine and is not recommended. But I already have written in the todo list that we need more checks in properties. I will try to get it resolved in 2.1

3. Okay. Will have a look at terminal velocity for bodies.

4. Yep, it makes sense. It can be hard to determine with 100% accuracy if the geometries have come to rest. Your best bet might me to count the number of sleeping bodies and aim for that number on every run. This can be tricky when using variable timestep or when you change physics engine version.

5. I will have a look at implementing serialization in the engine in some different ways. It could be used for savegames where a body is flying in mid air and it should continue when you load the savegame. Another is saving the state for transfering over a network or interpolation between states.

Thanks for all the kind words. We really appreciate it.
We are trying to implement some new algorithms in 2.1 to make the engine perform more. We keep the old ones and make it possible to choose the new ones, just like the current broadphase collision detection system. I will also make sure to write about it in the manual.
Dec 4, 2008 at 8:17 PM
Edited Dec 4, 2008 at 8:23 PM
3. Terminal Velocity is a rather complex equation and you need to know the amount of drag on the object that acts against the vertical velocity of the object - drag depends on a drag coefficient, the atmospheric density, the square of the air velocity, and some reference area of the object. Anyway, I looked at this myself and came to the conclusion that it was far too 'expensive' to implement when clamping the velocity will work just as well (in my case).

5. I'd like to second the vote for some way to store physics state.

Dec 4, 2008 at 8:28 PM
@DrDeth: Any implementation we might come up with will only be enabled if the user want it to be. But it depends on it's usage and perfromance :)
If you have any implementation of terminal velocity you are welcome to send it to me. We are grateful for anything that helps us.
Dec 5, 2008 at 2:18 PM
I didnt get as far as an actual implementation. I could take a stab at something useful if you'd like? The only way I'd see it being useful (given seiggy's original use case) is to calculate the optimal value to use in clamping, and to limit the velocity of falling objects.

On another note, I've just got polygon subtractions working in my FarseerPhysics extensions. I'll be updating my feedback thread shortly with a link for you.
Dec 5, 2008 at 3:14 PM
@DrDeth: Sounds great! If you could create an implementation that simulates terminal velocity with respect for external forces (impact from falling objects with no terminal velocity or user applied forces) it would be great. Thanks for all your contributions so far, I look forward to have a look at your polygon subtractions.
Dec 5, 2008 at 9:30 PM
I will be working on performance issues mostly. I'm going to try and get realtime geometry creation going so I can implement some super cool features I want to keep secret until I have a prototype working. So most of my work will be focused on abstracting the different parts of the engine without breaking existing code. If my goals are not achievable with the current setup then I am going to start my own engine and focus on usability, features, speed, and high level functions.
Dec 6, 2008 at 6:12 PM
Hi, I am making the game of the side-scroll base by using Farseer.
The interface of Farseer is good.

There is a problem that should be realistically cleared when the game is made.
Roughly a lot of people have similar worry?

1-a. Treatment of shape(Geom) of character, jump and move (especially, slope and rotation).

1-b. Detecting state of "Standing", "Moving(Walk, Run)", "In the air", "Swim" ... for draw animation, finite state machine(AI in the wide sense), etc.

2. Penetration, high-speed object, big range of small/large object.

3. Method of sounding when object collides, When is the sounded?

It is glad when there is a Document or Sample code. I'm sorry in a rude demand.
Dec 6, 2008 at 6:42 PM
1. We do not provide drawing or game specific features. It's up to you to make that feature.

2. We already have that on our list. Thanks for the suggestion though.

3. We have the OnCollision event that you can subscribe to. You can play your sound inside this event.

If you have any questions about Farseer Physics, you can have a look at our manual here: http://www.physicspoweredgames.com/FarseerPhysics/Manual2.0.htm
Dec 9, 2008 at 11:38 AM
Farseer 2.1... time flies fast ^^

If I may make a little wish :D for Geoms. Position offset and rotation offset aren't public at the moment, thus you're just able to modify them through the constructor. Please, please give Geom 2 public properties to modify them.

Looking forward to v2.1
Dec 9, 2008 at 4:27 PM
@sunDiver - Naah, we are really just looking around for features and the like. Just want the community opinion on the next release, we are starting the real planning in the new year.

I have written your suggestion down.
Dec 15, 2008 at 5:11 PM
I've always wondered why the Factory classes (or at least the methods inside) weren't static.  Do we need that 'Instance' field?  Do we even need the factories?  I've wondered why some of these methods aren't part of their respective classes already.  For example, why the BodyFactory methods aren't static methods on the Body class.  CreateLinearSpring() should be a method, or even constructor of the LinearSpring class.  This would be one less namespace to think about also.
Dec 15, 2008 at 5:22 PM
@Yota: I guess a lot of people have had that thought. I've had some questions about it in the past.

Jeff was the one to make those factories, and he did it with good (and simple) design in mind. In my opinion he chose the right design by using the GoF Factory Pattern that gives away the responsibility of creating objects, to a dedicated class. This can be combined with a lazy loaded GoF Singleton Pattern that makes sure that only ONE instance of the factory is ever created, and that -singleton- is only loaded when needed.

If we rebuild the factories to be static, they will be instanciated at runtime and reserve memory before (if ever) they are used. If we gave the responsibility to each of the classes (such as Body or LinearSpring as you mentioned) we would have potentially 1000 instances of classes that all does the same logic (and use a lot more memory).

So for performance and design reasons, Jeff chose to implement those patterns. Hope that answers your question.
Dec 16, 2008 at 9:13 AM
Farseer is great, my concerns are that you might overload it or make it hard to use oO.
So, "don't overdo it" is the only point I'd like to add to the todo list :-P ...
Dec 16, 2008 at 11:21 AM
@sickbattery: ever saw them "overdo it"? ^^
Dec 17, 2008 at 9:47 AM
Uhm, I've seen some hard to use engines. Does that count ^^ ?

I'm thinking about a destructable surface generator.

I have an idea for creating polygons with holes and more then one part per texture and I wanted to use this to create a static surface - which would consist of static geoms created over large bitmaps.

DrDeth gave me an other idea of updating the surface and I thought about it again and came to the evil conclusion that Farseer needs destructable Geoms. It's unavoidable. Sorry guys o_O ...

That way I'd just update the CretePolygon function and add a new function to the GeomFactory CreateGeoms and/or BodyFactory CreateBodies. We could take DrDeth's boolean operations code and simply allow some polygon operations on the geom.

I've never used the controllers but they sound like one could create a DeformationController?

I'm not going to dive into more details right now. I have to work god damn it -_-!
Maybe you already had that idea?

I'll have some free time in january ... and on week ends of course so I'll tak a look.
Dec 18, 2008 at 5:23 PM
Edited Dec 18, 2008 at 5:25 PM
@genbox:  Sorry, I still don't quite understand.  Though as a mere user of the library, I suppose it isn't really my job to.

There are already two static members of these factory classes as it is. (The Instance field and property.) So we already have some memory being allocated at startup. (4 or 8 bytes?) If I recall correctly, method definitions are all metadata.  Making them static wouldn't effect memory at all.  There are only a couple non-static fields in these classes, if any, but these could be moved into the methods themselves.  The standard .Net assemblies use static code like nobody's buisness, but it still seems to run well.

Also, I don't quite get what you're saying in the latter half of your third paragraph.  Last I recall, each factory method only supported one type of joint/controller.  If these were moved to their respective class, they would be able to operate for custom classes that inherit the built-in ones. (This may be possible to do with factories using generics, but the programmer wouldn't be able to override the code.)

I'm not trying to make this sound like a complaint, this is just my way of suggesting things.  I can totally live with the way things are, but I'm just throwing this out there for the heck of it. =]  Same goes for any and all of my other suggestions.  You all are doing a great job, and I'll love this library no matter what.
Dec 18, 2008 at 7:58 PM
Edited Dec 18, 2008 at 8:00 PM
@Yota: "There are already two static members of these factory classes as it is..."

No arguing there. Currently we don't utilize the full potential of the design patters as we try all we can to reduce the overall footprint of the engine. A factory such as the ComplexFactory actuall utilizes it more since it carries 4 public properties (they are static the 2.0 release, but have been changed to non static in 2.1) They should only be created when needed, and not at runtime.

You need to remember that this pattern is not a fix to some sort of problem, but at design pattern that prevents us from doing bad allocations in now and in the future.

"Also, I don't quite get what you're saying in the latter half..."

Factory pattern makes sure that you only perform creation of an object in one single place. It unify the creation of an object and can have the task of doing some preliminary to the creation process. (Like we calculate MOI of geoms in the GeomFactory).
Before the factory pattern was introduced to Farseer, we had to do this:

(NOT working code)
Geom geom = new Geom();
geom.MOI = 4.3f;
geom.Grid.CollisionGridSize = 0.5f;

We could have made it so that it was just like this:


But then we have the following problems:
1. All instances have the same creation logic (that might utilize a lot of variables) and that use a lot of memory
2. No lazy loading
3. All the code from the current factories would be in the Geom class. Code clutter.

We could also do this:


But we still have the following problems:
1. No lazy loading (not natural lazy loading, would become a hack)
2. Code clutter

So we choose to use the Factory design pattern that gives us the following:
1. Lazy loading
2. Thread safety
3. Reduced code clutter

There are no disadvantage for us to be using the Facotry/Singleton patterns, only advantages. We are also secured in the future where the use of factories might become more visible.
Oh, and as a side note, we try to use as little inheritence as possible. It too slows down code because the CLR is not able to use some of it's optimizations (under certain conditions) and the method calling structure becomes more complex, and each method called gives us slower code.

As for the methods that does not require resource allocations (memory in this case), you are totally right, but you need to remember that while our factories right now only contain methods (with the exception of ComplexFactory) but might now do in the future. Static variables are reservating memory at runtime while factory/singleton variables are reservating memory at use-time. (They might not ever be used).
For more on optimizing games for performance (or libraries) you can take a look at my Ziggyware article: High Performance Game Development
When I reread my explanation from before, I can see why you thought I was referring to methods. If you stumble upon something like that in my article, I would appreciate if you contacted me about it.

Edit: Sorry about this large thread. I'm doing 5 things concurrently and I actually lost my direction several times because of it... The life of a busy developer.
Dec 19, 2008 at 1:56 AM
I would really love to see continuous collision detection or CCD, that would prevent tunneling as mentioned by your awesome manual genbox.  I have need of this feature in my already created game, and I'm sure other people do too.
Dec 19, 2008 at 12:51 PM
@somethingnew: Indeed. This is one of our big items on our list. Matthew will working on the collision stuff in 2.1. He will be working with CCD and the narrow phase collision detection. He's a great guy and you can expect him to come up with something good. :)
Dec 19, 2008 at 10:21 PM
Hi everyone. Thx Ian.

I will be attempting to separate the narrow phase collision part of the engine to allow for different algorithms to be implemented. I am going to try and get the Separation Axis Theorem (SAT) algorithm working inside Farseer. This particular algorithm only works with convex polygons so a polygon decomposition algorithm will also be necessary, as I don't want to limit Farseers current abilities. Also, I am going to add projected geometry to this algorithm which should allow for Constant Collision Detection (CCD). While these features will be a great addition to Farseer the real bonus will be that geometries will be much simpler and easily created / destroyed / deformed in realtime. While I could focus on implementing CCD to the current narrow phase, it would not improve the creation time of the geometries grid. By using SAT I will enable realtime geometry modification.

My goals are to -
1. Fully expose the narrow phase in much the same way as the broad phase is.
2. Provide a solid implementation of SAT.
3. Enable CCD.
4. Provide several advanced demos of how to use the newly created geometries.

If anyone has any comments or suggestions please post them up here or email me at mattbettcher@gmail.com. I am very interested in any ideas and any help in achieving these goals.

Dec 22, 2008 at 1:53 PM
Hi all.

Quick thanks again for Farseer, it is lovely!

When you are working on the new release, please could you profile it using the CLRProfiler, to check for allocations during normal updates?

It would be great if you could get them completly down to zero.

I was having some performance difficulties on the 360, and by changing some code I was able to improve performance.
- I do need to double check that this applies to the latest version, as I was mucking around with quite a few bits, so i could be fibbing.

If I recall correctly it was something to do with sorting generic lists of arbiters, and I think you had made a change to it, not sure if it completly sorted out the allocations.


ps.. Sorry for the state of the message, need to go do some work!

Dec 22, 2008 at 1:58 PM
I fixed 2 allocation blobs in 2.0 before release. One of them was the ContactComparer and the other one was something in the Arbiters. I did run CLRProfiler and serveral memory profilers and it all seemed fine.

If you find any garbage buildups, you are welcome to email me and I will fix it right away. I sense in wasting cycles on the garbage collector.
Dec 22, 2008 at 5:43 PM
Cheers Genbox. If I can recreate them I will send it over. (I foolishly was changing lots of things at once, so I am not entirely sure which thing sorted out my problem)

Happy Christmas everybody!

Dec 23, 2008 at 10:36 PM
Edited Dec 23, 2008 at 10:53 PM
Polygon from texture with hole detection anyone? ... someone?

I had to make some changes in Vertices.cs (CreatePolygon is now CreateSimplePolygon; CreatePolygon creates now polygons with holes) and I've added a new class (PolygonCreationParameters.cs - I had enough of all the parameters I had to pass over and over again.) but ... that's ok, right ^^?

Put that onto the todo list oO?

(Don't discuss the pic. I know what's wrong and I know what to do. It's just that I have a little feeling of success and want to share it xD.)

The code is still pretty fast. Don't worry.
(I've created a small collision detection function on my own (which is called only once per line) and I check only the pixels inside the polygon.)

Oh and merry x-mas :).
Dec 24, 2008 at 10:31 AM
Great work sickbattery.

There are some problems though. Farseer Physics is not designed to work with polygons with holes in them. First of all; putting anything inside the hole would cause the geometries to be included in the narrow phase collision detection all the time because the AABB covers the hole.
Farseer was also not designed to takes holes into account. It is used to work with concave and convex polygons without holes in them. creating a hole inside a polygon with the same set of vertices might expose some problems.

Anyway, it's still neat what you have done and I would be grateful for any improvements you might come up with. You can upload patches to the project under the Source Code tab here on Codeplex. If you have any improvements that you would like to include, you are welcome to upload them.

Merry Christmas to you to and everyone here.
Dec 24, 2008 at 1:46 PM
Hey genbox,

I know that farseer can't handle holes in polygons and that's why I'm not creating any ;). It's still one line. Two of the edges cross in the pic above. That will be gone in the final release. No edge will cross and it'll stay a single line. ... I have no time to write more details, sorry I'm in a hurry.

I'm glad you like it :).
Jan 12, 2009 at 4:31 AM
Edited Jan 12, 2009 at 4:46 AM
Um, i hope you guys don't mind me adding my two cents...

So here's my feature wish list:
1a. Some way to offer more control over which geoms collide and which don't (more than collision groups offer) (e.g. a Do Not Collide (DNC) list in each geom and then each broad phase collider does a check to see if either geom has the other in it's DNC list)
1b. as a second step, you could offer a way for the user to further customize the broad phase collision functions with some arbitrary code (you could register a function into a variable which is then called by the current broad phase collider)
2a. Some way to easily change the global gravity on demand (so that you can have gravity shifting levels)
2b. this is not very important, but it would be cool if there were a way to set body-specific gravity (which could make "gravity zones", among other things, easy to implement)

Almost all of these features i either have implemented or have plans to implement so i can post the code if you want.
Jan 12, 2009 at 8:04 AM
1a. We do have CollidesWith and CollisionCategories to enable more complex collision logic. We have gotten the request to add lists before so that the engine performs fewer iterations. If you have an implementation for this, I will be happy to look at it.

1b. Right now you just create a new class and inherit the IBroadPhaseCollider interface. We need to do it this was as we want the broad phase to be very modular. Again, if you have some other implementation than this, I will take a look at it.

2a. The PhysicsSimulator.Gravity property can be changed on the fly to change gravity.

2b. Body specific gravity is not really something you see everyday :) I've been thinking about implementing planetary gravity (Gravity zones) so that you can you can create space levels. This is only something I've been thinking about, but if anyone has an implementation of this (can also be seen here) I'll be happy to take a look at it.
Jan 14, 2009 at 2:05 AM
Edited Jan 14, 2009 at 2:06 AM
About 1a. i considered both of those methods (and will indeed be used in my game), but i needed some way to just say to the collider, "don't collide these two geometries". As for posting the implementation, which would you prefer: just posting the changes i made, or taking the cs files i modified and zipping them up and posing a link to them?

for 1b. i mean making it so that all of the existing colliders support user written broad phase code (so that they can implement some arbitrary logic without having to make a whole collider of their own)

for 2a. i didn't know that thanks.

for 2b. i guess i actually should implement on my own something like that for my game if i am indeed going to do that. Actually, i am just toying with the idea of gravity zones and probably wont implement them for a while

Also, i remembered another idea that i wanted: Mass, size, and velocity based collision control. What i mean by this is you could make objects act like nets or soft materials by having colliders optionally check the appropriate values and not collide geom pairs if the collisions are right (there could be MassBasedCollision, SpeedBasedCollision, and SizeBasedCollision values and then properties to define thresholds for collision)

the other thing i thought would be cool, but not important, is adding soft geometries/bodies. Currently, there seems to be no open source physics engine of any decent quality that can simulate both hard and soft bodies at the same time. I figure that this is a huge feature and i hope it is being planned for implementation sometime in the future, but if it's not i understand.

P.S. I love the engine and it has been a godsend!
Jan 14, 2009 at 9:34 AM
RogueCommanderIX - If your changes are only to the engine, I would prefer a diff file.

1b. I've written it down on my list. But for now we keep it as it is. Thanks for the suggestion.

As for the soft bodies. We are not going to implement real soft bodies in the near future, but we do have plans for fake soft bodies to simulate soft bodies.
Jan 14, 2009 at 10:08 AM
What is a diff file and how do i make one?

1b. you're welcome.

Soft bodies: perhaps you could elaborate slightly on the "fake soft bodies" thing?
Jan 14, 2009 at 10:21 AM
A diff file is a file that contains the difference between the basic Farseer Physics version and your own. There is a ton of tools to do that. I use Team Explorer, it's a part of our connection to the Team Foundation source control here on Codeplex.

I will give more info about the fake softbodies soon as I will release the Farseer Physics 2.1 changelist (todo list) soon.
Jan 14, 2009 at 12:24 PM
1) It would be nice to have real circles rather than approximations with geometry. It should be faster as well.

2) I get lots of floating point exceptions due to numeric error. I think the main problem is that the engine relies on units as pixels and that causes big numbers to appear. Adapting the engine to accept Meters, Newtons, Kilograms, Seconds as standard dimentions would help. I am not saying everyone should use MNKS but at least the engine should still work if you used it. I converted my game to use pixels but it's so hard to tune the parameters and I easily get massive numbers.

3) Soft body physics would be a major step forward

4) I get occasional un-explainable penetrations. Might be because of the big numbers involved.

5) Unit tests would be nice.
Jan 15, 2009 at 11:10 PM
Edited Jan 16, 2009 at 8:49 AM
I'll see if i can hunt down a tool for diff files. BTW i am using v2.0.0 should i use the newest version to make the changes? I can hardly wait till that list comes out! :)

EDIT: i have decided to use WinMerge as a tool to generate the difference file (it is called a "patch file" in it) and pending a method to host the file, i will post a link to it.The files i change are: Geom.cs, and the 3 colliders. I haven't applied any optimizations or anything to the code (like inline stuff or anything), because i just wanted a simple implementation.

EDIT2: i just thought of another feature that i wished was in the engine: some sort of air friction type thing (so that i can simulate drag easily). It doesn't have to be complex, just a simple (adjustable) reduction of speed every frame)

EDIT3: the file is at here, if your tool can read GNU/diffutils compatible files then you're fine. in case you can't use that file, here is the whole project. The changes are only to the Geom.cs and the 3 colliders.
Jan 16, 2009 at 12:28 PM
Thanks a lot RogueCommanderIX. I will take a look at it later today. I've also used WinMerge before, It's an excellent tool.
There is only a few changes between 2.0 and 2.0.1. Diff files for 2.0 will do just fine.

As for the drag. We have the LinearDragCoefficient property in the Body class to control drag. We also have RotationalDragCoefficient to control the rotational drag.
Jan 18, 2009 at 12:41 AM
Oh yeah i forgot about those. You're welcome!
Jan 18, 2009 at 4:42 AM
Edited Jan 18, 2009 at 8:28 PM
One thought that I was recently having was would it be possible to have some physics on the GPU, say Broad Phase that uses the GPU to detect if a texture is overlapping, then the results read back to the CPU (I know it's slow, but do it one frame late), after that do narrow phase.  The only disadvantages is it only works on Windows (if you have the graphics card) and Xbox 360, and that physics would be delayed by one frame.  I really not sure if this would completely work since the engine is iterative so it would be behind I think 5 cycles in reality.  If you guys think it's worth doing, I'd reccomend looking at Shawn Hargreaves' new blog post about detecting overlapping textures on the GPU here: http://blogs.msdn.com/shawnhar/archive/2008/12/31/pixel-perfect-collision-detection-using-gpu-occlusion-queries.aspx  I would like to try it if you guys think it's possible.
Jan 20, 2009 at 11:00 PM
While GPU based stuff (ray tracing, ray casting, occlustion testing, etc..) is great, it is not faster then a even a simple brute force. That being said it is possible to move actual physics calculations to the GPU, but probably not with Farseer. A GPU based physics engine is possible (especially with CUDA), it would most likely need to be written from scratch to enable good performance. It's actually on my list of things to try out, but not for Farseer. 
Jan 21, 2009 at 2:09 AM
Makes sense, good luck with it.
Jan 22, 2009 at 4:24 AM
Yeah CUDA would be pretty hard to use with farseer. I recently found this (CUDA.NET) and after a brief perusal of the manual (which said a bunch of stuff and the code samples indicated manual memory allocation) i decided not to even try to use it to improve farseer. it might be possible, but i certainly couldn't do it (memory leaks anyone? :P)
Jan 22, 2009 at 4:41 AM
Yeah, if I going to use a GPU enabled physics engine it would probably have to be NVIDIA PhysX since they made CUDA and it used already by many pro games.  I was just theorizing if it would at all be faster for Farseer to be on the GPU, but as Matt pointed it would be really hard on the surface to move calculations there.  Thanks anyway.