[CLOSED] - Farseer Phsyics Integration - Any pointers?

#221 @Will...the IsStatic flag makes the body immovable, but still substantial. Meaning, it will collide, but it will not react to forces (including forces resulting from collision).

This is good for walls and floors.

--RB

#222 Ok.. still having issues with my waves. It seems only one is being generated, its very small, and only works on the initial impact.

#223 @Will...I'm not sure what kind of geometry you're using for your sprite. Is it polygonal geom or one of the regular shapes? If it's polygonal, are you defining the collision poly in TXB or are you using a texture to define the collision area?

By the looks of your sprite, it appears that what you're seeing is a diver making a clean entry into the water (with no splash). Try belly-flopping into the water.

Hit the water with the broad side of a rectangle.

Then work on the fluid dynamics. Make your fluid less dense...add more nodes to the object's water component. Put in some dynamic waves using the wave generator.

You are seeing the reaction...it's just not very pronounced which leads me to believe that it's more a matter of tuning and less a matter of "things not working."

Increase the gravity to accelerate your sprite into the water quicker.

The Farseer water controller is a bit more like jell-o than water. It can only distort the body that represents it...but it can't break apart bits to create separate water droplets.

Hope that helps in some way...

#224 Still only creates waves on initial impact.


Increasing and decreasing the number of nodes seemed to dissipate the waves more quickly, or spread them out.

Adding another object made a bigger splash, but once again, upon re-entry, they did not splash again.

#225 @Will...remember...these are wrappers for Farseer functionality. If there's a bug in Farseer...it will most likely be present in this implementation:

From the Farseer forums:

Quote:
Minor, rare, issue found: Sometimes if you land on the diving board just right, you will dip into the water for a second (splashes) and then fly out and land in the water again somewhere else. The issue is that there is only a splash the first time you enter the water. Not a big deal, but the game would be a bit more polished if this were fixed.

Ron

#226 Here's some splashing around. The fluid simulator is far from perfect but tuning it gives some nice results. In this demo I didn't spend much time tuning the parameters so I'm sure it could be way better than this.

These are the settings used:

Gravity: Y = 0, Y = 250

FSFluidComponent:
Frequency 0.001
DampingCoefficient 0.930
NodeCount 200
RotationalDragCoefficient 0.002
LinearDragCoefficient 0.98
Density 0.027
WaveGeneratorMax 50.000
WaveGeneratorMin 0.000
WaveGeneratorStep 0.000
RepeatTexture_X 1.000
RepeatTexture_Y 1.000

The fluid Geometry collisions are disabled.

#227 @Pino/Ron: are waves like this water demo an option with the current component.

#228 @Aaron: yes, just keep a very low number of wave nodes ;)

#229 @Pino: Very cool, I havent had the chance to play with the fluid component yet. Can't wait to give it a try.

#230 New toys for the kids! :)

Hey all...I just finished implementing the Farseer Path generator into Torque X. Really cool stuff. It can be used to create ropes, chains, bridges, tank treads, etc.

The new component is called FSPathComponent.

It works like so...each path segment has 3 components.

1. The scene object that you attach the FSPathComponent to is the first link in the path section. This should be a real scene object (not a template).
2. The FSPathComponent has a LastLink property. This is the scene object that represents the end of the path segment. This should also be a real non-template object.
3. There is also a LinkTemplate property. This is the scene object that represents the links in the path segment. This object should be a template, as the component will create any number of links in the chain that you request.

All 3 links must have an FSBodyComponent. If you choose to have the links collide with other objects, you can also add the FSGeomComponent. Both the body and geom are configured as always. No changes were made to those components.

You can also indicate whether you want to pin the first and/or last links to a fixed position. If you fix one end, it will be anchored to the position you defined in TXB. The individual links will be Farseer bodies and will react to the simulation's physics.

Once the path has been created, each link is bound to the next using a link type that you specify. Four different link types are supported; RevoluteJoint, SliderJoint, PinJoint, and LinearSpring. These are all familiar to anyone who's been using the Farseer code. Just to note: your objects WILL NOT need and WILL NOT be assigned FS*SpringComponents or FS*JointComponents when the links are created. These are raw joints and springs with no Torque X components to control them (for now...this may change in the future).

