What exactly is the difference between the local and worldPosition attributes?

The same with the local and worldOrientation attributes as well, what is the main difference when the operative word in the front is switched to ‘Local’ as opposed to ‘World’

I’m asking this because in a regular use scenario of setting the location and orientation of the object, there seems to be not much in the way of a difference, you might expect that changing the localPosition on the X-axis for example would move the object along its local axis (like pressing the ‘X’ key twice to move an object in the 3D view), but changing it moves the object along the global Z-axis instead thus doing the same thing as changing the worldPosition, that is the reason while I’m not really able to get if there’s a difference and why I would want to use the local attribute instead of the world one.

So what is the difference between these two position and orientation types, and why do they not move the object along their local axes in terms of position and orientation, because for one thing, if they did that then it would make an whole basket of certain gameplay mechanics much easier, I’m just wondering because right now it seems there’s not much a difference in terms of how they can be applied.

1 Like

Afaik, world space coordinates are the usual coordinates, if you have a truck it moves on these coordinates, if there’s a physical box on the road that gets bumped by the car it also moves on those coordinates, even if it falls over the truck and gets carried by it.

Local coordinates makes reference to the coordinates when within an object for example:
-if your truck is in position 0,0,0, and both rotation and scale are 0,0,0, then the local coordinates will match whenever you enter on edit mode, if the box is part of the truck and is over the truck, say 0,0,1, it will match world position.

-BUT if you drive around (notice the box is part of the truck so can’t be a independant physical object), the world position of the truck will change, but the local position of the box is unnafected, it is STILL on 0,0,1.

-This is also true if you parent the independant box to the truck, the truck will move and the box follow, but the box will still be on 0,0,1 in World space coordinates, because when parented, it turns into a local space coordinates. If you don believe this last one do the following: in 0,0,0, parent a sphere to a box, move the box and then unparent the sphere, that alone will make the sphere to snap back to the initial position.

If you create an object that moves along it’s local x-axis, it will move in a different direction depending on rotation. World x-axis? It will move in one direction regardless of orientation.

If you have an object and have it spin around it’s x-axis, it will rotate along that axis no matter what orientation. World x-axis? It will only spin around the world x-axis.

To test the orientation bit (because it doesn’t sound that much different) add two actuators one to rotate the object along the z-axis(make this one local) and one to rotate the object along the x-axis (make this one world). It doesn’t matter how you trigger them. Start the game and play around with rotating the object. Now change the z rotation to world and you’ll see the difference.

I have only recently understood what is localPosition
I think it was best to call childrenPosition
only works for objects that are parent to

I read that they want to clean the modules confused, I think you need it.

if object is a shot in the north-east, and you want to go straight ahead (with respect to its rotation) must use applyMovement ([0,1,0], 1)
but this definition does not work within the script, but only when it comes out.
same thing for applyRotation

I hope they do a good job!
I wish there was a separate module that applies only to movements, so that everything is clearer.

hello

object space:

  • coordinates relative to the object’s origin and transformation
    local space
  • coordinates relative to the object’s parent’s origin and transformation
    world space (or scene space)
  • coordinates relative to the scene’s origin and transformation

camera space

  • coordinates relative to the camera’s origin and transformation

It is always possible to transform a vector from one space into another as long they have a relationship. (You might loose precision while transforming).

Special cases:
object space = local space (because all vertices are relative to the object center in the BGE)
no parent -> implicit: parent = scene -> local space = world space

All transformations can be expressed as 4x4 matrizes. This makes it very easy for the 3D engine to work with them.