[CLOSED] - Farseer Phsyics Integration - Any pointers?

#161 Hey all...one more tiny update tonight that might add alot of value to what you're working on.

I've just made a small change to FSBodyComponent that allows you to define a collision polygon using T2DCollisionComponent. There's a new check box called "UserDefinedCollisionPolygon." If you enable this option, the Body and Geom will be created using the standard technique available in Torque X Builder for defining a collision polygon.

This is cool because if your geometry is convex and simple, then it is probably less resource intensive to draw your own polygon rather than to use a texture to create one. Additionally, you can enable the "RenderCollisionBounds" flag in T2DCollisionComponent to see the boundaries of your collision.

Keep in mind...Torque X Builder will AUTOMATICALLY add in a T2DCollisionComponent if you define the collision polygon using the editor. This is necessary and is used by the Farseer integration code to grab the vertices that make the polygon.

So choose your weapon...you can use T2DCollisionComponent to define your polygons or use a texture...it's up to you.

[UPDATE] this is also VERY useful when building games that use tile maps. You can create blank scene objects and overlay them on top of the tile map. Give them FSBodyComponents and FSGeomComponents, then use TXB to draw their collision areas. VERY valuable for tile maps.

Have fun!
--RB

#162 Hey all...one more update before bed time. ;)

I just made my first pass at the weld joint. This joint is very poorly documents (as in, it does not even get mentioned in the manual) and the code is not commented either.

I think I have a good implementation in place. I've exposed all the public data members of the Farseer Weld class to TXB.

Similarly to the FSRevoluteJointComponent, this one also has an anchor value that can be interpreted in many ways. So it includes an AnchorType property as well to indicate how the anchor vector value should be used.

It seems to work the way it does in the demo...maybe someone can whip up a cool lever or seesaw demo. ;)

Let me know if this is working as you'd expect...or if I just completely flubbed the implementation. :)

Enjoy...
--RB

#163 Hey all...sync your checkouts again and get the latest revision.

Pino found and fixed a race condition that might cause your user-defined polygons to not reflect the full set of properties you've assigned to the body.

His update will make sure that after the body gets created, all properties will be updated based on the values in TXB.

Thanks, Pino!
--RB

#164 Hey Ron, I was trying make an object slide over the top of a point of gravity to make it stick in place, but the object gets thrown away or vanishes. I know the point of gravity is probably not intended to work like a "layer gravity", but it would be sweet if it could function like that when it doesn't have the Geom component or if they are in the same Collision Group.

#165 @Aaron...I'm not sure I understand what you're requesting (or even if you're requesting anything), but keep in mind that bodies are just points in space and a moment of inertia.

The point in space defines the body's position and moment of inertia defines its resistance to rotation about its center.

Not having a geom means the body is insubstantial...meaning another body can arrive at the focal point of the gravitational influence. At that focal point, there's potential for the acceleration component of the force (gravity) to become REALLY high (as in approaching infinity) in those cases...objects will literally disappear in 1 frame. They haven't disappeared...they've just accelerated so fast that they are no longer in the visible space.

With a body being a point in space and gravity being applied at that point...I don't think there can be any concept of a "layer of gravity."

Geoms give the body substance...and as a side effect keep affected bodies AWAY from the point of gravity where accelerations can get extreme.

I'd try to maybe post what you're trying to accomplish here and see what kind of recommendations we can make to help you achieve the desired effect.

Good luck...
--RB

#166 Thanks Ron, I guess I was trying to defy physics :-) Its for a puzzle game with physics, using zero gravity and points of gravity to pull pieces into place when they are pushed from the player. The best way to visualize what I'm wanting is to vision a chess board and under each square there is a magnet. The game pieces are also magnetic, allowing them to stick in place but also able to be pushed off their spot and onto a new square. I can think of other ways to do this, but I would really like the gravity effect/look that the physics engine offers. This is were I got the "layered gravity" idea (a 3d world effect in a 2d world).

It's a side project so its really no biggie right now.

#167
I have attached an Angle Spring to my "box car" to simulate a weighted object that is affected by the speed, gravity, and my weight shift controls.

I am updating the TargetAngle of the AngleSpring "ShiftWeight" to match the box car "CarFrame". Here is the code:

if (move.Sticks[1].X > 0.0f)
                {
                    ShiftWeight.TargetAngle = CarFrame.Rotation + (move.Sticks[1].X * 30);
                }
                else if (move.Sticks[1].X < 0.0f)
                {
                    ShiftWeight.TargetAngle = CarFrame.Rotation + (move.Sticks[1].X * 30);
                }
                else
                {
                    //The part that doesnt work when CarFrame.Rotation gets close to 0
                    ShiftWeight.TargetAngle = CarFrame.Rotation;
                }

Here is the problem: The car can go up or down hills, but when the CarFrame.Rotation gets close to 0 (when the car is upright), all hell breaks loose.

