[CLOSED] - Farseer Phsyics Integration - Any pointers?

#41 I've had some off line discussions with Pino, and I'm going to take a minute to back off the Farseer components and tighten up the integration points between stock Torque X and the Farseer engine.

The next update to the Farseer code will include positioning and rotation of the Farseer body within the physics simulation via the SceneObject.Position and SceneObject.Rotation properties. Currently, if you change the SceneObject's position and rotation once the simulation is in progress, then the simulation's representation of the Body and Geom will not match what's in native Torque X. I'm going to ensure that there is bidirectional communication of updates to position and rotation so that changing either the Farseer Body's or the SceneObject's position will be mutually reflected.

I'm also going to add in a hook to T2DPhysicsComponent for the Velocity and AngularVelocity properties so that if you are using T2DPhysicsComponent in your current game, it will check for an FSBodyComponent and hijack changes to the Velocity and AngularVelocity values and feed them to the Farseer simulation. This will also be a bidirectional communication.

I'll keep you all posted...
--RB

#42 This sounds like too much work.. I had a very easy integration of the APE Engine which I was thinking of posting here, but I was worried it would just be abused and end up making games no one wants to play. Anyways, I'm not particularly excited about these new "additions" you guy's are talking about, especially considering that it doesn't look like you are containing it at all, and are already talking about it being a part of TX when it's not even done yet.

Anyways, my two cents is this is a bad idea, and will only get worse as long as you fail to get it to play nice with TX. But it doesn't sound like you are doing that, it sounds like a really bad port.

Let me ask you this, do Farseer objects collide with T2DCollisionComponent objects?

Also new people are going to be very confused by this, and you are cluttering up the physics for people who are buying the source, and may want to implement their own custom physics add ons. (Yes this includes me, you are re-doing something I already did for myself).

#43 @Will:
At the moment I don't think the hybrid collision is there but sure will be, that's quite obvious.

This addition won't have any effect on your APE implementation as long you don't add Farseer and APE stuff together. The principle is quite simple: if you don't want it just don't use it. This won't make any difference to your other implementation.

From the email poll I got 99% thumbs up (you are that missing 1%) so I guess that we're doing the right thing here also considering that this won't affect your usage. The only "cluttering" is a 185KB DLL that comes along... and I really don't think that 185KB will make any difference in any game.

#44 Well, I'm hoping you guy's can prove me wrong. If Hybrid integration is your goal, then I'm cool with what you are doing.

#45 @Will: hybrid integration will come because it's a natural evolution, but I guess it's not a priority because if one wants to use Farseer there is no evident point to go hybrid. This could be necessary to quick start a Farseer implementation in existent projects, just to make it quick, but as any hybrid it won't give you any result besides clamp/bounce/kill ... which is quite reductive in a Farseer environment ;)

#46 @Will...welcome to the discussion.

I respectfully accept your criticisms, and can only offer that I've been at the software engineering game for 16+ years and have no intentions of breaking anyone's stock configurations or implementations with other engines.

If you don't reference any of the FS* classes I implemented, then your stuff will all work the same way it does today.

If you don't add an FSBodyComponent...then nothing I've written will affect your work.

That's the beauty of a component-driven model...if you don't want the functionality...don't add the components.

As for the Farseer integration in general...people here expressed interest in it, so I went and tested the waters and got something at least minimally useful done within a few days. Developers can use that and extend it as they see fit...or they can disregard it entirely. I will also continue to enhance and make it "play better" with TX (that doesn't mean it's going to "infect" TX...only work more seamlessy with it).

I have no intention or desire to "prove you wrong." I'll assume you're one of the guys that didn't want it, so if you choose not to use it, I certainly won't be affected by that decision.

Good luck with your game builds and other 3rd party product integrations, but rest easy...I know how to make non-invasive software, and that's what I'll continue to do with this integration work.

Have fun...
--RB

#47 Also, I heard rumor that the TX editor would soon be changing, are you aware of this? Won't this affect your work, and create more problems, are you affecting to assimilate the new editor into your work?

#48 Rockin guys I am trying it out now.

I don't think the TX editor will change until the T2D editor changes. So I believe we have a while ;)

#49 @Will...the editor (in my experience) is mainly valuable for adding new components to your SceneObjects and setting their initial positions in the game world.

Unless TX is moving away from a component model, then the new editor shouldn't have an impact.

