[CLOSED] - Farseer Phsyics Integration - Any pointers?

#21 Hey Ron,

if I remember correctly the loader processes the objects sequentially so you should edit the scene file and inverse the order (or create them in the editor in the proper order).

Cheers,
Pino

#22 @Pino...thanks for the advice, my friend. I've removed the dependency and added them in the reverse order that I need them to initialize. Pretty sorry solution...but I guess it will suffice for now so I can focus on the integration.

;)

--RB

#23 @Ron:
This is what I do in these cases (another ugly one): I implement a deferred and controlled initialization. The dependent component upon post registration checks if the main one is there; if it's not it does nothing and at the first other call checks if it's properly initialized and if not it performs the init again. It's not elegant but it works fine ;)

~Pino

#24 Okay all...I've been working on the integration, and while it's still in early stages, it seems to work fairly well. My inexperience with the engine may prompt some bad design decisions, but so far things seem to be working as one would expect.

In a nutshell, I've created a few different classes:

FSPhysicsSwitchboard: This is basically a wrapper to ensure that all scene objects using Farseer physics components are all part of the same physics simulation. It gives a handle to the game's PhysicsSimulator instance and provides an access point to manipulate the gravity vector.

FSBodyComponent: This is a component that turns a SceneObject into a Farseer Body...bodies have mass, but no substance. They are affected by gravity, velocity, forces, and torques.