The last link of one path segment can be the first link in another path segment. This technique can be used to link multiple segments together to create a loop for a conveyor belt or tank tread like so:

1. Create PathSegmentA
2. Add the FSPathComponent to PathSegmentA's last link and create PathSegmentB.
3. Add the FSPathComponent to PathSegmentB's last link and create PathSegmentC.
4. Set PathSegmentC's last link to be the same scene object as PathSegmentA's first link (the owner of the FSPathComponent object for PathSegmentA).

This will create a 3 segment loop. :)

Path segments have a user-definable LinkCount property. This is the number of links in the chain (including the first and last link). Every chain must have at least 2 links, so specifying a number less than 2 will cause the component to clamp the value to 2.

I'm uploading a video now to show some of this work...but it's taking a long time to upload and it's been a long night. I'll post it tomorrow.

[UPDATE] - Okay...here's that video.

Enjoy...
--RB

#231 @All...with regards to the path generation code that just went in last night.

This change is really a convenience change. There is nothing that the path generator does for you that you could not do on your own using the components that have already been created for this integration.

That being said, with convenience often comes a loss of flexibility. With the standard components we've written for this integration, the joints and springs have all the properties exposed for maximum tuning (including a delegate for defining functionality for broken joints and springs).

With the Farseer path generator, only a few parameters have been exposed for joints and springs, and there is no way to specify the "Broke" delegate or, for that matter, to even specify the breakpoints of the joints and springs.

Sometimes, there's just no substitute for "hard work," and if you need a property or feature that's not exposed in the FSPathComponent (and I've exposed all of the ones that Farseer supports), then you just might have to build your ropes, chains, and treads the "old fashioned" way. :)

I hope this makes some kind of sense!

Enjoy...
--RB

#232 Wow...it's been a fun 6 weeks, and while the integration took a little longer than I'd expected...I'm pretty comfortable saying that Farseer Physics is now a well-integrated subsystem to Torque X.

Thanks to Pino, for his help in integrating the controllers for point gravity and fluid dynamics as well as his help in closing gaps in the integration, fixing bugs, and exposing the delegates for collision management and link breakage.

At this time I have no plans to create any new components for this integration. I will attempt to fix any defects that arise with the components that have already been written.

My focus will shift now to the port of Torque X to XNA Game Studio 4.0...all of the Farseer integration code has already been included as part of that new code base, and NONE of the Farseer integration code will have any value if Microsoft pulls the plug on XNA 3.1 XBLIG submissions before we finish the port to 4.0.

That being said...any further development of the Farseer integration against the XNA 3.1 based product would be a pretty futile endeavor.

The community here will have its hands quite full with the 4.0 port...so please be aware that this integration will definitely play second fiddle to that effort.

I hope you all can find some ways to make use of the effort put forth here over the last month and a half...and I'm looking forward to seeing how folks will use the Farseer integration combined with the 4.0 port to continue to make new product for the Xbox 360 and other 4.0-supported devices.

Thanks for hanging out with us here while we made this port come together.

Ron

#233 Ok, I'm really confused with this Farseer intergration, can someone explain a basic number step of how to get it working with the new CEV, as i am completely clueless to how it works? I just normally play around with the Torque X T2DForceComponent... Please help? The less coding the better, as i purely work on design :)

#234 @Solloman:

1) With CEV setup you will see a new component called "FSPhysicsManagerComponent" add this to a blank scene object and set the gravity of your world. You must have this component on the scene for the physics engine to work.

2) Add the "FSBodyComponent" to your objects that you want to be affected by the physics engine. Within this component you can setup the Mass and Shape of the object. You also use this component to control Velocity, Angular Velocity and Drag.

3) Add the "FsGeomComponent" to the objects to handle the collisions and define the collision groups (need this if you want your objects to collide and have physics effects) Note: The FSBodyComponent will be added automatically if you add this component first.

You should have physics now! This is a brief, if you need more help, i suggest reading through this entire thread (I know, its long, but it has your answers).