why the difference between setangle and rotateTo?

#1 Can't say why they use differing center of rotation - the only difference was supposed to be setAngle() is instant and rotateTo() should rotate the specified amount in the specified time. Looks like a bug to me....

#2 How can I request a fix or can you point me to the code?

#3 Under the hood, rotateTo() calls setAngularVelocity() which sets the angularVelocity of the underlying box2D body. On the other hand, setAngle() simply set's the angle of the body rotated around the center regardless of mass. So the angle applies to the object using the center of the object's bounding box, but the rotational velocity uses the physics which would use the center of mass.

The center of mass is affected by collision shapes that you add to the object that have a density greater than zero. You can check the center of mass using getLocalCenter(). Echo this out in the console. If it's not "0 0" then that's why it's not rotating around the center and there's no bug.

#4 Ah, right - it takes all collision shapes attached into account. I was assuming he only had one, and the center should have been the naive center - but if there are two and one is "heavier" than the other then center of mass will not be obvious to the casual observer. Thanks for the reminder Peter!

#5 I guess my assumption that a collision shape would not have a mass but just create a collision boundary was in error.

Is there a way to make a collision shape that has no mass?

It seems that to have an object with multiple collision shapes throwing off the center of mass a bit odd. But that is just me....

But it does explain why I had to add 3 coll1sion shapes to 1 object to rotateTo properly. Of course I made them sensors only and ignore the collisions with the second and third one.

#6 Multiple collision shapes don't throw off the center of mass - the center of mass is calculated taking all collision shapes into account.

The thing to keep in mind is that a "collision shape" is a physics entity, not just to see if two things intersect, but also to determine the appropriate reaction to a collision (should they bounce, if so how much, etc). See the Box2D documentation - it should clarify somewhat. Collision still needs to take mass into account and I guess the way Box2D handled that was to incorporate all of that into the collision shape.

#7 Maybe I am seeing something different.

Try this.

create a sprite 10-1 ratio (like a pipe)
do not add a collision shape.
rotateTo(90,90) and the sprite will rotate about the center of the sprite.

now add a collision shape 1-1 ratio at 1 end of the pipe
rotateto(90,90) and the sprite will rotate about the center of the collision shape.

now add a second collision shape 1-1 ratio at the other end of the pipe.
rotateTo(90,90) it rotates at the center of the sprite again.

#8 Yes. If there is only one collision shape, its center is the center of mass, since the image itself has none. The Sprite object has no mass - only collision shapes have mass.

#9 So let me see if I got this right.

Sprite has NO mass (unless you surround it with a collision box) yet an angular rotation can be applied to it.

If I want a car front bumper to detect collision and allow me to modify the sprite (crumple the bumper) I need a second collision shape (back bumper) the same size and the same distance from the center in the opposite direction to keep the mass centered.

If I want to shift the center either forward or back - I need to increase the size of the front or back collision shape (into the car).

IMHO - Not the way I would do it but it works. I would make the sprite the mass and the collision shapes apply forces through the sprite's center depending on the how the force hit the collision shape. I would also allow the sprite center to be offset. (i.e. position the center over the car's rear axle and the rotation would be at that point.)

Apples or Oranges - both make juice....

#10 Just set the collision shape to have zero for the density and it won't affect the mass.

%density = 0;
%object.setCollisionShapeDensity(%shapeIndex, %density);

With no mass in the collision shape, the object will behave the way you expect. The object itself does actually have a mass which you can set with setMass().

One other thing to note is that not all shapes use a density to calculate a mass. For instance, EdgeShapes have a hard-coded mass of zero, which makes sense.

#11 Well, would you want to have a sprite that you couldn't rotate unless it also had a collision shape? The current solution offers flexibility, but requires more of the developer. There are several things in T2D and T3D that are not exactly intuitive.

Of course, the source code is in your hands so you can make it behave any way you wish.

#12 @Peter - thanks - that solved my dilemma. I wrongly assumed turning a collision shape into a sensor there would be no mass/density.

@Richard - thanks - I am not trying to reinvent the wheel - just trying to understand how it works. I do not like wobbly tires unless I want them to wobble.

I know that if I read ALL the documentation I would understand more but then the next year would be spent reading and not programming.

#13 lol - I know how that goes - been screwing around with Torque stuff in general for about 11 years now....

Wait - you're just making wheels? The Truck Toy does that quite stupendously.

#14 Actually a tank turret - therefore the rotateTo function but I only wanted to check if the tip of the cannon ran or rotated into something.