The editor code uses the XML schema to create fields in the editor UI that correspond to values and properties in the code. Any level editor is going to have to provide at least that much functionality. Again...unless TX is moving away from the component model.

A move away from the component model would have a huge impact on TX...it would basically make it a completely different product.

Maybe I'm not understanding your concern...but I don't see the editor modifications as having any impact on the Farseer integration. Can you give me an example of how any of your components would be affected by a new editor?

None of what we're doing with this integration will have any impact unless the components are used. And there's nothing special about the FS components I'm writing...they are every day run-of-the-mill components. They aren't hyper-integrated into the core of TorqueX.

I would imagine if a new editor would "break" the Farseer integration, then it would also break every existing TorqueX project that's currently in development.

:)

--RB

#50 @Henry...have at it!

Let me know if the tuts are accurate...totally done from memory while eating breakfast this morning. ;)

--RB

#51 Wait there are Tutorials? I gotta go check the XPdev site, I just right click and update...

I was wondering about collision but that will probably be explained in the tutorials.

From what we have seen of the new T2D, I think that T2D is more likely to move to the component model than TX move away from it. I know that the guys in the iTGB forums seemed to think that would be a good idea for them.

#52 OK hate to make double posts but where are the Tutoials? I don't see anything on the SVN

#53 @Henry...They are really mini-tuts...just to help guys setup the sandbox.

Go back to comment #24 and #25 for an overview...then read #36 and #37 for the mini-tuts.

Maybe these are actually micro-tuts? They aren't much...just some points to get you moving.

--RB

#54 Sounds ok Ron, I'm just saying there is alot of integration necessary to get that all to the standard that the TX editor already has, hence why I didn't release my components, it would just create confusion. Now you have a situation where a collision polygon, can be concave or convex, but you can't set it convex in the editor.. So maybe in the next integration of the editor, you can, but for now its like you have this working thing that nobody understands what its there for.

#55 Works great, of course I have also played with farseer a little bit. I did a fair bit of playing around with collison polygons through code with the tiles. I do not think it would be hard for you to get the collison poly from the T2DCollisonComponent. I just don't know if the t2d component would interfere with the farseer component.

It's kind of a bummer that we do not get editor source like we do with T2D.

#56 @Henry...I was thinking I can add the ability in the FSGeomComponent to allow the developer the option to "disable" the T2DCollisionComponent. This would allow both components to be used and the T2DCollisionComponent can define the polygon. Then the FSGeomComponent can pull the collision poly and neutralize the T2DCollisionComponent (if the user configures it to).

That's the problem with not having the editor source...some components provided by Torque Powered have a higher level of access to the editor than our custom built components have.

Editor source access would probably help in resolving the collision category issues that will rear their ugly head when I get into that mess.

Glad the tuts worked!
--RB

#57 I apologize for the noob question. But will this be able to work with the Platformer kit or will we have to write some code to make it compatible?

#58 Been checking out the Farseer demo's and the Physics look incredible.
I might have to try and set this up before I get started on my project.

I cant wait to see it in the SVN. Thank you so much! I will definitly give you credit, when and where its due!

#59 @John and all...Basically the goal here is to provide a TorqueX-friendly access point to the Farseer functionality. So the familiar approach is to provide a series of components that you can attach to SceneObjects in your game. So, yes it will work with the Platformer kit (the same way that any other custom component you write for yourself would work with the Platformer kit). What you WILL have to do is go into your scenes in TXB, and add the FSBodyComponent and other components where appropriate.

The best way to be able to use this and understand the moving parts would be to understand what makes Farseer tick. Best place to learn that is here:
www.farseergames.com/storage/farseerphysics/Manual2.1.htm

@Aaron...no need to wait. This is already in the SVN repo. I made some updates yesterday (minor ones, but they should help with integration into existing projects), and I've sent them off to Pino for review.

The next update will include exposure of more configurable properties within each component. There are some properties of the various bodies, geoms, joints, and springs that are not yet exposed to Torque X Builder. So I'll be opening these up soon.

After that I'll move on to abnormal bodies and geometry (polygonal). Right now all the bodies are created and collisions are performed using symmetric types; rectangles, circles, and ellipses. Farseer supports abnormal geometry, so I'll be hitting that area soon.

Have fun with this...
--RB

#60 Ron I can't wait to try this out. I am for sure going to try this out on friday. :)