FSGeomComponent: This component gives a body substance. It makes the body respond to collisions with other substantive bodies. This system supports 32 categories of objects (similar to TX2D's object types). The objects can be categorized to collide with one another, but I have NOT yet exposed object categorization to TXB.

FSPhysicsManagerComponent: This component would be attached to a dummy body in any given scene. It is used to set the gravity for a scene (via the switchboard class). This component has very little functionality, but it does give an in-game access point (including tick processing) to manage the gravity.

Those are the basics. Other than that, I've implemented a component for each different type of Joint object that is supported in Farseer. In Farseer several joints come in a Fixed and "dynamic" variety. Fixed joints typically apply to only one body, while dynamic joints apply to 2 bodies. For the components I've implemented, there's a "IsFixed" boolean and a "Body" property that is a SceneObject. In the case where the joint is fixed, the body element is ignored. For dynamic joints, Body1 is the SceneObject to which the component is attached, and Body2 is set according to the value stored in the "Body" property. Clear as mud? =P

Beyond this are the actual entities that create connections, forces, and resistances among the objects. More on that in my next post.

--RB

#25 For all of the joint types, I've exposed public setters/getters for the type-specific properties, but there are still properties of the base Joint class (an abstract class) that I have not exposed public accessors for (so far, I've not seen a need...but I'm certain one will arise).

While Farseer works using (obviously) radians, the accessors I've exposed to TXB use degrees and a conversion utility sets the proper radian values into Farseer.

FSAngleJointComponent: This component serves to provide the functionality for both the FixedAngleJoint and AngleJoint classes in Farseer. Basically this joint, in Fixed mode, holds a body to a set angle. In the dynamic, case the joint holds bodies to a set angle off one another, so a value of 90 degrees would ensure that the 2 bodies remain rotated 90 degrees apart from one another.

FSAngleLimitJointComponent: This component handles the functionality for both the FixedAngleLimitJoint and AngleLimitJoint classes in Farseer. Basically it works the same as the FSAngleJointComponent with the exception of the fact that it supports a high and low angle range instead of a scalar value.

FSRevoluteJointComponent: This component serves to provide the functionality for both the FixedRevoluteJoint and RevoluteJoint classes in Farseer. Basically this joint, in Fixed mode, holds the body to a set position, but allows free rotation. In dynamic mode, it allows 2 bodies to rotate relative to one another but keeps their relative positions fixed (I believe this to be true, but again...I don't have much experience with Farseer short of this integration).

FSPinJointComponent: This joint is always dynamic. It does not have a fixed mode. It represents the PinJoint in Farseer and basically keeps 2 bodies a specific distance from one another, but allows independent rotation of each body. Think of this as an axle between 2 wheels; you could pick up one wheel and the other would stay on the ground until you raised the first wheel higher than the length of the axle, at which point the other wheel would also come off the ground.

FSSliderJointComponent: This joint is also always dynamic. It represents the SliderJoint class in Farseer. It works pretty much the same as the PinJoint only it allows a high and low range of distance between the 2 bodies.

The next step will be for me to do the work around springs. Basically these are similar to joints only bouncy. =P

There are fewer spring types than joint types, so I suspect I'll only have to implement 2 more components (2 different spring types) and each component will funnel both the fixed and dynamic spring types.

I have things working fairly well, but I don't think it's worth posting as a resource yet. I'm concerned that not having exposed accessors for the base Joint and Spring classes and the fact that I've not yet implemented the collision categorization might limit the usefulness of the implementation as part of an actual game. Right now, I'm mostly in proof-of-concept mode.

Oh...by the way...to Henry's point...this would serve as a replacement to T2DPhysicsComponent, it would not work well in conjunction.

I'll provide updates as ready...
--RB

#26 Well Ron looks you are advancing and way ahead of me (I haven't even started!) If you are ok with sharing it this could be a great addition to our SVN repo ;)

#27 @Pino...I would love to see this in the SVN repo. Do you want it in its current state or do you think I should continue with the springs, collision categories, and base/abstract class accessors?

It would also help for me to add some code comments. When I'm working at this pace, I have a tendency not to follow particularly tight commenting guidelines. :)

BTW...this implementation has been done using the 3.1.4 repo, but I haven't made any changes to the TX code, so it shouldn't be hard to implement this in 3.1.5.

If you'd like, I can email you the components directly, and you can get them integrated with 3.1.5 in the online repo. It will also require a download and inclusion of the FarseerPhysicsXNA project.

Let me know what you'd prefer, and I can get the code over to you.

Thanks
--RB

#28 @Ron: thanks a lot :) if you send it to me I'll see at implementing it into the engine.

Thanks!
Pino

#29 @Pino...I've sent you the work I've done so far. I should have a few new classes tonight. I'll zip those up and send them as well when they are completed.

--RB

#30 Wow, this sounds awesome.

#31 @John Bura...thanks, but I wouldn't quite call it "awesome" yet. ;)

At this point, it's simply pretty cool. =P

I'm working with Pino to get this into the online community repo. I have entities in place for all the major moving parts; bodies, geoms, joints, and springs. Now I'm going to loop back to the beginning and start exposing new properties and methods through the components that I've written.

This will allow the developers to set velocity, apply torques, and apply impulses to the SceneObjects in the game that use Farseer.

This is the part where the Farseer docs might be a bit of a problem. I found, during the implementation, that some of the docs are not accurate or complete. So I had to dig through the code to glean certain functionality aspects.

Also, there is this notion of "Controllers" in Farseer that is very underdocumented. My understanding is that it allows you to set zones of ambient physical affect. So a region could be identified as a liquid (and the properties of the liquid could be set in the controller), or a zone could be indentied as having planetary gravity (for space games). There is very little in the way of publicly accessible documentation regarding this concept.

I'll keep working...
--RB

#32 Hey guys,

I've a smal backlog so I'm finishing the integration of Alex Richards advanced lighting system right now and then I'll attack the files Ron sent me yesterday night. Stay tuned ;)

Pino

#33 @All...I have added some significant functionality to the FSBodyComponent class to allow the application of torques, impulses, forces, as well as accessors for the angular and linear velocity properties of the Farseer Body.

I've also added a setters (accessible to TXB) for the initial velocities (both linear and angular).

@Pino...I will send you the new copy (which I've added to a local SVN repo here).

--RB

#34 Geom's suck! =P

Ok...just wanted to give everyone a heads up here...the Geom collision categories in Farseer are implemented on a similar bitwise notion as the object types in TorqueX...I was hoping to just substitute object types in the builder and convert the bitwise values to their Geom collision category equivalents...but I'm not sure how well that will work.

For starters the object types are 64 bits, and collision categories are only 32. Secondly, the comments in the TorqueX code seem to imply that I shouldn't be fiddling with the bits because they are only for Debug mode. The implementation for object types is subject to change.

Not sure what direction I'm going to go with this...stay tuned.

--RB

#35 Lighting published (very nice addition!) now attacking this one ;)

#36 Hey all...as I write this, Pino's just informed me that he'll be submitting the Farseer integration into the community repository. I just wanted to take a minute to advise all of the major moving parts that must exist for a Torque X/Farseer experience to work correctly.

Refer back to my comments #24 and #25 in this thread to get the lay of the land in terms of the class names and what their purposes are:

www.torquepowered.com/community/forums/viewthread/118539/2#comment-770983

1. To start, create a new game project based on the community repo.
2. Add a dummy SceneObject and give it an FSPhysicsManagerComponent. Exactly one scene object should have an FSPhysicsManagerComponent at any given time. One should either exist in every .txscene file, or you should create one and make sure it's persistent. This component has 2 major purposes. First off, it gives you an in-game access point to set the level's gravity. Secondly, its ProcessTick method calls the Farseer physics simulation's Update(dt) method which makes the magic happen. For this mini-howto, set the gravity to (0, 10). This will be "traditional" gravity. Bodies will fall toward the bottom of the screen.
3. Add a SceneObject to your game, and give it an FSBodyComponent. Set the mass of the body (it must have mass, it cannot be 0).
4. Add another SceneObject and give it an FSBodyComponent. Set the mass on this one, and set the IsStatic field to "true." The IsStatic field will ensure that no physical forces will affect this body (useful for walls and floors).
5. Save and start your game.

You should see that the non-static body falls toward the bottom of the screen, and the static body stays put.

Those are the absolute basics for making Farseer do anything appreciable on screen.

The Farseer docs are here:

www.farseergames.com/storage/farseerphysics/Manual2.1.htm

Not the greatest docs in the world, but if you have SilverLight, you can see some inline examples that will give you a good idea of what the different joint and spring types do.

More in a minute...
--RB

#37 Once you have completed the above mini-tut (see my comment #36 in this thread), you should now have a sandbox with simulated physics.

Let's try to make it a little more interesting:

1. Go to the non-static body. While we're in here, give this body a name so that we can find it later (let's call it BodyA). Add an FSRevoluteJointComponent, and set the IsFixed flag to "true." For most cases, when joints/springs are fixed, the "Body" data member is ignored. Fixed joints work on only one body, so it stands to reason that they will work on the body to which you've assigned the component. The fixed revolute joint you just added will make the body stick to its position in the world, but will allow 360 degrees of rotation in that position.
2. Add another SceneObject, and give it an FSBodyComponent. Add this one above and slightly to the right or left of the body with the FSRevoluteJointComponent (BodyA). Don't forget to give your body mass.
3. Add an FSRevoluteJointComponent to this body as well. DO NOT set this one as fixed. Instead, attach this joint to BodyA, by setting the value in the Body field of the FSRevoluteJointComponent.
4. Save and execute.

When the simulation starts, your static body should remain unaffected by the simulation. You should also notice that BodyA (which fell toward the bottom in the last tut) is no longer falling. The last body you created should be falling under the force of gravity, but should swing around BodyA like a pendulum causing BodyA to rotate around its fixed revolute joint.

This tutorial is coming from memory as I'm not sitting in front of the game/sim right now. Hopefully I've gotten all the details right and I haven't missed anything.

If these tuts don't work...post here and I'll fix the tuts when I get home and can test them out (I'm on East Coast time in the US...so it won't be until 7PM or 8PM my time).

Good luck!
--RB

#38 After you've spent some time with immaterial bodies...you can add in an FSGeomComponent.

Define the Geom type...now would be a good time for me to mention this:

The only supported BODY AND GEOM types in the current iteration of the Farseer Integration are Rectangles, Ellipses, and Circles. I have not yet integrated the Polygonal body and geom functionalities as this will be a bit complex and will rely on the collision polygons to work as you would expect. Feeding those collision polys into Farseer is going to be a bit tricky, and I have not had the time to get there yet.

Once you've defined a geom, your body will now be able to collide with other bodies that have geoms. Add a few more bodies and geoms and joints to see how things swing around and smack each other about. Play around with larger and smaller masses on your bodies to see how that affects the collision responses.

Let me know if any of this is working at all. ;)

Have fun...
--RB

#39 Ron I can't wait to try this out. As soon as I get the chance I am going to try it out.

While we are debugging this can we make sure that this will pass all of the certifications to get on the xbox marketplace. Im sure there is something that could cause an unnecessary code 4. If we take care of this now, it will save a lot of time later.

Also If people use physics in their games wouldn't that be ground to make the game more expensive?

#40 @John...you can be the guinea pig for these mini-tuts...hopefully they work as I've described...if not, I'll try to fix them ASAP.

I have not found any issues yet while running on the Xbox, but my tests have been fairly rudimentary. I'm not sure what certifications processes are currently being run against the community code base, but hopefully these will be subject to it as well.

Post your findings on the mini-tuts...let me know if my memory's working okay. ;)

--RB