Farseer Physics 2.1 and 2.2 Development

Topics: Developer Forum, Project Management Forum, User Forum
Coordinator
Jan 17, 2009 at 2:14 PM
Edited Jun 5, 2009 at 1:14 PM

This is our current changelist for Farseer Physics Engine 2.1.
Have in mind that the list is still subject to change. We will keep you updated on any progress by updating the list.

Version 2.1

  • Done - Change default behavior of paths.
  • Done - MSDN style online documentation
  • Done - More code documentation
  • In progress - Water simulation documentation
  • Done - Weld Joint
  • Done - New narrow phase algorithm
  • Done - More checks in code
  • Done - Raycast helper
  • Done - Auto-divide geometries
  • Done - Vertices union/clipping
  • Done - Modular narrow phase
  • Discontinued - Gear joint
  • Done - Ragdoll sample
  • Done - Support for multipolygon texture
  • Done - XNA Water sample
  • Done - WPF Simple samples
Jan 17, 2009 at 8:33 PM
Nice, will 2.1 prevent penetration in any way? Also do you have an estimated release date?
Jan 17, 2009 at 8:43 PM
Penetration will be solved by CCD it looks like in 2.2.
Jan 17, 2009 at 11:55 PM
I'm rather confused about something. In 2.2, you list a "fake soft bodies sample" item but there is no "fake soft bodies" item (that i see). Can someone clear this up?
Coordinator
Jan 18, 2009 at 12:57 AM
RogueCommanderIX - Fake softbodies can already be done with current versions. The sample is composed of springs and geometries made in such a way that it resemble a soft body. It's going to be in the advanced samples. It's not very useful (to most users), but demonstrates some of the more advanced powers farseer have.
Jan 18, 2009 at 1:18 AM
Edited Jan 18, 2009 at 7:02 AM
hmm... interesting... perhaps you do it by adding a single point to a Vertices class and then making a polygon geom? also, will you be having some sort of SoftBodyFactory type thing?
also, wouldn't removing the geom creation from path generators only increase the work the user has to do? i can see where you might want it to be able to just generate bodies for a chain or something but wouldn't you then want to modularize the steps in case somebody does want the geoms automatically created?
Jan 22, 2009 at 3:43 AM
Edited Jan 22, 2009 at 4:16 AM
After looking at Box2D's manual, i decided to try to implement the Pulley joint. I know that a pulley can be simulated by chain looped around an anchored wheel, but i figure that it could be much more efficiently simulated with a joint.When i have finished the code (it will integrate with the engine by deriving from joint and doing all the rest), i will post a link to it. While im at it ill experiment with joints and see what i can come up with (a Gravitate joint comes to mind).

EDIT: im having problems with the hard drive that i store Farseer on. when i have a chance to fix it, i will make those new joints and post a link to them.
Coordinator
Jan 22, 2009 at 7:03 AM
@RogueCommanderIX - Any contributions are welcome. It's also possible to upload files under the Source Control tab. There is a link at the top that says "Upload Patch".
Jan 25, 2009 at 6:14 AM
Edited Jan 25, 2009 at 9:14 AM
ive finished the fixed gravitate joint, and as soon as i add a non fixed one, integrate it with the factories and stuff, and test it i will upload a patch.

EDIT: i added the patch file. for details, see the description there.
Coordinator
Jan 25, 2009 at 2:45 PM
Great RogueCommanderIX. Thanks for the contrubution, I will take a look at it.
Jan 26, 2009 at 3:28 AM
You're welcome. BTW do you want me to upload a patch containing the DNC list change?
Coordinator
Jan 26, 2009 at 6:32 AM
Yeah, why not. :)
Jan 27, 2009 at 1:24 AM
The DNC list patch is up now. PS: call me RCIX.
Developer
Feb 3, 2009 at 8:19 AM
Hi,

I've been busy the last month and couldn't work on the polygon from texture code but I already have done enough to make polygons with holes. I will continue my work and I think I'll pick up Dr.Deth's code. I still don't know much about it, but I'll take a look. Maybe I'll replace my subtraction code with his (or his with mine, I don't know if his code is able to create fake holes). ...and I'll also make it possible to create multiple polygons from a texture.

However oO. I don't see this feature in the list. So, genbox you may want to put it in there for 2.1 ? I'll need one, two or at max three weeks.

... and uhm what's Auto-divide geometries ?

Best Regards.
Feb 3, 2009 at 9:53 AM
i think its where the engine tries to detect if edges are too big and then divides them if they are. Not sure about this tho.
Developer
Feb 3, 2009 at 10:01 AM
Ok, that sounds right. I was just wondering if the polygon operations code is already implemented and ready or if there is something like it or if someone is working at it (auto-divide sounded something like that). Didn't have much time to look into the Vertices class. I'm at work so I'm in a hurry here ...

Thanks!
Coordinator
Feb 3, 2009 at 3:10 PM
@sickbattery: Auto-divide geometries is a feature to split up a large geometry to several smaller geometries. Just like the "Chunking up the landscape" part of our manual. It to increase performance by reducing collision tests.
Developer
Feb 4, 2009 at 12:39 AM
The Auto-divide will hopefully be able to split a large single Geom into a nice grid of Geom's. This will allow larger Geom's to take more advantage of the broad phase collision dectection (fast) instead of always running into the narrow phase.
Developer
Feb 4, 2009 at 9:31 AM
Ok, but it's only for fixed objects. Right? Or will you connect moving multi part objects with joints?

I've been to the Convex vs. Concave Polygons thread first and ... I don't know. Should I continue with the way of creating polygons or change it to multi part like described in the linked thread?
Developer
Feb 4, 2009 at 10:45 PM
Well you can add multiple Geom's to a single Body and they will act as one without any joints between them. The benefit of sub-dividing a large polygon, say 500 edges, is that less edges will need to be tested in the narrow phase because most of the work will be done by the broad phase (which is very fast). This feature should work on any geometry, but as most moving geometry's shouldn't have tons of edges it's mostly for terrain geometry or static geometry. 

About the method for creating polygons from bitmaps... I feel the best method is to create a set of convex polygons. As for holes inside the geometry this would be a great feature but seems hard to accomplish. Remember that we are going to a fairly major overhaul of Farseer in version 2.1. Don't be afraid to break old code in an effort to make better code and structure.
Developer
Feb 5, 2009 at 6:55 AM
"Well you can add multiple Geom's to a single Body and they will act as one without any joints between them."
Oh ... yeah, I knew that one can add more then one geom to a body but I thought they wouldn't be connected. Hmmm -.- ... why didn't anyone tell me? (Update the docs please. I didn't find it there either, but I also didn't have much time to look for it.)

