Position/Scale/Rotate Entity
Blitz3D Forums/Blitz3D Beginners Area/Position/Scale/Rotate Entity
| ||
| What order are these commands are applied in "under the hood"? It seems to produce the same result no matter what order they are called... |
| ||
| The result would be the same because Blitz always uses its internal unit size, irrespective of mesh scaling. Imagine 2 spheres, each the same size. One sphere gets scaled to twice the size. Both spheres move forward 1 unit The enlarged sphere is reduced again to its normal size. Both spheres move backwards 1 unit -> The spheres would be in their initial start positions. |
| ||
| Let me give an example to illustrate my question: If I code something like: e = CreateCube() RotateEntity e, 0,90,0 PositionEntity e, 1,0,0 I get a cube facing along the positive X axis, that is located at x=1. If I code the following: e = CreateCube() PositionEntity e, 1,0,0 RotateEntity e, 0,90,0 <***fixed typo ^^^^^^^^ supposed to be 90 degrees yaw ***> I *don't* get a cube facing along the positive X axis but located at x=0, z=-1 like you would think if you applied these transformations one at a time to their logical outcome... I get the same result as the previous block of code. So, there is an inherent *ordering* to these 3 calls when used together, PositionEntity, RotateEntity and ScaleEntity, that is independent of what order you call them in... Hence, my question, what is the order they are applied in "under the hood"? I realize that the TurnEntity, MoveEntity, etc., can be used to programmatically build up a sequence of operations on an entity, and that using the Mesh functions can "destructively" alter the coords in the mesh vertices relative to the entity's local coord system... but this one detail doesn't seem to be describe in the docs. It seems that the "fixed" and "automatic" order of these commands for an entity is either: Scale -> Rotate -> Translate or Rotate -> Scale -> Translate ... no matter what order you call these 3 particular commands in. Am I missing something? Thanks and DIA (DOH! In Advance)... Ed |
| ||
| Rotation is relative to the entity's local coordinates, which is really the intuitive way to do it. For example, suppose you are an entity. I tell you to walk forward mile, then turn right 90 degrees. You make the turn 'in place' at your new location. You don't move quarter of the way around a one mile radius circle. |
| ||
| Suppose I tell you to turn 90 degress right, and walk forward a mile... you will end up one mile east, facing east. If I tell you to walk one mile, then turn 90 degrees right, you end up one mile north, facing east. It all depends on the *order* you do these things. However, with these commands, you end up at the same place despite the ordering. To know which place you'll end up, you need to know what order these commands are processed in... right? |
| ||
| If I code the following: e = CreateCube() PositionEntity e, 1,0,0 RotateEntity e, 90,0,0 I *don't* get a cube facing along the positive X axis but located at x=0, z=-1 like you would think if you applied these transformations one at a time to their logical outcome... I get the same result as the previous block of code. The cube won't be located at z=-1 - not sure where you got that from. :) And you won't get the same result as the first block of code as that rotates the cube around the Y axis (yaw), whereas this code rotates around the X axis (pitch) The commands are simply executed in the order you call them. |
| ||
| It was a typo (I fixed it above). |
| ||
| positionentity uses global coords doesn't it. it would be like, "'teleport' one mile north, then turn 90 degrees" versus "turn 90 degrees, then 'teleport' north 1 mile". same thing. its moveentity thats local right? or am i wrong? even then wouldn't it be the same? |
| ||
| Ahhhh... that's the key. PositionEntity is not a normal "transformation" like RotateEntity is. It's being handled outside of the normal chain of multiplied transformations matrices. In my example, if you treat the RotateEntity like a ApplyAnAbsoluteRotationToWorld, then you can see what I was thinking. Once the cube is moved, a rotation would move the cube instead of just rotating it about it's center no matter where it is (rotating an object at x,y,z about it's center is actually a combination of transformation matrices together: translate entity center to world origin - rotate about the about the world origin - translate entity back to original position). |
| ||
| Moveentity moves your entity the way it's facing. If you're facing East, then tell your entity to move forward 100 units, then you'll end up 100 units Eastwards. If you want to move your entity north, while facing East, use TranslateEntity. This moves your entity in a global scape (doesn't care which direction your entity is facing). RotateEntity turns your entity "on the spot", around it's own axis (for a sphere, this would be the centre of that sphere). PositionEntity just takes your entity and plants it down at the given coordinates, no matter how big the entity is, or where it's facing. |
| ||
| My example with 'moving around a one-mile circle' was meant to illustrate how unnatural that type of system would be. It seems more reasonable to have the Entity commands be local to the entity. I find it easier to think of these transformations as operating on the local coordinate system, which is firmly attached to the entity. |
| ||
| You may find MoveEntity and handy for relative (local) movement. All these commands have an optional Global Parameter that can be set to true/false. i.e. MoveEntity entity,x,y,z,GLOBAL_PARAMETER |
| ||
| Er, not all the commands have a global param. MoveEntity doesn't because it implicitly uses local coords - that's what distinguishes it from TranslateEntity. :) |
| ||
| Thanks guys! |
| ||
| Big10p - I meant PositionEntity there :) |
   |