FYI: The SpringConstant needs to be between 50,000 and 75,000 to properly work, unlike the 1,000,000 needed when fixed to the world.

#168 @Aaron...it's possible there's a division by zero issue somewhere in the code.

The integration that's ongoing in this forum doesn't actually have anything to do with the mathematics performed by the physics engine...it's just exposure of the various physical simulation entities that can be used.

I have run into a few situations while testing where things just seem to "fly apart" so to speak. I've also had a few crashes in the Farseer code and have even seen some in the demos that came with the engine.

Is there an actual crash...or are things just kind of coming unraveled?

--RB

#169 @Ron: It's random, sometimes it freaks out real bad and crash, other times it comes undone and then magically rebuilds itself.

I think my next step is to write something to skip 0 and 360 and see if this fixes the issue. This brings me to a noob question... In general, do angles continue to calculate outside of 0 through 360(like -45 or 405) without causing issues? I noticed in TXB if you put a negative rotation value it will update to a positive after you save and reload.

#170 @Aaron: maybe it's still too early in the morning but... I miss the meaning of your code. You're forcing an angle to an angle spring because... ? Is that a try to force a motion via the spring's push/pull?

#171 @Pino: Without updating the TargetAngle it will always stay at the initial angle(try to), even if the car is at 180 degree's.

I have been messing and testing with this all night and have narrowed down the degree's of problem. It was not actually 0, it is 300-360 (60 degrees of pain) without these degree's I experience no issue. Driving me crazy :-)

Edit-> I'm not changing the angle of the spring, just the target angle (the angle that offers it zero force)

#172 @Aaron: Not sure to understand your goal. If it's to keep that at the same angle of the cart why don't use a WeldJoint?

#173 @Aaron...another thing you might try is an FSAngleLimitJointComponent. It allows you to fix the "weight" to the car and ensure that the drift in angle between the 2 is always between some high and low range. If you want it fixed at a specific range, then you can use that value as both the high and the low end of the range.

Hope that helps...
--RB

#174 So... Ron told you that something was cooking on this end, and here I am with a new video showing another cool couple of controllers integrated into Torque X to allow you to have fluids (water & C.) in your game :)

How to use this new feature? Well, just have a static sprite for your water (it should be ok also an Animated Sprite but I didn’t test it) and add it to your scene. Edit the water scene object and simply add the FSFluidComponent to it. Disable the Geometry collision as they are not needed (unless you need them for some other use).

Then go to the scene objects that are supposed to interact with the fluids (any fluid) and check the FluidReactive checkbox in the FSGeometryComponent.

That’s it. Play with the fluid parameters to get the effect as you want it ;)

In this version the FluidMaterial is not active so the fluid will be rendered still using your texture. I’m working on the material to render the waves but it’s driving me crazy (you can see it in the repository) because it renders the positions logarithmically… crazy behaviour indeed. If anybody will have a look at it he’s welcome :)

#175 Awesome work, Pino...this is excellent.

So I assume these bodies only react to the water when they are in contact with the water sprite?

Do they use normal physics until they come in contact with the water?

That's just sweet!
--RB

#176 @Ron: Yes, all the physics works as usual outside and inside the water. In the water there are other forces that come in the picture that you can configure in the fluid component.

The Fluid component makes a quite simple intersection check using AABB.Intersect between the fluid and the incoming geometry.

#177 @Pino: I love the water demo! RE#172: The goal is to keep same angle of the cart, but also simulate a human like reaction of maintaining balance (eventually, I will make this invisible and place a character animation that is triggered by the angle change). It all works great, besides those 60 degrees that cause chaos.

The weld joint doesn't allow the spring joint to rotate(unless I'm doing something wrong).

@Ron: Re#173: I played around with AngleLimit, but dont think it will give me the effect I am trying to achieve, because it doesn't have a target angle.

@All: Ok, so I was digging around a second ago and in the farseer 2.1.3 XNA sample code download, Demo 7: Dynamic Angle Joints, they are achieving what I want, the Target Angle is dynamic. I'm going to check the code and see if I cant get it working, I will give you guys an update soon.

#178 @Pino that demo on #174 looks really nice.

#179 @Will: thanks, but there will be quite more nice stuff to come ;)

#180 Ok Guys,

In regards to my ongoing issue: either I'm doing something completely wrong, I missed a simple step, or there is a bug somewhere. In the Spider.cs from the Demo 7: Dynamic Angle Joints found here 2.1.3 Xna Simple Samples, they update the target angle by the degree's they want to move not the actual degree in the world. However, if I want to change the target angle I MUST use the world's degree. I hope this makes sense.

To recreate this problem, make a movable body (shape1) and then attach another body (shape2) with an angle joint and a revolute joint, check is fixed for the angle joint. you will see that shape 2 will always stay in the initial targetAngle even when shape 1 rotates.

Any help on this would be greatly appreciated. It might just be me.