"As for holes inside the geometry this would be a great feature but seems hard to accomplish."
Once you've done it, it's pretty simple ;D. Since the multi convex polygon thing isn't an compat breaking issue I'm going to go that way and create multiple convex polygons. I just hope that the hole detection alg. wasn't a waste of time oO. Searching for parts could make it redundant.
Feb 6, 2009 at 2:20 AM
I propose that a terminal velocity feature be added (so that bodies can't move faster than a certain speed if the developer so chooses). I'm planning to get it done and should have it up tonight. Also, how do you guys like those other features i uploaded?
Coordinator
Feb 6, 2009 at 2:39 PM
@RCIX: I hope I'm in time to tell you this :) The LinearDragCoefficient works like a terminal velocity for bodies. As you might now, all bodies (in the real world) are pulled towards the earth by gravity. All bodies also have a medium in witch they move (such as air) and they essentially provide drag to the body. Terminal velocity is when the downwards force of the gravity is equal to the upward force of the lineardrag. This will make a net force of 0 an thus the velocity of the body will be at a constant value.

If you however apply another downward force to the body (by a collision by another geometry or manual force) the body will move faster than the terminal velocity but after some time it will be at the terminal velocity again.

I've had a look at your code. And first of all, thanks for contributing! The DNC patch looks a lot like the current functionality of CollisionGroups or CollisionCategories. We choose to use simple numbers and bitwise calculations to speed up the test (if geoms should collide) instead of a list of geometries to not collide with. This is for performance reasons.

As for the GravitateJoint. Looks great and I like the idea of gravitation implemented as a joint. It's great if you only want some specific bodies to be affected by the gravity. (For whatever reason you would want that). I do have an extention to make to your gravitationpoint (or more precise, a whole another way of doing it). If you are interested I can tell you the idea and maby you could implement it? Then I can get to the huge todo list I have :)
Feb 7, 2009 at 6:51 AM
RCIX: i was wondering if you could give me some of the code or tell me how you do it for limiting geom speeds

is there just a _MaxSpeedPerSecond value for the geom ?
that i could set and then it would say only move at 50 pixels per second for instance

if so this would be a big help 
Feb 7, 2009 at 7:35 AM
Edited Feb 7, 2009 at 8:13 AM
@genbox: Well I figured danthekilla wanted some sort of simple method to be able to clamp the max velocity of bodies (without having to deal with gravity versus the linear drag etc.). After some thought i might implement a force clamping that way impulses won't be clamped and collision and stuff should work. I can just build the code for danthekilla if you want though. About the DNC list: if you have a faster method of doing this then i'd love to see it. i did this because it would have been really complicated to use collision categories since i needed (for proper behavior) certain objects (which are attached to each other usually) to ignore collisions between specific objects. And since i needed these objects to be able to rotate relative to each other, then i couldn't attach multiple geoms to a body... GravitateJoint: sure, fire away... i'll see what i can do. I only meant for that to be temporary because you said (somewhere i cant remember where right now) that you were toying around with the idea of adding planetary gravity and i thought this would help. BTW did i add a (working) validate function?

@danthekilla: I'll get working on this soon: you can use Linear drag for a terminal velocity but as it seems more complicated ill see what i can whip up.

EDIT: after looking at the code for updating bodies, it's too confusing for me to change in my state of tiredness... I'm also not sure that any method of speed clamping (other than linear drag) will work right. Sorry!
Feb 7, 2009 at 12:05 PM
@RCIX: So there is no way of easily limiting the speed of an object regardless of gravety?


i was hopeing for some way that i could make a simple _MaxSpeedPerSecond value and just set that to say 500 and then the geom wouldnt be able to go any faster than 500 pixels per second

thanks for you help RCIX and Genbox and thanks for giving it a go for me even if it doesnt look possible
Coordinator
Feb 7, 2009 at 2:18 PM
@RCIX: Yeah, CollisionCategories at first sight can be tricky. The samples demonstrate it good by making a collision category that can collide with some, but not all. CollisionGroups are easier but not as flexible. As I said before, collision categories use bitwise matching and they are really fast.

As for the gravitation joints, they look good, but yeah, the validation is used to check if the joint should even be processed and the like. Not a big deal as it's only a matter of moving a few lines of code. As for the idea about another gravitational field, I will contact you by mail.
Oh, have you checked your gravitation code against the planetary gravity article? (Artiche here)
One of the great things about your implementation is that even if a user has gravity set, he can still use the gravitation joints. He can even set Body.Ignoregravity to true. Very flexible.

@danthekilla: It is indeed possible. if you run your simulation at 60 fps, each update is 16,6 ms. You need the limit to be 500 in distance, so the velocity should be 30 in average. (30*16,6... = 500) Just make sure that the velocity is at a constant 30 and it will travel 500 distance.
If you want it to move slower on some updates and faster on others, you will have to make a buffer that calculates the force that needs to be applied to correct the velocity. Slow geometry needs more positive force (x or y direction) to catch up and fast geometry needs more negative (x or y direction) to slow down.
Feb 8, 2009 at 1:29 AM
@genbox: & @RCIX:  i understand the whole fps to second thing
i can just use gametime in xna to do all that

i have a top down space game that im working on
what i was wondering was if i have gravity set to 0,0
and i want the ships to never come to a rest aka have no friction
and i just add force to move the ships (which i calculate based on the current angle of the ship and contorller input)

by setting a linear drag coefficient to something like 2 or 3 or sumthing will it just cap the speed (regardless of how much force is added?)
or will it temporaly go faster than a certian speed but then slow down to its max speed and settle there or will it just keep slowing down?

also i use CollisionCategories to check collsions in the game but i was wondering why th framerate drops when lots of objects go on top of each other in the game world (even when they cant collide with each other) is this just because they all have to be checked for narrow phase collision???

Coordinator
Feb 8, 2009 at 1:38 AM
@danthekilla: The best for you would be to test a solution out by yourself. This would answer a lot of your question.
drag is just like air resistance. If you throw a ball it will slow down because of drag. So would your spaceship if you put linear drag on it. Even with no gravity.

"or will it temporaly go faster than a certian speed but then slow down to its max speed and settle there or will it just keep slowing down?"
It would temporary go faster and then continue to slow down if you don't apply a constant force on it.

As for the performance of the physics engine. It does a lot of work to figure out collisions between objects. You might want to find bottlenecks and places where you can optimize. You have to know that games are mostly made out of visual performance. This means that the game seems like it handles all elements at one time, but actually you have some of them disabled or something like that.
Feb 8, 2009 at 1:50 AM
i havent been home for a few days so havnt been able to try it out yet sadly (only have a laptop with onboard gfx with me)

as for performance i already delete all bodys and geoms from the physics simulator when they go out of the screen and then when they come back i put them back in i also cache all geom and bodys once they are made so that if i ever make the same object again it just pulls it from the cache



"or will it temporaly go faster than a certian speed but then slow down to its max speed and settle there or will it just keep slowing down?"
It would temporary go faster and then continue to slow down if you don't apply a constant force on it.

that is the problem im actaully facing i want the ship to never slow down unless the player pushes into the other direction its space so its dragless and frictionless but i want for there to be a top speed

i relise that i could add the current speed as a force every update to try to overide the slowing down by the drag but then i wouldnt have a top speed again
is there anyway somewhere in the physics system i could code an actually limit to movement speed ?? or would this take to much time to impliment?

thanks for the quick reply
Coordinator
Feb 8, 2009 at 1:56 AM
You set drag to 0. You won't need that.
Inside your Update method in your game you do this:

Vector2 topSpeed = new Vector2(100,100);
if (ship.LinearVelocity.X > topSpeed.X)
    ship.LinearVelocity.X = topSpeed.X;
if (ship.LinearVelocity.Y > topSpeed.Y)
    ship.LinearVelocity.Y = topSpeed.Y;

Now the ship will never go faster than 100.

Feb 8, 2009 at 2:01 AM
thats the code i used to use

i found 2 problems with it
it had a wierd bug where all input was being ignored (but that was probalbly something else now that i think about it)
but also that will not give me the correct speed limits will it??

i could go 100 pixels to the right or left or up or down but 14.8 (i think or 14.4) in the diagonals
which was why i needed a more complex solotion
Coordinator
Feb 8, 2009 at 2:51 AM
A quick update on the progress of 2.1:

I've added DrDeth's vertices extension to the Vertices class and wrote his demo to fit the AdvancedSamples structure. It seems to work great, but there are still a few problems that needs to be fixed before I will mark it done. Stay tuned.
Feb 8, 2009 at 4:30 AM
Edited Feb 8, 2009 at 9:57 AM
@genbox: I got your email, and i actually had a better idea: i would make a controller, but it would accept a list of bodies and/or Vector2s which would generate gravity and apply it to all of the bodies in the engine. it would allow the same settings specifications as a joint, but would apply globally. It would also have a distance disabling feature where bodies that are farther apart would not have gravity applied to them. Also, i figured out why you would want a joint version (a la Star Trek Armada 2): If you have a ship whose engines are functioning, you can park in the vicinity of a black hole without getting sucked in. But if those engines are disabled (say, by attacks) then the gravity of the black hole starts affecting the ship and it gets sucked in and destroyed. A similar thing could be done with gravity joints: you would attach a gravity joint between the black hole and the ship only when the ship's engines are offline (in a copy of the game that uses a fictional 3d version of farseer physics).

EDIT: the patch is up. See the description for details on what it changes/adds.The method that that article you recommended me seemed to use a whole different method for calculating gravity force but i will try and test it (my method) over the next couple of days. Also, i made a slight error: you need to make the PlanetaryGravityController class public before the code will work.
Initial testing has revealed that it does the opposite of what it is supposed to. I need to do more toests to fix any and all errors, so i won't be able to get back to you for a couple of days. I gotta get to bed now good night.
Feb 8, 2009 at 5:13 AM
I had an idea for another feature to be added (probably to 2.2 or later): Particle based fluid. This would provide a more accurate version (in most ways) than a drag based water, and could potentially offer a much more rich fluid simulating tool for users.  I don't know how much work this would be though.
Coordinator
Feb 8, 2009 at 1:52 PM
The discussion about planetary gravitation has been moved here: Planetary gravitation
Please continue in the thread described.
Coordinator
Feb 8, 2009 at 3:51 PM
Another Update for FP 2.1

1. The vertices union/clipping functionality is now completed. I'm not sure if I want to keep the current structure where it takes two polygons. But for now I leave it there.

2. I've also finished a sample to show off the functionality. It's based on DrDeth's original demo and still uses PhysicsSimulatorView to show the outline of the polygons, I will probably change this in the future and make the polygons filled with a solid color.

3. I've added another extension to the Vertices class. It's not possibly to create a capsule shape (like a pill capsule) using the Vertices class. Thanks to Yobiv for this extension.

4. All demos now contain borders to further simplify their implementation. Some used floors, some used borders and some had none. Now all use borders.

5. Added some checks to our factories to make sure that the referenced data is not null and contains what is expected.

That's about it for now.
Feb 11, 2009 at 2:44 PM
@genbox:
The first parameter to the union/clipping functions was only required because I implemented them as class Extensions. You could make them local methods (ie. not static), remove the first parameter and just replace where its referenced with 'this', which is luckily only once in the call to PreparePolygons. So its a fairly quick job, but there's no reason why you'd need to at this stage.

Im really hoping I get onto the Acknowledgments page... Oh, and DrDeth is spelt wrong on line 1506. ;)


