[CLOSED] - Farseer Phsyics Integration - Any pointers?
by Ron Barbosa · in Torque X 2D · 07/29/2010 (12:51 pm) · 234 replies
Hey all...I've just recently started looking at some demos and videos for Farseer Physics.
I was curious if anyone here had done or is considering a Farseer integration with TorqueX. If so, how's it going for you?
I am admittedly ignorant in the use of the physics engine, so I have no idea where to begin...but I'm just curious if folks are even trying this and whether or not it integrates fairly simply or if it will detract too much attention from my game build.
I don't want to take a 2-month detour from my game project just to integrate the physics. My game project is going to be a value proposition. I want to sell it cheap and see if I can push volume...so if it doesn't have a proper physics implementation, or uses only the TX physics...that's ok. But if I can spend a couple of weeks or a month on the Farseer integration...that might help push sales volume.
Thanks!
--RB
I was curious if anyone here had done or is considering a Farseer integration with TorqueX. If so, how's it going for you?
I am admittedly ignorant in the use of the physics engine, so I have no idea where to begin...but I'm just curious if folks are even trying this and whether or not it integrates fairly simply or if it will detract too much attention from my game build.
I don't want to take a 2-month detour from my game project just to integrate the physics. My game project is going to be a value proposition. I want to sell it cheap and see if I can push volume...so if it doesn't have a proper physics implementation, or uses only the TX physics...that's ok. But if I can spend a couple of weeks or a month on the Farseer integration...that might help push sales volume.
Thanks!
--RB
#202
Just kidding...Pino and I have been working very hard on this feature to make it work and to keep it well integrated with the rest of Torque X while also making it non-invasive to those folks who are not planning to use Farseer.
It's been alot of fun and to anyone who plans to use it...I hope it serves your needs.
--RB
09/07/2010 (5:03 pm)
@Charles...we've certainly put in a lot of work...but I don't know if it's "good work." ;)Just kidding...Pino and I have been working very hard on this feature to make it work and to keep it well integrated with the rest of Torque X while also making it non-invasive to those folks who are not planning to use Farseer.
It's been alot of fun and to anyone who plans to use it...I hope it serves your needs.
--RB
#203
@Pino - just sent you an email. Coulda sworn GG had a messaging system built in; guess not!
Thanks again guys!
09/07/2010 (9:09 pm)
@Ron - It'll add a whole nother dimension to what we could do with tx2d (yes, people talk that way where I'm from).@Pino - just sent you an email. Coulda sworn GG had a messaging system built in; guess not!
Thanks again guys!
#204
If you get using the Farseer stuff, post vids here.
Enjoy!
Ron
09/08/2010 (1:13 am)
@Charles...I live in FL...you wouldn't believe the way some people talk around here. ;)If you get using the Farseer stuff, post vids here.
Enjoy!
Ron
#205
I'm using the Observer Pattern to allow the various Farseer entities to stay in sync when the bodies and geoms change size.
As part of this submission, there are 2 new general-purpose interfaces that have been added to the code, IObservable and INotifiable.
FSBodyComponent now implements the IObservable interface and FSGeomComponent and all the joint and spring components now implement the INotifiable interface.
Using this interface, the Geoms, joints, and springs subscribe to "observe" the FSBodyComponent. When changes are made to the FSBodyComponent that materially effect its observes (such as resizing the object), the observers will receive a "message" from the FSBodyComponent telling them what has changed and allowing them to take action.
In the case of Farseer, that normally means resizing the geoms, and performing an on-the-fly removal and readdition of the joints and springs.
It works pretty efficiently and doesn't seem to have broken anything.
Farseer aside...the Observer Pattern is a very useful tool in game development. It's got built-in efficiency in that the observation subject only needs to inform its observers when a change has been made (and not during every frame, tick, or clock cycle). This allows you a lot of leeway in performing reactive functionality. Rather than having to check your reaction condition during each tick, you are advised through observation when action needs to be taken.
I wrote a piece in Game Engine Gems that addresses the use of the Observer Pattern for game state management.
It's a very useful paradigm, and the interfaces that make it work are now part of the community repository.
Have fun!
--RB
09/08/2010 (2:16 am)
Hey all...after a few days of stable testing...I've submitted the Farseer body/geom resizing integration code. Now if you resize a scene object by changing the SceneObject.Size value, the change will be captured and communicated to the FSBodyComponent to allow the body to recalculate its moment of inertia.I'm using the Observer Pattern to allow the various Farseer entities to stay in sync when the bodies and geoms change size.
As part of this submission, there are 2 new general-purpose interfaces that have been added to the code, IObservable and INotifiable.
FSBodyComponent now implements the IObservable interface and FSGeomComponent and all the joint and spring components now implement the INotifiable interface.
Using this interface, the Geoms, joints, and springs subscribe to "observe" the FSBodyComponent. When changes are made to the FSBodyComponent that materially effect its observes (such as resizing the object), the observers will receive a "message" from the FSBodyComponent telling them what has changed and allowing them to take action.
In the case of Farseer, that normally means resizing the geoms, and performing an on-the-fly removal and readdition of the joints and springs.
It works pretty efficiently and doesn't seem to have broken anything.
Farseer aside...the Observer Pattern is a very useful tool in game development. It's got built-in efficiency in that the observation subject only needs to inform its observers when a change has been made (and not during every frame, tick, or clock cycle). This allows you a lot of leeway in performing reactive functionality. Rather than having to check your reaction condition during each tick, you are advised through observation when action needs to be taken.
I wrote a piece in Game Engine Gems that addresses the use of the Observer Pattern for game state management.
It's a very useful paradigm, and the interfaces that make it work are now part of the community repository.
Have fun!
--RB
#206
Basically, I modified Pino's custom material to allow the body to be defined full size in TXB, then when disturbed, the water presents ripples and distortions to the texture.
I'm not sure if this is the same effect that Pino was shooting for, but I figured this was worth sharing to see if this effect will work for your needs.
@Pino...I know I sent you a lousy texture in the sample (okay...there's no such thing as liquid bricks) so maybe this video will give you a better idea of the effect I was envisioning. Let me know if this matches what you were shooting for, and I'll submit the change.
Enjoy!
--RB
09/09/2010 (5:29 am)
Hey all...here's a video of my attempt at the textured fluid material.Basically, I modified Pino's custom material to allow the body to be defined full size in TXB, then when disturbed, the water presents ripples and distortions to the texture.
I'm not sure if this is the same effect that Pino was shooting for, but I figured this was worth sharing to see if this effect will work for your needs.
@Pino...I know I sent you a lousy texture in the sample (okay...there's no such thing as liquid bricks) so maybe this video will give you a better idea of the effect I was envisioning. Let me know if this matches what you were shooting for, and I'll submit the change.
Enjoy!
--RB
#207
09/09/2010 (8:23 am)
@Ron: that's just great! I have to revise the little I've learned about shaders... looks that I've got partial/wrong info about it.
#208
Basically, just build out your body of water in TXB, and it will look the same way in the builder as it does in your game (in terms of the size and scale of the texture). Then just splash around and see the distortions.
I'm a bit rusty when it comes to shaders, but this one is being done in application code for the moment. It will probably be best to move this logic out of the application and into an effect file for liquid-GPU-love. :)
Have fun with this...
--RB
09/09/2010 (11:43 am)
Hey all...I've submitted the new water material. As indicated in the video in comment #206, it's not a tiling water texture (although we can easily add that in as an option).Basically, just build out your body of water in TXB, and it will look the same way in the builder as it does in your game (in terms of the size and scale of the texture). Then just splash around and see the distortions.
I'm a bit rusty when it comes to shaders, but this one is being done in application code for the moment. It will probably be best to move this logic out of the application and into an effect file for liquid-GPU-love. :)
Have fun with this...
--RB
#209
thanks to Ron the texturing is now perfect. I've just committed a change allowing the tiling of the texture using two new params in FSFluidComponent (RepeatTexture_X, RepeatTexture_Y): allowed values are between 0.25 and 100 (values < 1 magnify the texture). Also added a specific effect file for future improvements.
Again: Ron, thanks a wagon!
09/09/2010 (6:21 pm)
Hi guys,thanks to Ron the texturing is now perfect. I've just committed a change allowing the tiling of the texture using two new params in FSFluidComponent (RepeatTexture_X, RepeatTexture_Y): allowed values are between 0.25 and 100 (values < 1 magnify the texture). Also added a specific effect file for future improvements.
Again: Ron, thanks a wagon!
#210
I think it's an even bigger deal that you added texture tiling/repeating. :)
Once again, glad to be able to help. My own game projects have stalled, so this integration is the only non-work-related project I have going. It breaks up the monotony. ;)
--RB
09/09/2010 (6:48 pm)
@Pino...thanks for the accolades, but it was not a very big deal.I think it's an even bigger deal that you added texture tiling/repeating. :)
Once again, glad to be able to help. My own game projects have stalled, so this integration is the only non-work-related project I have going. It breaks up the monotony. ;)
--RB
#211
09/09/2010 (8:38 pm)
Ok, you guy's are definitely getting my attention, I loaded up my own 3.15 community project and i'm messing with it now. So far it looks promising.
#212
09/09/2010 (8:47 pm)
@Will: glad to hear that :)
#213
It really is non-invasive if you choose not to use it in the end.
If you get stuck on getting anything started...post here...be glad to help out.
--RB
09/09/2010 (8:59 pm)
@Will...I hope you enjoy using it. It was a lot of fun to implement.It really is non-invasive if you choose not to use it in the end.
If you get stuck on getting anything started...post here...be glad to help out.
--RB
#214
My main concern is that you should be using either a scroller or animated, tiled sprites possibly, for water, to give a basis? Or am I totally off?
Obviously, as I have a platformer, I'd like very much to have water to land in, possibly swim in, or just die. I'd be happy to even post my platformer integration to help others accomplish this as well.
So far my objects just sink through the water.
09/09/2010 (9:21 pm)
I'd like to see some example files of what you guy's are posting. I could possibly get one of my artists even to give you some better textures, if we can manage anything decent.My main concern is that you should be using either a scroller or animated, tiled sprites possibly, for water, to give a basis? Or am I totally off?
Obviously, as I have a platformer, I'd like very much to have water to land in, possibly swim in, or just die. I'd be happy to even post my platformer integration to help others accomplish this as well.
So far my objects just sink through the water.
#215
Farseer actually calculates density as a function of body size and its "screen area" so try making your bodies physically larger on screen (thus less dense), less massive, or make your fluid more dense.
Any of these or some combination should get your objects to float in the water.
--RB
09/09/2010 (9:39 pm)
@Will...I'm about to go sit down for dinner, so I can't field all these questions right now, but I can give you one tip.Farseer actually calculates density as a function of body size and its "screen area" so try making your bodies physically larger on screen (thus less dense), less massive, or make your fluid more dense.
Any of these or some combination should get your objects to float in the water.
--RB
#216
How are objects recognizing each other... I'm a bit confused.
1. I see the geom object has a "collidesWith" field, which I assume works on object type.
2. I see the geom object also has collision group which appears to take an integer value.
3. Does water collide with body, or does body collide with water, or both have to collide.
4. Does body need a geom component, because it seems to default to rectangle.
09/09/2010 (9:53 pm)
My first shot at changing density's didn't do anything, but I tried again as you suggested, still not seeing any results.How are objects recognizing each other... I'm a bit confused.
1. I see the geom object has a "collidesWith" field, which I assume works on object type.
2. I see the geom object also has collision group which appears to take an integer value.
3. Does water collide with body, or does body collide with water, or both have to collide.
4. Does body need a geom component, because it seems to default to rectangle.
#217
If you're going to use the integrated code, you're best off to hit comment #24 in this thread and start reading from there. Let me see if I can distill it for you:
For all Farseer interactivity as part of this integration, the FSBodyComponent is required. If your scene object does not have an FSBodyComponent, it is basically invisible to Farseer. FSBodyComponent let's Farseer position and rotate the body and define its moment of inertia.
A Farseer Geom (represented by the FSGeomComponent) requires a body. Geoms give the bodies substance and make them eligible for collisions.
That's the basic setup to make a body movable and collision ready in Farseer.
Other items like joints and springs (each represented by its own component) can be used to bind 2 bodies together or to make their rotations be relative to one another. They can also be used to fix the bodies to the world (as opposed to fixing them to another body).
The FSPhysicsManager component is used to set the gravity in the level and it also makes sure the simulation updates each clock tick. During your game's execution, there should be EXACTLY 1 scene object that has an FSPhysicsManager component.
The the fluid components can be added to scene objects that have both a body and a geom.
In order for a body to react with the fluid, it must have its "FluidReactive" flag set to true (this flag is in FSGeomComponent).
Start reading around comment #160 to get more information on how the collision system works.
Basically, it's tied into the TorqueObjectType values that you define in native Torque X. However, there are some caveats to collision handling that are part of Farseer (and not imposed as part of this integration). Those are detailed in the comments regarding collisions around #160.
Lastly...this integration is a reflection of the classes and features available in Farseer 2.1.3. This integration is largely a series of wrapper classes around the Farseer library. So if something doesn't seem to work right...check the Farseer Manual.
I know this thread is kind of exhaustive...but most of the questions you're asking have been answered over time.
The first rounds of integration began around comment #24...start there for the crash course. Then hit up comment #160 for details regarding collision management.
Also...it might not hurt to hit each page of this thread and search for the words "submit", "commit", and "svn". This will at least give you some idea of where code changes were made and announced. Normally we'll include some instructions along with each submission.
Good luck...
--RB
09/09/2010 (10:51 pm)
@Will...are you attempting to make use of the Farseer classes directly, or are you using the components we've built as part of the integration?If you're going to use the integrated code, you're best off to hit comment #24 in this thread and start reading from there. Let me see if I can distill it for you:
For all Farseer interactivity as part of this integration, the FSBodyComponent is required. If your scene object does not have an FSBodyComponent, it is basically invisible to Farseer. FSBodyComponent let's Farseer position and rotate the body and define its moment of inertia.
A Farseer Geom (represented by the FSGeomComponent) requires a body. Geoms give the bodies substance and make them eligible for collisions.
That's the basic setup to make a body movable and collision ready in Farseer.
Other items like joints and springs (each represented by its own component) can be used to bind 2 bodies together or to make their rotations be relative to one another. They can also be used to fix the bodies to the world (as opposed to fixing them to another body).
The FSPhysicsManager component is used to set the gravity in the level and it also makes sure the simulation updates each clock tick. During your game's execution, there should be EXACTLY 1 scene object that has an FSPhysicsManager component.
The the fluid components can be added to scene objects that have both a body and a geom.
In order for a body to react with the fluid, it must have its "FluidReactive" flag set to true (this flag is in FSGeomComponent).
Start reading around comment #160 to get more information on how the collision system works.
Basically, it's tied into the TorqueObjectType values that you define in native Torque X. However, there are some caveats to collision handling that are part of Farseer (and not imposed as part of this integration). Those are detailed in the comments regarding collisions around #160.
Lastly...this integration is a reflection of the classes and features available in Farseer 2.1.3. This integration is largely a series of wrapper classes around the Farseer library. So if something doesn't seem to work right...check the Farseer Manual.
I know this thread is kind of exhaustive...but most of the questions you're asking have been answered over time.
The first rounds of integration began around comment #24...start there for the crash course. Then hit up comment #160 for details regarding collision management.
Also...it might not hurt to hit each page of this thread and search for the words "submit", "commit", and "svn". This will at least give you some idea of where code changes were made and announced. Normally we'll include some instructions along with each submission.
Good luck...
--RB
#218
Have a look back in the forum: Ron has posted a lot of practical information about all the points you're asking about ;) I konw we should feed a wiki for TX-CEV but... there is no time and now with the 4.0 port it'll be more difficult. At any rate I'll post a mini-game in the TX-CEV TRAC website to allow some code sample. This week-end will be full for the codebase selection of Torque X 4.0 CEV but I'll try to put something together.
Midnight here... very long day at work so I'll commit a new enhancement and then I'll call it a night ;)
09/09/2010 (10:55 pm)
@Will: Have a look to your Geometry component options... have you checked the FluidReactive box? Have a look back in the forum: Ron has posted a lot of practical information about all the points you're asking about ;) I konw we should feed a wiki for TX-CEV but... there is no time and now with the 4.0 port it'll be more difficult. At any rate I'll post a mini-game in the TX-CEV TRAC website to allow some code sample. This week-end will be full for the codebase selection of Torque X 4.0 CEV but I'll try to put something together.
Midnight here... very long day at work so I'll commit a new enhancement and then I'll call it a night ;)
#219
I'm stumbling along, but getting there..
I got a couple random ripples and a floating object. The ripples were not centered.
I checked the fluid to "IsStatic", and it dissapeared when the floating object sunk into it.
More or less, its a fun item so far.
09/09/2010 (11:18 pm)
Madness! I thought the FluidReactive box was for an object bouncing around and making waves, to give a reactive look? I reversed my thinking, and it worked.I'm stumbling along, but getting there..
I got a couple random ripples and a floating object. The ripples were not centered.
I checked the fluid to "IsStatic", and it dissapeared when the floating object sunk into it.
More or less, its a fun item so far.
#220
It took another hour... you have a new SVN commit to get so update to last revision to have:
- FSGeometryComponent: OnSeparation delegate (complements OnCollision)
- OnBroke delegate on all joints and springs
Enjoy ;)
Pino
09/10/2010 (12:15 am)
Hey guys,It took another hour... you have a new SVN commit to get so update to last revision to have:
- FSGeometryComponent: OnSeparation delegate (complements OnCollision)
- OnBroke delegate on all joints and springs
Enjoy ;)
Pino
Associate Giuseppe De Francesco
DFT Games Ltd