PhysicsSetPosition behavior

[Michael_J]

I was doing collision and physics work yesterday and experimented a lot with PhysicsSetPosition. I believe I now understand its behavior and what may be causing people problems when trying to use it.

 

When you use this command to manually move an object from point A to point B a velocity vector is calculated to make this transformation in the physics world. The strength is just a multiplier as to how fast you want to get there--entering a value of 1.0 will fully cover this distance in one frame.

 

The "problem" comes in on the next frame. The velocity that was added is not nulled out, so the object just continues along in the same direction. Probably the perceived functionality of this command is that the object would get to point B and just stop there.

 

My first attempt to handle this was (in pseudo code):

 

if (wantingTOmove){

object->grab current velocity

object->PhysicsSetPosition

object->set old velocity

}

 

The problem here is that by setting the old velocity, in the physics world it effectively cancels the PhysicsSetPosition and the object didn't move at all. My next attempt was:

 

if (wantingTOmove){

object->grab current velocity

object->PhysicsSetPosition

object->UpdatePhysics()

object->set old velocity

}

 

I was hoping UpdatePhysics() would force the object to update to the new position, but this didn't work (so my use of the method was incorrect). My next attempt was successful:

 

if (!objectForcedmove){

if (wantingTOmove){

object->grab current velocity

object->PhysicsSetPosition

objectForcedmove = true

}

}

else{

object->set old velocity

objectForcedmove = false

}

 

What this does is use a Boolean flag that will allow you to move the object on one frame, and then set the old velocity on the next. At this point the object behaved as expected: if the old velocity was 0,0,0 then when the object got to the new location it just stopped there.

 

Now here are my questions:

1. Is this the correct behavior for PhysicsSetPosition (and I assume PhysicsSetRotation), or is it not working as intended?

2. If it is the intended implementation, can a new version of the command be added that will handle this "behind the scenes"?

3. If not, is there a way to force an additional physics update on an object mid-frame so this can all be done in one pass (probably not as the physics runs on its own thread, yes?)?

4. Finally, if using this command makes the object non-collidable (as it seems to--I witnessed my object penetrating walls to get to the new location), then if you had to manually update an object every frame wouldn't it effectively nullify the object to physical collision and reaction?

 

If so then I'd warn people NOT to use it and a rigid body for trying to make their own character controller, as I've seen some mention of. Rather, if you need a RB then you'd probably be better off calculating the required velocity yourself from A to B and applying it to the object via SetVelocity() so as not to interrupt the physics simulation (seems the better way to go?)....

 

Anyway, long post I know. I just thought the information I found might help out others who may be having trouble dealing with this command.

 

Cheers...

[YouGroove]

I also played a lot with physics, here is how i use them

 

Never mix these physics functions depending on what you want to do :

 

- SetPhysicsPosition :

Allow you to each frame make move the object yourself : you calculate position each frame by code than call SetPhysicsPosition() I will override any Velocity or other function called previoulsy

Will not be as clean moving as SetVelocity (my moving steps was not perhaps as good ?)

 

-SetVelocity :

Just call it one time with velocity parameters, and the object will move at constant velocity until you stop it with 0 velocity or calling some PhysicsSetPosition for example

SetVelocity to 0 or other values to diminuish it or stop object.

I use it for bullets, missiles to move them smooth and in a constant speed.

 

PhysicsSetOmega() :

Call it to have a constant object rotation : Similar to PhysicsSetVelocity() , but for the rotation.

 

PhysicsAddForce() :

use it for impact forces or ponctual forces : projectile canon launch, bullet hitting object, explosion impact etc ...

 

PhysicsSetTorque() :

Very similar to AddForce , better use it for ponctual Force that will turn the object like some impact on the side of object that would make object turn and not translate like AddForce()

 

Avoid to mix character controller physics functions : SetInput , GotoPoint with other functions such as PhysicSetPosition or SetVelocity.

 

 

-----------------

 

If so then I'd warn people NOT to use it and a rigid body for trying to make their own character controller, as I've seen some mention of.

 

Well actual character controller using SetInput have two main problems :

- Physics are jittering (a bug and example will be posted very soon)

- Physics collision is fixed in size and shape : what will never workf for games using any size of characters and bosses.

 

I disagree as using SetVelocity for direction and force you can make move very smoothly any Shape physic size collision and without any physic jittering.

[Josh]

Typically if you are using PhysicsSetPosition(), it will be called continously, so when it overshoots the target, it will have forces push it back in the opposite direction, until it settles down.

[Michael_J]

Typically if you are using PhysicsSetPosition(), it will be called continously, so when it overshoots the target, it will have forces push it back in the opposite direction, until it settles down.

 

Yeah, that's exactly what I saw. I just don't think that's what people expect at first. Perhaps worth a mention in the documentation?