[CLOSED] - Farseer Phsyics Integration - Any pointers?

#141 Update:

I've committed a better way to manage the collision setting so you can disregard the code in my previous post and simply assign the collision delegate.

You'll find also a new parameter in the Geometry component to define in how many vertices each edge of a rectangular body shall be divided.

#142 @All...I've just submitted the changes to support abnormal and concave geometries.

The way the implementation works, a Torque X 2D material is used to define the collision areas of a geometry. Transparent regions are ignored as part of the collision area, and filled in pixels represent the solid parts. Farseer uses the texture to create a polygon representing the collision regions.

The material can be set using a pulldown in the body component. The polygon will be used to set the moment of inertia in the body and then passed off to the geom to set the collision area.

Only a simple material can be used for the collision polygon at this time. Multi-cell materials cannot be used.

Beneath the pulldown where you specify the collision material, there are 3 new properties. There's a boolean called "ScaleUsingMySize" and a scale vector (with independent X and Y coordinates). This was broken up into 2 properties so that each could be given a default of 1.0.

Because the scale of our game world units may vary wildly from the size of our texture images, the "ScaleUsingMySize" option can be used to scale the collision polygon relative to the size of the SceneObject. Without this addition, if a 256 x 256 scene object used a 512 x 512 shape material, the object's collision area would be twice the size of the actual object in the game world. The ScaleUsingMySize option will tell Farseer to scale the object by (in this case) a factor of 0.5 x 0.5.

If ScaleUsingMySize is checked off, then the ShapeMaterialScaleX and ShapeMaterialScaleY values are ignored. If not, then you can plug in any arbitrary scale value here. But always keep in mind, the scale is factored into the MATERIAL'S RESOLUTION, not the size of the scene object. So, if using a 512 x 512 texture on a 10 x 10 scene object, with ScaleUsingMySize disabled and a value of 0.1 x 0.1 for shape scaling, the collision geometry would be 51.2 x 51.2.

Clear as mud?

This solution is very flexible, as I've found while unit testing. You can use rectangular collision materials on circular scene objects and vice versa. You can also create scene objects with "chunks" cut out, like a crescent moon. It was alot of fun playing around with this.

There were a few problems in the Geom factory methods provided with Farseer that needed some modifications, but I'm pretty comfortable with the latest submission.

How about another video, Pino! ;)

--RB

#143 That's totally awesome Ron! Will be using that feature right away.

@Pino: Are you using Camtasia for your screen rec? I tried to get some videos made but the video animation was a bit choppy after it was done recording.

#144 @Aaron: nope, I use Fraps 3.1.0 which is an excellent tool for this kind of production.

Working at producing a new demo right now ;)

#145 Ok then,

before call it a night let me add a few words about the Collisions.

Now that Farseer source is in Torque 2D project we've got a fully integrated collision system... how so? Well, have a look to the two parameters geometry1 and geometry2 you got in the collision delegate: now they have a new property called Owner... is the T2DSceneObject owning the colliding objects! Now you can retrieve those and do your usual stuff :)

Have you noticed that the collision delegate has to return a boolean value? If you return True the simulator goes ahead processing the collision to generate the dynamics. If you return False the simulator clears the collision so the objects just pass through each other ignoring any dynamics. Kinda cool :)

And now... here's the video on Ron's last addition: polygonal collision using a texture as shape.

About this, let me add another info: the collision texture must be in Color format, not DxtCompressed: Farseer isn't able to manage Dxt compression so to avoid crashes be sure to use the Color format for those textures used as collision shape (the format can be set in VS expanding the Content Processor in the texture's property pane).

#146 Collision categorization.......so close. ;)

I've had some really good results using the Torque X native object types to define object collision categories.

It looks like it will be a pretty seamless integration.

Stay tuned!

[UPDATE] - I'm having Pino take a look at this work because a second pair of eyes never hurts. With the differences in timezone it's a little tough. We're almost there verifying the logic...then I'll post some usage instructions here after I submit the code change. This will most likely not go in until tomorrow evening.

--RB

#147 I have a couple problems...

My "Box" Car

In the above picture the "wheels" are geom attached to a non geom "box" using revolute joints. However, I would like the box to be able to be geom so that if it falls over it wont go through the ground. If I make the box geom the wheels are relocated because they can no longer be on top of the box. Is there a way to make this work as pictured?

