Having the camera follow player at rotation point

epoulsen

I've been trying to use orxObject_GetWorldPosition(), orxObjectGetMassCenter, orxObject_GetPivot to find the point on my player object where it rotates (via they physics apply_torque) funtion. The actual point is the centroid of the physics box, but what I end up getting is essentially the upper-left corner of the object.

The end goal is to have the camera follow the player, so the player is always in the center, but since the point I end up with is not the center of the physics model, when the player spins, the camera wobbles around, since the player location is "off center."

Setting a Pivot (event "center") for the graphic _really_ screws things up for my buoyancy calculations, and doesn't actually fix the problem.

iarwain

Well, unfortunately, the only right answer is to have your pivot set correctly with respect to your visuals and then have your physics part expressed correctly with respect to that pivot (which is also the origin of your body's local space).

In the end, the buoyancy calculations should be completely completely independent of the space in which vertex coordinates are expressed and should always yield the correct centroid. If it's dependent from the space, there's something wrong somewhere.

As for the camera following the object, if you don't want any kind of latency and always be perfectly "on spot", I'd suggest setting your object as the parent of your camera, this way you don't have to do any computation on your side.

Lastly, I'm sure you're aware of it, but just in case, the config variable Physics.ShowDebug will display an overlay with all the physics shapes in non-release modes which is pretty handy for debug purposes. You can also issue your own primitive display calls for your own debug needs.

epoulsen

Well, unfortunately, the only right answer is to have your pivot set correctly with respect to your visuals and then have your physics part expressed correctly with respect to that pivot (which is also the origin of your body's local space).

This might be the bit that I'm missing. Is it correct to say that the pivot is the 0,0,0 coordinate of the local space? Sounds like I just need to tweak my .ini numbers correctly. I'm doing it semi-manually because my texture has animation frames, so I need to set coordinates by hand.

In the end, the buoyancy calculations should be completely completely independent of the space in which vertex coordinates are expressed and should always yield the correct centroid. If it's dependent from the space, there's something wrong somewhere.

The centroid is always correct, and actual "simple buoyancy" is correct, but other bits such as drag and lift are way wrong because with an (incorrectly used, in my case) pivot, the physics coordinates are offset, which plays havoc when you're applying a force that's offset. The buoyancy stuff occurs in world coordinates because it relies on the intersection of two fixtures (body parts).

As for the camera following the object, if you don't want any kind of latency and always be perfectly "on spot", I'd suggest setting your object as the parent of your camera, this way you don't have to do any computation on your side.

Problem is that the player object is perfectly still, while the background rotates around it. I want the camera to follow the player, but ignore player rotation.

Lastly, I'm sure you're aware of it, but just in case, the config variable Physics.ShowDebug will display an overlay with all the physics shapes in non-release modes which is pretty handy for debug purposes. You can also issue your own primitive display calls for your own debug needs.

Yes, I even have it bound to a key to toggle. I also set up my own simple debug draw system that helps greatly when debugging force/impulse vectors, and intersecting polygons, etc.

iarwain

epoulsen wrote:

This might be the bit that I'm missing. Is it correct to say that the pivot is the 0,0,0 coordinate of the local space? Sounds like I just need to tweak my .ini numbers correctly. I'm doing it semi-manually because my texture has animation frames, so I need to set coordinates by hand.

Yes, that's correct.

The centroid is always correct, and actual "simple buoyancy" is correct, but other bits such as drag and lift are way wrong because with an (incorrectly used, in my case) pivot, the physics coordinates are offset, which plays havoc when you're applying a force that's offset. The buoyancy stuff occurs in world coordinates because it relies on the intersection of two fixtures (body parts).

Ok, that shouldn't be too bad to fix then. I'm not 100% sure but I believe the forces are applied at the center of mass by default (don't have the code at hand to verify that assertion), which is probably different than the actual origin of the local space (as defined by the pivot), if your "shapes" aren't regular.
The center of mass is only defined by the parts+density that are linked to your body.
Debug-drawing both might help solving your offset issue when applying a force if that's not already what you do.

Problem is that the player object is perfectly still, while the background rotates around it. I want the camera to follow the player, but ignore player rotation.

Even with a parent/child hierarchy, you can still re-apply the background rotation on the camera every frame, which will have the same result as doing all the calculations manually. It's really a matter of taste though, there isn't really a "best" way of doing it.

Yes, I even have it bound to a key to toggle. I also set up my own simple debug draw system that helps greatly when debugging force/impulse vectors, and intersecting polygons, etc.

Ah nice, I'm glad to see you're familiar with those tools then.

epoulsen

Just some closure on this issue. I ended setting the player object as the camera parent, then rotating the camera so the scene remains un-rotated. I had to insert this bit when I received an orxRENDER_EVENT_START, since it seems doing it in Update means that the camera rotation would be set before the physics step and rendering, and would lag by one timestep. While this caused a kinda-cool tilt effect, it wasn't what was desired. Now it's rock stable.

I still haven't resolved the center of rotation issue; Setting pivot=center works fine if I have a simple non-animated sprite.

iarwain

In Scroll there's a CameraUpdate virtual method that was meant for that exact purpose but it might not be called at the right time anymore, since I modified the gameloop for greater CPU/GPU parallelism. I'll check that.

As for your center of rotation issue, I can have a look when I've moved in and gotten my computer back + internet connection, hopefully within 2 weeks.

epoulsen

In Scroll there's a CameraUpdate virtual method that was meant for that exact purpose but it might not be called at the right time anymore, since I modified the gameloop for greater CPU/GPU parallelism. I'll check that.

I'll give it a shot.

As for your center of rotation issue, I can have a look when I've moved in and gotten my computer back + internet connection, hopefully within 2 weeks.

I got this figured out ... just needed to think about it and tweak my numbers.

epoulsen

In Scroll there's a CameraUpdate virtual method that was meant for that exact purpose but it might not be called at the right time anymore, since I modified the gameloop for greater CPU/GPU parallelism. I'll check that.

Just tried it; works perfectly.