FixedAngleJoint vs FixedRotation

Topics: User Forum
Feb 13, 2012 at 3:36 PM

Let's take this code:

Body = BodyFactory.CreateRectangle(World, 20, 10, 1.0f);
Body.BodyType = BodyType.Dynamic;
Body.LinearDamping = 0.2f;
Body.AngularDamping = float.MaxValue;
Body.Mass = 50;

a) Body.FixedRotation = true;
b) JointFactory.CreateFixedAngleJoint(World, Body);

Shouldn't a) or b) achieve the same result?

 

This object is attached to another one through a RevoluteJoint. When I use a), this object doesn't rotate, the other one does; when I use b), this object rotates anyways...

Any idea why?

Feb 16, 2012 at 6:46 PM

I tried both methods in my game and they both kept the upper portion straight while rotating the wheel below. Personally, I use the fixed rotation method rather than creating the fixed angle joint. So I don't know why you are getting that result.

Feb 18, 2012 at 11:00 PM

I still have that; not sure why, but FixedRotation seems to work well.

On question this opens: when you have two objects like what (box + wheel) attached by a joint; which object do you 'handle' for motion, etc? does the linking order (box 1st / wheel 2nd or vice-versa) has any impact?

I found that if I put a linear impulse on the box vs the wheel, I get different results, so I'm trying to track the origin.

Feb 19, 2012 at 12:07 PM

Ya i think the linking order has a huge impact on the the outcome.I dunno which way you did the fixed angle joint fixing ,but i think if you do it in a different order you might get different results .And i think you should put a linear velocity on the wheel if you want it to move( like run) ,if you put a linear velocity on the box it'll be like somebody pushing on your shoulders to make you move ,that is i'm guessing you're trying to make the legendary character model with a wheel and box right?

Feb 19, 2012 at 1:01 PM

yes, trying to move an older game from tile logic to physics and it is a real pain :)

Feb 19, 2012 at 1:05 PM

Hehe true true ...it's like i dont know why this random thing isn't working ,but it used to :D

Feb 20, 2012 at 11:10 AM

yes, pretty much :)

Another issue is that the tile based game has states for everything (idle, running, falling, jumping, etc). These states cannot really be removed because they are used by the input, animation, etc.

Matching a given state to what happens to the character in a parallel world (the physics one) seems easy, but has its complications. An example is standing on the edge of a platform, where the logic would start a timer, play an out of balance character and push the character to fall if the player didn't move away from the edge; With physics it's a bit more complex as the wheel starts to roll by itself on the edge and start the fall; sure, the wheel could be harder to turn, but then it would affect something else.

So the connection between a world that is more discreet (state based tile logic) and the physics is quite troublesome.

Feb 20, 2012 at 3:43 PM

Well you could always raycast to see where are the different parts of your model.Say if its on the edge,the ray cast on on side will be a much smaller distance then the the side that is sorta hanging of the ledge ,so knowing that you could make the wheel harder to turn and start the timer and run the animation when you wish ...something along the those line... hope I made at least some sense

Feb 22, 2012 at 10:19 AM

That's what I've been doing: 2 raycasts on top, 3 on the bottom; works pretty well... until I find the next things that breaks the whole system :)

Feb 22, 2012 at 3:34 PM

Hehe ,but i think that using Farseer will pay off greatly in the end :)

Feb 22, 2012 at 5:46 PM

that's the thinking as well; it allows for a lot of cool things.

I posted my new challenge, from last night, in a new thread (http://farseerphysics.codeplex.com/discussions/341920)