This brought me to what I thought would be an alternate solution, but it also failed. I decided to mount another object with geom to the box (basically turning the box into a frame, wheels on bottom, new object as the car body up top). After some testing this is what I found. Geom can mount to geom, non geom can mount to geom, but geom can NOT attach to non geom (of course the one making the most sense to me doesn't work). Is this a bug?

P.S. This "Box" car is so fun to drive, I have it all setup with some nice controls(Left trigger break, Right trigger gas, Left stick for balance control).

#148 Okay all...collision categorization is in the online repository and appears to be working seamlessly using the Torque Object Types that we are familiar with using from the stock Torque X configuration.

The most notable changes will be FSGeomComponent. You will see that there are 2 new properties exposed to TXB. The first one is CollisionGroup and the default value is 0. The second one is CollidesWith and it accepts TorqueObjectType values.

Basically the collision groups are the toughest thing to wrap your head around because there's a case where the behavior is different than in all other cases.

Here are the rules for collisions:

1. If a scene object does not have collisions enabled, it will not collide with other objects.

2. When 2 bodies meet in the Farseer simulation, they are evaluated such that if there is an intersection between one of the object's ObjectTypes and the other object's CollidesWith set, then a collision will be ATTEMPTED. The evaluation DOES NOT HAVE TO BE MUTUAL. IE if Obj1 collides with Obj2 then the collision is ATTEMPTED, even if Obj2 does NOT collide with Obj1.

3. I used the word ATTEMPTED above because while point #2 describes the base rule for collision processing, the collision groups can override that rule. If the objects are both in group 0 and a collision occurs, the attempt will be successful and the collision will take place in the physics simulation.

4. This is where it gets strange. If Obj1.CollisionGroup is equal to Obj2.CollisionGroup but the CollisionGroup is NOT equal to 0, then the collision attempt fails. In short, objects in the same NON-ZERO collision group will never collide, regardless of whether or not rule #2 is satisfied. This can be used for disabling friendly fire. If "bad guys" are in group 1 and "good guys" are in group 2, then "good guy bullets" can be placed in group 2 as well. That way when a good guy bullet hits a good guy, this rule kicks in and stops the collision.

5. If Obj1.CollisionGroup is NOT equal to Obj2.CollisionGroup and NEITHER of the objects is in group 0, then a collision will occur when condition #2 is satisfied.

Read this post...then read it again. :)

Once you wrap your head around it...it starts to make sense. After this post, I will put up another set of test cases that I ran to validate the implementation. Each case gives a pretty clear indication of how the 2 objects were configured, whether or not a collision should be expected, and why a collision should or shouldn't occur.

Hope this helps...
--RB

#149 As promised...run through these different permutations, and you should get a good idea of how to configure your collisions:

Collision Group 0 test:

1. This setup results in a collision because both objects are in group 0 and each is set to collide with everything:

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith empty (which means collides with everything) / CollisionGroup = 0
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith empty (which means collides with everything) / CollisionGroup = 0

2. This setup also results in a collision because Obj2 collides with everything:

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith = "Green" / CollisionGroup = 0
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith empty (which means collides with everything) / CollisionGroup = 0

3. This setup does NOT result in a collision because each object only collides with objects of its own type (Obj1/Green does not collide with Red and Obj2/Red does not collide with Green)

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith = "Green" / CollisionGroup = 0
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith = "Red" / CollisionGroup = 0

4. This setup results in a collision because each object only collides with objects of the other type (Obj1/Green collides with Red and Obj2/Red collides with Green)

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith = "Red" / CollisionGroup = 0
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith = "Green" / CollisionGroup = 0

#150 Same 4 tests below but with BOTH objects in collision group 1.

5. This setup does NOT result in a collision because both objects are in the same non-zero collision group and are, therefore, not ALLOWED to collide:

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith empty (which means collides with everything) / CollisionGroup = 1
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith empty (which means collides with everything) / CollisionGroup = 1

6. This setup does NOT result in a collision because both objects are in the same non-zero collision group and are, therefore, not ALLOWED to collide:

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith = "Green" / CollisionGroup = 1
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith empty (which means collides with everything) / CollisionGroup = 1