Coordinator
Feb 11, 2009 at 7:07 PM
@DrDeth: Indeed. I'm just not sure if I like the static (as it is now) or the instance methods better. The static ones make more sense (Union this and this) compared to the instance ones (Union this with own). Then there is the memory to consider too. Anyway, I'll keep it as it is for the moment.

As for the acknowledgment page, you are indeed going to be on that page. I've written down all our "major" contributors down on a list to be included when FP 2.1 is done. Oh, and I'm sorry that I spelt your nick wrong. Thanks for the correction.
Feb 15, 2009 at 3:20 AM
I noticed that your Texture to Vertices code violates a number of CLR guidelines. I was wondering if you could wrap it up into a function that takes a more CLR friendly format or just directly extracts vertices from a texture.
Feb 16, 2009 at 5:56 AM
I just had a thought... After that soft body sample is made i might look at making a SoftGeomFactory and a SoftGeom class where you feed in lists of Vertices and you get back a Softbody object that contains a list of the required geoms and the springs/joints/etc (for easier manipulation). On a site note: not to seem petty or anything but will i be on that contributors list? :)
Feb 16, 2009 at 7:57 AM
@genbox:
Hehe - I'm not to worried about it, though the creds are nice.

@RogueCommanderIX:
The SoftGeom classes sound like a pretty cool addition. Give it a go.