7. This setup does NOT result in a collision for 2 reasons. The objects only collide with THEIR OWN type not the OTHER type (see description for test #3) and because they are in the same non-zero collision group.

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith = "Green" / CollisionGroup = 1
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith = "Red" / CollisionGroup = 1

8. This setup does NOT result in a collision because both objects are in the same non-zero collision group and are, therefore, not ALLOWED to collide:

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith = "Red" / CollisionGroup = 1
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith = "Green" / CollisionGroup = 1

#151 Same 4 tests below but with Obj1 in CollisionGroup 1 and Obj2 in CollisionGroup2

9. This setup results in a collision because both objects collide with everything and they are in different collision groups:

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith empty (which means collides with everything) / CollisionGroup = 1
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith empty (which means collides with everything) / CollisionGroup = 2

10. This setup results in a collision because Obj2 collides with everything, and the objects are in different collision groups:

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith = "Green" / CollisionGroup = 1
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith empty (which means collides with everything) / CollisionGroup = 2

11. This setup does NOT result in a collision because each object only collides with objects of its own type (see test result for test #3):

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith = "Green" / CollisionGroup = 1
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith = "Red" / CollisionGroup = 2

12. This setup results in a collision because each object only collides with objects of the other type (see test result for test #4):

• Obj1 - SceneObject.ObjectType = Green / CollisionsEnabled / CollidesWith = "Red" / CollisionGroup = 1
• Obj2 - SceneObject.ObjectType = Red/ CollisionsEnabled / CollidesWith = "Green" / CollisionGroup = 2

#152 @Aaron...now there is a way to do what you want! :)

Read the last 3 posts. Basically, what you want to do is put all 3 of those entities...2 wheels and a box in the same CollisionGroup, but MAKE SURE you do NOT use group 0.

Set all 3 of those to collision group 1, and you should get the result you want.

You will need the latest version of the code to set the collision group.

--RB

#153 I should have waited an extra 5 minutes to see your update :-) Thanks Ron :-) This is even more exciting now!

This will definitely fix my issue, but what about the mount issue, not that I'm going to use it, but is that a bug that should be addressed?

#154 @Aaron...I'm not quite sure what you mean by "mount" because Torque X has a native version of object mounting which is really not taken into account when using Farseer physics.

If you mean "mount" in the Torque-native sense, then, while I wouldn't call it a bug...I would openly admit it's an area that we have not covered yet that will need some special consideration. We'll call that "unsupported" for now. ;)

If you mean mount in the sense of using Farseer joints to connect to objects, then you have to keep in mind that joints apply to bodies and not geoms. Geoms make the bodies substantial and the physics take over at that point...so 2 substantial bodies cannot occupy the same space at the same time...so that might be what you're seeing.

Also...it COULD be a bug in the Farseer integration code OR in the Farseer engine code itself. Maybe if you can post a video of the results...it might be helpful.

But for now...you can solve your problem by updating your code and grouping your objects in a meaningful way.

Post your results...and let us all know if the new additions fixed your problem!

--RB

#155 Torque-native sense, "unsupported" sounds good :-)

The new collision groups worked great for my box car!

#156 @Aaron...I think in the next few days the dust will settle around the current level of integration between TX and Farseer. With the collision categorization in the code base...I'd say we've got a fairly well integrated product here.

What will come next are those add-ons like object mounting and things of that nature that are not inherent to the physics, but have to be handled in a special way by the physics code.

I suspect we will end up using Farseer joints to accomplish mounting of one Farseer body to another. Technically...much of that integration is already supported by configuration through the components...but in order for it to "feel" natural...we'll have to get a tighter link established between Torque Link Points and the Farseer joint components.

Basically, what you're accomplishing with your box car is not very different from object mounting...it's just configured differently. We'll have to unify that experience in the next few passes of the Farseer integ.

Hope that makes sense...
--RB

PS - Out of curiosity...how are you getting the car to "drive?" Are you applying a rotational force to the wheels, or are you simply moving the box by changing its velocity? What's your technique here?

#157 @Ron: I'm using the right trigger to apply rotational force to the wheels, my first game is going to be a time trial type game, but also want it to be a seamless semi-story based game with a twist of puzzles and enemies at the same time. I need to find a good artist willing to work for royalty pay.

#158 @Aaron...sounds cool man...applying the force directly to the wheels is probably the most physically interesting way to move the car.

Did the latest updates give you what you needed to address your mounting problem?

--RB

#159 The mounting via Farseer works just perfectly thanks to Ron's last addition :) I'm producing a video with a cart and some mechanics to show how well it works ;)

#160 Here I am again :) Enjoy this short demo of a wheeled cart and basic mechanics ;)