Feb 17, 2009 at 2:57 AM
@DrDeth: well pending an explanation of how soft bodies are made, i am planning on whipping up a soft geom factory thing.
Feb 25, 2009 at 8:29 AM
Edited Feb 25, 2009 at 8:30 AM
If you don't mind, could i rewrite the linear spring code to make more sense to those game developer newbies out there? I had a hard time understanding what exactly was the process for calculating a spring force until i disassembled the code and reassembled it in a more understanding friendly fashion. i might look into the angular spring while i'm at it.
Coordinator
Mar 17, 2009 at 12:45 AM
Update on our progress:

In progress - Raycast helper
I've just uploaded a sample (AdvancedSamples demo #9) on how to use the CollisionHelper included in Farseer Physics 2.0. I'm going to extend the functionality of this class in the next few days.

In progress - Modular narrow phase
Well, this is a tricky thing. We would like to keep the current narrow phase (distance grid) to make sure that our users have the possibility of switching back. The problem is that the current design of the engine does not let us do that easily. The communication between narrow phase and the engine needs to be unified. Matt is working on it, but he is short on time, so we might have to wait a little.
We have been thinking about removing the old narrow phase, but this would also remove support for concave polygons. It is possible to create concave polygons with the SAT algorithm, but that would require an algorithm that splits up a concave polygon into multiple convex polygons.

In progress - More code documentation
I've talked with some people on the forums about what places needs more documentation. It's obvious that the physics properties needs (more) documentation and I will do my best to explain it in terms easy understandable by new users.
In progress - Support for multipolygon textures
Sickbattery is working on this one. He was the one that provided the texture-to-polygons functionality in the first place, but he wanted more than just mapping a single texture. Hopefully he will get it done soon so we can include it into the engine.

----
We have also been fixing some bugs and simplified our samples both be more effective but also easier to understand.
Thats it for now.


Mar 17, 2009 at 1:00 AM
thank you for the update i am very excited to see these updates in the next version, it makes me very happy to see you guys still working on farseer.
2 things
for destroyable geometry does that meen what i think it meens?
and for the multipolygon textures how would that be utilized?
Mar 17, 2009 at 1:24 AM
Keep up the good work guys!
Mar 17, 2009 at 2:09 AM
this sounds auwsome
is there anything different abouthe new narrow phase
does it have any other features or is faster
whats the reasons for implimenting it?
also is there any news on continuous collsion detection
Mar 17, 2009 at 3:00 AM
@TLegion:
Yes it means that the geometry wil break up into chunks (i think) if you want it to,
and the multipolygon textures means you can feed in a sprite sheet and it will provide separate geometries for each sprite in the texture.

@danthekilla:
Well i think the new narrow phase is being made for the same reason that there are more than one broad phase methods: they will work better in different situations. Also, CCD is coming in 2.2, not 2.1.
Mar 17, 2009 at 4:21 AM
my game would be based off of just that hahaha
i would overuse that to the max and then some

And thats what i was hoping the multipolygon texture meant, although currently i think you can do it but it would take updating quite often and would be quite costly for performance, in theory.
Mar 17, 2009 at 5:13 AM
@TLegion: huh? i think the multipolygon textures are an extension of Texture to vertices. BTW, you never mentioned what kind of game you're making. what kind is it?
Mar 17, 2009 at 5:55 AM
Edited Mar 17, 2009 at 5:56 AM
i do not know haha
its quite frustrating as i had all these ideas about games i wanted to make before i started game devolopement, and now that im actually able to try im drawing a blank.
I think its sort of out of fear that i wont be able to do my crazy ideas i used to come up with,
but anyway, i was referring to the texture to vertices. I was saying you could do that now with text to verts but it would be alot of work and costly on performance.

Although the process for doing it is quite simple.
Mar 17, 2009 at 7:24 AM
Yeah you're probably right.
Coordinator
Mar 17, 2009 at 12:48 PM
@danthekilla: The new narrow phase is based on separate axis theorem (SAT) and should be a lot faster than the current implementation, but we can't say for sure until we actually benchmark it.
What makes the theorem faster is that it only works on convex polygons. This also means that no concave polygons is allowed inside the narrow phase. To fix this we have 2 choices: No concave polygon support (like most other engines) or create a polygon disposing algorithm that splits the a concave polygon into several convex polygons.

@tlegion: as RCIX said, it's for splitting up a geometry into several smaller geometries. I'm unsure if we are going to implement a fast chunking algorithm for use in the new narrow phase and just use that. Or if we are going to implement both the fast chunking algorithm and a triangulation algorithm that will split up a geometry into small triangles.
I will talk with Matt about this.
As for the multitexture to polygon functionality. Sickbattery is working on it and he has come up with a great algorithm that finds outstanding polygons. I'm not sure how the new algorithm will work and the efficientcy of it. As I understand it he is very close to a final solution. I will contact him and ask about an ETA.
Mar 17, 2009 at 8:12 PM
great!
one thing though, if it were to be used with spritesheets, would their be a destination rectangle sort of thing for geometries like their is in the draw method?
Mar 17, 2009 at 9:27 PM
very cool!
i'm really looking forward for the raycasting and documentation update.

btw: which collision resolving technique does Farseer actually use?
Mar 17, 2009 at 10:10 PM
@TLegion: im pretty sure you get back a list of geoms that you can use with the spritesheet.
@Yobiv: if you mean narrow pahse, it uses someting called Distance Grid. Don't know much about it myself.
Coordinator
Mar 23, 2009 at 9:33 PM
Good news everyone.

I managed to decouple the narrow phase collider design by changing the distance grid (our current narrow phase) to store distance grid nodes in a different way. This finally gives us a perfect platform to incorporate different narrow phase colliders.

Even better! Matt has created a working SAT (Separate Axis Theorem) implementation. I just tried it myself and I'm really happy with the results. It still needs some cleanup and it needs a benchmark to see how good it performs.
I'm really looking forward to see final implementation. I'm also very exited about the new narrow phase design as it provides our current users with some backwards compatibility without sacrificing anything. Hope you like it as much as me ;)
Mar 23, 2009 at 9:47 PM
Sorry to ask as it may be obvious, but what would be the advantages of the updated narrow phase and the SAT?
More importantly what does SAT do?
Mar 24, 2009 at 12:01 AM
@genbox: Thats great to hear! i tried it myself a day or two ago and i like it.
@TLegion: Well as i understand it using SAT will allow you to skip the large pre-computation cost for geoms but it might run slower than the current implementation. Well as i understand the theory of SAT, you check the 2 geoms in question to see if they overlap along each axis (which in this case, there is one axis for each "face" normal on a geom) and if you can find an axis where they don't overlap, then the two are not colliding.
Mar 24, 2009 at 12:29 AM
SO it runs slower?
Im sorry but that doesnt make sense,
it skips alot of the work but its not as efficient?
Mar 24, 2009 at 1:06 AM
Well im not sure but it might run just a little bit slower while in use, but the advantage is that you can skip the big initial cost (with the current narrow phase code) of calculating a distance grid which can get quite large especially for big geoms.
Developer
Mar 25, 2009 at 1:03 AM
@tLegion: SAT is faster or slower then the current distance grid method. It does however eliminate the slow and costly creation of the grid before you could use the geometry. So the real benefit will come from people wanting to to real-time geometry deformation and creation. Once I complete the implementation I will release demos that display this awesome power. Could be useless for some people, could be the best thing ever for others.

For anyone wanting to check it out just download the latest source and open the SpecialBraches folder and run FP2.1SAT.

Also currently SAT is performing better than the broad phase with absolutely no optimizations. So hopefully I will be able to get it way faster when I am finished.
Mar 25, 2009 at 3:59 PM
Hooray regarding the SAT implementation! :)

Does this mean static line collision shapes will be possible (like typically wanted for a platform game)?
Mar 25, 2009 at 5:38 PM
ALL you had to say was it advanced the aspect of deformable eometry and i wouldve mindlessly supported it haha.

I cant wait for the demo im so excited to see some new features put in action, also ill be able to learn from the demo and get started using it.
Mar 28, 2009 at 5:54 PM
Can't wait for the demo.  SAT sounds great!
Mar 30, 2009 at 11:19 PM
Fantastic news, guys! I'm really looking forward to trying the new SAT implementation!
Developer
Apr 4, 2009 at 10:48 AM
Hey there,

I know, some time passed since I wrote my last post here but as usual ... I somehow didn't find the time, didn't have the motivation or my gf was here (what ever, you sure don't care). ... but I actually have got good news for you guys oO. I've got myself some vacations (two weeks) and I'll have some more time to work on "my" farseer part. I also already did and I have some new results. Maybe I'll post a video later on because I have code that is now able to create a polygon with holes.

Yeah, I already said that once and I wasn't lying, I just thought that the jump from creating one hole in a polygon wouldn't be that different from creating some holes in a polygon oO. I got proved wrong -.- ... and that's what made it a bit complicated and stole me some motivation to work on it again.

... yeah, I'll post again when the vid is ready. This might take some time because I want to do some other things before working again.

Best Regards,
sickcahos.
Apr 4, 2009 at 8:30 PM
THats great!
It will com ein very handy, even just the poygon with one hole
Developer
Apr 4, 2009 at 9:40 PM
Edited Apr 4, 2009 at 9:42 PM
Hehe :). I'll work on this on monday again. For now you might want to see this:
http://www.youtube.com/watch?v=aph0mFdVc9Y
Apr 4, 2009 at 10:57 PM
That looks great, the extra detail wouldnt be a problem in functionality though right?
Would it just make it do more than it needed and cause efficiency issues?
Coordinator
Apr 10, 2009 at 3:57 PM
Edited Apr 10, 2009 at 8:22 PM
Good news, everyone! (Futurama - for those who know it...)

I've just implemented a new broad phase collider into Farseer Physics. It's a rather simple method called Spatial index (Spatial hashing in this case) that groups together geometries in an area that have the potential of colliding.

I made some performance tests on the new broad phase algorithm, and it looks promising.
Here is the results of testing 1600 geometries against each other on my 8-core Xeon 2.33 server with Geforce 8800GTX:

1600 geometries idle:
BruteForce: 71-75 ms
SweepAndPrune: 0.6-0.7 ms
SelectiveSweep: 2.9-3.0 ms (Default collider in Farseer Physics)
SpatialHash: 1.8-2.0 ms

1600 geometries moving:
BruteForce: 75 ms
SweepAndPrune: 2.8-3.2 ms
SelectiveSweep: 2.9-3.1 ms (Default collider in Farseer Physics)
SpatialHash: 2.0-2.2 ms

As you see, it has good rather good performance in all cases. The tests are not definitive and should never be treated as such.
You now have another option for broad phase detection. Try it out by switching to it like

PhysicsSimulator.BroadPhaseCollider = new SpatialHashCollider(PhysicsSimulator);

Note: It will appear in Farseer Physics 2.1 - until then you will have to download the latest snapshot of our 2.1 development tree.

Apr 10, 2009 at 5:20 PM
Haha i get the reference, i wouldnt have if you didnt say it was futurama tho
But anyway
that sounds and looks great(im not sure how great it is actually but I will take your word for it)
Will the stable release of 2.1 be soon?
And will destroyable geometry be touched on in 2.1?
If not i assume there is a complex way of simulating it in the current release
Apr 11, 2009 at 9:16 AM
Wow... i'm impressed. Sounds good! However; when is anyone gonna see 1600 geometries in any one game (excepting maybe an expansive overhead space shooter)? It's good though that you have a broad phase collider that will handle stress well.
Apr 11, 2009 at 6:10 PM
Edited Apr 11, 2009 at 6:10 PM
a game with all destroyable geometry?(a boy can dream)

edit: Maybe if you include all the levels haha i dunno
Developer
Apr 12, 2009 at 5:36 AM
I'm shooting for a finished SAT implementation by the end of summer, but don't hold me to that to hard. The finished implementation will include examples including -

Real Time Geometry Deformation
Real Time Geometry Destruction (Shattering)
Real Circles
Line Segments

and not SAT related but still on my list for release with SAT -

Fake Soft Bodies


As for using 1600 bodies in a game,  I'm sure once I get my destroy-able geometry working I will be able to touch that number. Remember my goal is a narrow phase that is just as fast as the broad phase. So if Ian's SpatialHash is getting 2 ms, which is outstanding by the way, then I am shooting for 2 ms as well. Set your goals high lol
Apr 12, 2009 at 7:36 AM
*drool* i would *love* to have some of that. I hope you'll get it done by then, but we'll understand if you don't....
Apr 14, 2009 at 7:02 AM
An idea i had (that i use in AtomPhysics) is to add a geom.IsSoft property that, when on, will switch the engine from using impulses to fix collisions to using forces. It works well for my engine, it might work for you!
Apr 14, 2009 at 7:18 AM
@Matt.... DROOL! I really can't wait.

One question: Will SAT include support for auto splitting non-convex geoms?
Developer
Apr 14, 2009 at 10:41 PM
@roonda: Non-convex, or concave geoms will be supported as well as real circles and line segments.

@RCIX: I'm not sure Farseer uses the same methods as your engine, but I will look into it. I was planning on possibly just writing another ComplexFactory to build "soft" shapes. I'm sure I won't get around to it for awhile, but it is on the burner.

On a side note, has anyone here played with SunBurn from Synapse Gaming? I just picked up the Indie license and have been playing around with it a little. I'm going to try an use it in my game do out in April of never. Anyway, if anyone has used it please let me know your comments. I think it's bad ass.
Apr 14, 2009 at 11:45 PM
Nope havent tried it. I kinda wish i could, but i am not particularly inclined to do any 3d work (its too hard for my simple brain :D).
Apr 17, 2009 at 12:06 AM
I've been umming and aaahing about getting Sunburn for a while now. The Indie edition is pretty damn cheap. I'd be interested to hear more of your opinion about it Matt. One other thing too... If I grab the latest checkin, how do I enable SAT and does it already support concave polys?
Thanks!
Developer
Apr 17, 2009 at 12:24 AM
@roonda: SAT is still not finished and no concave polys yet.

About SunBurn, please send me messages directly at mattbettcher@gmail.com as I don't want to riddle Farseer's forum with SunBurn talk. Also, I will probably create an example that uses SunBurn and I'll start a new thread and post it up so everybody can take a gander at it.
Coordinator
May 2, 2009 at 11:01 AM
Update:

The following items has changed status:
  • Almost done - New narrow phase algorithms
  • Almost done - More checks in code
  • Done - Raycast helper
The SAT narrow phase algorithm is still getting its final tweaks by Matt. The checks in code is few in numbers, but they make sure that values stay within a sane range. The raycast helper just got a few tweaks. (I have not uploaded the final version yet tho).

Hopefully we can get 2.1 out of the door soon to start working on future versions.
May 2, 2009 at 7:21 PM
AWESOME,
looking forward to the raycast helper
Developer
May 11, 2009 at 8:53 AM
Edited May 11, 2009 at 8:54 AM

Update on 'Support for multipolygon textures' (and most important of all :P ... holes in textures.)

 

Hey there,

my hole detection algorithm finally works (multi-hole) - with some limitations because of the lossy compressed data I have to work with (polygon instead of the texture data, to speed up).

As you might know you can set the max distance between a polygon's edge and the graphic's edge (HullTolerance). Well, this distance is the minimum distance for hole detections inside of the polygon (irony: Who would have thought that, huh? error: I searched for the distance only on the x axis and not for all polygon edges in all dimensions -.- ...stupid me). This means, if you have a hole inside a graphic and it's at no point further away then HullTolerance then this hole will not be detected.

I know I have to be careful what I say about the completion of this :) ... but I have a good feeling that this (with multi-poly) will be finished at the end of this week (hole detection = 'hard' part + I have no other intentions this week).

(I thought I should post to give a sign of life o_O)

Coordinator
May 11, 2009 at 4:53 PM

Hey, you are alive! Good to hear from you again sickbattery.

Never been quite comfortable with the whole hole-tingy, but let's see how it turns out. :) when it arrives that it.

Developer
May 12, 2009 at 10:45 PM
Edited May 12, 2009 at 10:46 PM

Here, take a look ...

http://www.youtube.com/watch?v=N0pJMlTb7ao
(it might be still processing for HD, be patient)

The "over detection" that happend in the previous version doesn't happen anymore.

K. Now I've got to go to bed oO.

Coordinator
May 12, 2009 at 10:51 PM

Arrgh, hahaha. Sickbattery, you are two kinds of crazy. Screw Guitar Hero 3 ;)

Nice video tho!

I can't wait to see what you have come up with. Hopefully you will have a working version for us to look at soon :)

Coordinator
May 12, 2009 at 10:59 PM

Update on progress.

I have some good news for you. Matt has been working hard on Farseer Physics lately and he has even done some of the stuff that was set to be in 2.2. Take a look at the updates:

  • In progress - Weld Joint
  • In progress - Gear joint
  • In progress - Ragdoll sample
  • Almost done - XNA Water sample

Matt has been working on the weld and gear joint. He is also working on some demos to show how they work. I've been working on a ragdoll sample and the XNA water sample. Matt did all the rendering on the XNA water sample and has even rewritten parts of drawing system in the samples to make them more flexible and give them better performance. If you have any thanks to give, send them to Matt for his great work!

The final change list will contain all the changes and notes. This list is only describe the main changes in the engine.

May 12, 2009 at 11:36 PM

AWESOME to both posts

i loled at your video sickbattery

the scribble was an edge of my seat white nuckle ride,

it was wayyyy intense, it was god damn amazing

Howd u do the data visulation? Add a new vert each update call and draw each new vert?

And that stuff looks great genbox, what will those be used for(gear joint and weld joint)?

May 14, 2009 at 3:29 AM

This all looks great

nice work everyone
i have played around a bit with the water sample a bit ive been fiddling with a shader to render the look of it better (aka foam, transperacy, warp effect for whatever is under it, etc..)

nice work all around thou

also holes in textures looks like its coming along very well cant wait to see it in action with some geoms rolling around inside a larger object (which i assume will be possible)

Developer
May 15, 2009 at 2:19 AM

@tlegion: The weld joint allows to bodies to be fixed together. Sample is now in the source code - SimpleSamples - check it out. Gear joint isn't working like I planned so it's being dropped for now. instead I have added to the Vertices class some very usefull gear shaped geom making methods, also in the sample.

 

@danthekilla: Be sure to post up your results. I wanna see the water with a good shader!!!

May 15, 2009 at 3:04 AM

@mattbettcher: i love the weld joint looks great the gear joint is amazing in the sample it works just like a real gear i thought but yer nice work anyways also i will post my results and mabey a video of the water shader in effect hopefully sometime next week on youtube or something i hit a little problem with it so now im trying to make good rope in farseer any help would be great lol

Developer
May 15, 2009 at 5:06 PM

@danthekilla: The weld joint is pretty handy. The gears are acutally not connected with a gear joint. It wasn't working like I'd hoped so I just tried it without the gear joint and it worked great. Hopefully someone will find a place to include gears in project.

 

To make a rope I use revolute joints. The key is getting everything placed just right so it dosen't explode when the simulation starts. Can your rope start vertically? If not then try to use the Path class to get it working. It takes some fiddling to get it perfect but it will save you tons of time.

Coordinator
May 17, 2009 at 12:53 PM

Updates:

  • In progress - More code documentation

I changed this from done to in progress. I've been looking at the code, and there are still areas that needs documentation. This of course, is an ongoing process throughout the project lifetime, but I want to make sure that most of our code is documented.

  • Done - Weld Joint

Matt has finished the WeldJoint. It's basically a joint that hold together a bunch of geometries. He has also created a sample to show it off.

  • Almost done - New narrow phase algorithm

The SAT implementation now resides in a special branch of Farseer Physics along with the decoupled narrow phase design. I'm going to move this implementation into the main Farseer Physics branch and test it out.
Matt has some ideas on improvements and extensions to this implementation, but they will first be avaliable in FP 3.0.

  • Almost done - More checks in code

I've created more checks in code and thus fixed some bugs. Some bugs prevented the engine from cleaning up after itself properly and others slowed down the engine by calculating forces on disabled bodies. The checks improved performance in some cases and should make the engine more stable.

  • Discontinued - Gear joint

Matt worked on the gear joint, but it did not work out as he had planned. We discontinue the gear joint until further notice. A bonus that came with this, is that gear functionality has made it way into the vertices class.

  • In progress - Ragdoll sample

Because of time, I've not yet finished the ragdoll sample. Sorry about that, but exams comes first :)

  • In progress - WPF Simple samples

One of our users (MattF) has created the simple samples in WPF. They are still work in progress, but should be finished when 2.1 comes out. Thanks to MattF for his great contribtution.

 

May 20, 2009 at 2:10 PM

your welcome :)

May 22, 2009 at 8:32 AM

There seems to be quite a bit of demand for the ability to have nonstatic geoms that only sense collisions, so perhaps this could be added  to the todo?

Coordinator
May 22, 2009 at 6:13 PM

It is already possible. Set the EnableCollisionResponse to true on your geometry and it will not react it the surroundings, but still detect collisions.

Developer
May 23, 2009 at 7:04 PM

Done.

Genbox, you might want to send me a PM with your email addy again :). Wanna see a pic ^^?

Coordinator
May 23, 2009 at 7:07 PM

Looks great. I've send you my email again. :)

Developer
May 23, 2009 at 7:11 PM

Now that was a quick answer :D ...

I'll send you the dirty version, without comments and anything, for testing only. Don't implement it :).

Coordinator
May 23, 2009 at 8:43 PM

Time for another update.

  • Done - More checks in code

Finally finished this one. It adds more stability and minor performance enhancements to the engine. An example: Don't update joint logic on disabled and staticbodies (only if both bodies are static or disabled).

  • Almost done - Support for multipolygon texture

sickbattery has finished his algorithm for converting textures into vertices (polygon shapes). I've tried it out and it seems to work fine. I used the texture from AdvancedSamples Demo #4 to test it out. I switched on hole detection and it found the hole aswell.

Thanks to sickbattery for this great contribution!

Coordinator
May 27, 2009 at 6:08 PM

Update

  • Done - More code documentation

We have done a lot of documentation in the current code - but as I've said before, it is an ongoing process.

  • In progress - Water simulation documentation

Matthew is going to work on the water simulation documentation in the manual. Hopefully we can get more people to use fluid dynamics by giving them a better understanding of how it works.

  • Almost done - New narrow phase algorithm

Matthew is putting a last hand on the SAT implementation. He has informed me that it is very close to being finished.

  • Done - Ragdoll sample

We now have a very simple ragdoll sample using pinjoints only. It's in no way a high quality ragdoll, but it's fun to play with.

  • Almost done - Support for multipolygon texture

Sickbattery has send me his newest implementation of his multitexture algorithm. He has already begun working on a new algorithm. But, since it's not tested and only an idea at this stage, we decided to include the implementation he send me by mail, and perhaps include the new one in a future version.

  • Done - XNA Water sample

The sample is a little unstable and could use some polishing - but it works. Matt even created a fast renderer for the waves to demonstrate how that works.

  • Done - WPF Simple samples

MattF has send me our Simple sample in WPF. I'm going to include it as a separate platform into our code tree. Thanks MattF.

----

As you probably have figured out, we are very close to a release of 2.2. We think it will be ready for release within a few weeks, so stay tuned.

 

Coordinator
May 29, 2009 at 11:41 PM

Update

  • Done - New narrow phase algorithm

SAT has been implemented in the latest checkin. (#53208). Not everyday you see a physics engine with different narrow phase algorithms ;)

  • In progress - Auto-divide geometries

Matthew is working on getting this into the engine. It is the very last thing on the 2.1 todo list before we update documentation and the like.

Coordinator
May 31, 2009 at 12:48 AM

Update

  • Done - Support for multipolygon texture

Thanks to sickbattery we now have a new algorthm to convert texture to vertices. It supports multipart detection (multiple images in same texture) and holes. It still needs some cleanup and a lot of documentation - It might also change API before release to make it easier to use. (as easy as the old version).

  • Done - Auto-divide geometries

Matthew has included an AutoDivide class to help you split up geometries into several geometries. Why is this needed you ask? Well, in some cases it will improve performance and it is needed if you use the SAT narrow phase collider and want to use concave polygons. Matt has also included Demo10 in the AdvancedSamples project to demonstrate how it works.

 

We are close to a release and info about the next release (3.0) will come out soon after 2.1 is out of the door.

May 31, 2009 at 1:04 AM

Hey genbox I was wondering if you could give me an idea of how to do this

I have made a nice simple car for the car sample (and I am using the polygon brush and stuff to draw) and that works well
I have made a pretty simple bridge for it to go over

the problem I am having is I want to make a simple kind of camera without changing too much in the sample code but it also has to be easy enough for people to understand

the problem is to see a car work properly I can’t do it all in one screen worth of space I have to move the camera a bit
This is what is looks like right now http://i42.tinypic.com/2lcllvk.jpg (there’s a bridge about a screen onwards that kind of works right now lol)

now at the moment I am just using the cars x pos as the camera pos and I am just going Ground.Draw(Spritebatch, CameraOffset) to make everything scroll
the problem with this is that when F1 is pressed obviously the debug view is off by a lot

I can fix this by just using a matrix based camera and passing that to my sprite batch and then drawing the debug view also within that.


Is this what you would do or is this too complicated for the simple sample?

Coordinator
May 31, 2009 at 1:10 AM

Just include the camera into the samples too. We have a lot of samples showing how to use Farseer Physics, maybe a simple camera will also help some people understand how to use a camera (and drawing in XNA in general).

Looking forward to see the rest. (rest of what's seen on the picture that is)

May 31, 2009 at 1:20 AM

@Dan: try this (http://farseerphysics.codeplex.com/Thread/View.aspx?ThreadId=50483) thread for a highly featured and simple to use camera.
@genbox: you're welcome to use my camera class!

May 31, 2009 at 1:23 AM

I already have a camera that works pritty much the same as that.
i will intergrate that i think and mabey merge some of yours in

ill post something up in a few hours showing my progress

Coordinator
May 31, 2009 at 1:27 AM
Edited May 31, 2009 at 2:10 AM

@RCIX: I’ve seen your thread before, it seems to be a very nice and simple camera.  As Dan wrote, he has already created a camera with some of the functionality created by you. I will write in my TOOD list that a link should be made to your camera thread, to be included in the tutorials section (under non physics related stuff).

 

May 31, 2009 at 2:06 AM

Regarding the AutoDivide class, would it be necessary to try to detect whether an arbitrary polygon geometry (say, one entered by the user in an editor) needs to be auto divided, or will the AutoDivide class do nothing if the geometry is already completely convex?

Coordinator
May 31, 2009 at 2:16 AM

The AutoDivide class has to be run manually for the moment. It is needed if you have concave polygons and want to use SAT. We will be looking into incoorprating it in such a way that the engine automatically detects concave polygons and auto-divide them. Depending on the time, this might be implemented after 2.1 has been released.

See Demo10 in the advanced samples for more info.

Developer
May 31, 2009 at 3:28 AM
Edited May 31, 2009 at 3:32 AM

Auto-divide is currently manual for right now. I'm looking to add Approximate Convex Decomposition and to make it truly "auto". Basically, I'm looking at adding a flag to the Geom methods somewhere to enable/disable auto-divide.

@JeroMiya: Currently Autodivide will split any set of vertices into triangles. Soon this will improve. However it does seem to work great with SAT, allowing concave polygons to be easily broken into triangles.

May 31, 2009 at 8:48 AM

a bug: but you seem to get odd results when pressing enter in the polygon operations tutorial when you have 2 separate geometries in it.

Developer
May 31, 2009 at 12:07 PM

@RCIX: Got your bug covered in the other thread. http://farseerphysics.codeplex.com/Thread/View.aspx?ThreadId=57641

Jun 4, 2009 at 4:47 PM

can you add the CreatePolygonTexture in the drawing System.

Thanks

Coordinator
Jun 4, 2009 at 4:53 PM

@nidall: Instead of creating a texture that contains a polygon shape, we decided to include PolygonBrush that draws polygons using lower level functionality.
PolygonBrush.cs will be included in the sample projects and everything you need to draw polygons should be in that file.

Coordinator
Jun 5, 2009 at 12:08 AM

Update:

We got some great feedback from our testers (Thanks a lot, to all of you) and we have fixed a lot of bugs. The only thing we are waiting for is some very last finishing touches and some final contributions. Then 2.1 should be out of the door.

Jun 5, 2009 at 3:31 AM

Hi Are you planning to enable the vertices subtraction to cut a hole in the middle of a shape? Cause that would be really great to have :) btw Its excellent that the polygon from texture does that.

Coordinator
Jun 5, 2009 at 1:36 PM

Short answer:

No, we are not planning on developing such functionality.

long answer:

We try not to be a computational geometry framework of sorts. We think it is important that our users have the tools to create dynamic simulations, but adding all sorts of tools to manipulate polygons, just because they are handy, is not our main goal. The main goal is to make stable, dynamic and high performance physics that is easy to use.

But that is the more general stuff, as for the whole hole business - I'm not to fond of holes since they go in the oppersite directions of how this engine was built. I agree that holes in polygons by far is the easiest thing when it comes to userfriendliness, but it's the worst when it comes to engine-friendliness.

All geometries have an AABB that surrounds the geometry. The engine uses this AABB to check if other geometries are near by, and if they are, we do all the expensive calculation stuff on the geometries. Adding a hole in a polygon and inserting another polygon into that hole would make it so that all the expensive calculations runs - all the time...
It's not too bad with one polygon in the hole, but adding a lot more will make a severe impact on performance. It is a lot more engine-friendly to compose the polygon from several smaller polygons that looks like the big polygon with a hole.

This is by no means a no - If someone contibutes code that does excatly that, I can certainly add it. Don't get me wrong, but the could could come in handy and it has not moved our focus away from our main goal.

Jun 6, 2009 at 7:10 AM

About that polygon brush: How do i use it with an existing matrix? i need to be able to apply a matrix to it that specifies my cameras rotation, translation, and the like.

Jun 6, 2009 at 8:00 AM

                          Quote:   "Nidall: can you add the CreatePolygonTexture in the drawing System."


I also think that this would be a great thing to add.
There are many times when i could see this being usefull.

Just thought i would let you guys know that there is some intrest in this.

As much as i like the brushes im having some trouble getting them to work with my camera

Developer
Jun 6, 2009 at 1:22 PM

@RCIX: I can add another Draw method that takes a Matrix instead of a position/rotation. I'll bust it out right now and add it to the source code. As for the other brushes they don't behave the same way, of course the PolygonBrush can replace them all ;)

Developer
Jun 6, 2009 at 1:37 PM

@RCIX: I added it to the latest source code. Please try it out and let me know how it works out.

Jun 7, 2009 at 9:16 AM

Nice start but i had two problems:
 * i had to do some hacky matrix stuff to get the body drawing in its proper position, could you add a Draw call with both the matrix, the position, and the rotation?

 * It looked fine until i had two geometries coolide with each other then they spiraled off in opposite directions of where their debug geometry went (which is drawn via calling spriteBatch.Begin with the camera matrix)

Developer
Jun 7, 2009 at 2:14 PM

@RCIX: Are you using the same camera that you posted up for everybody? Also seeing what hacky stuff you had to do would help greatly in unhacking it ;)

Jun 8, 2009 at 8:00 AM

Yup same camera (i've tweaked it a tad since then but nothing that would affect this). In order to draw the object at the proper position/rotation i had to feed the following matrix to the draw call:

Matrix.CreateTranslation(body.Position) * Matrix.CreateRotation(body.Rotation) * camera.CameraMatrix
this gives me an idea... i think i got the position and rotation matrices backwards. I'll swap those but it would be nice to be able to feed in a position, rotation, and a camera matrix and let it do the heavy lifting.