Well my proc is doing everything for a object, starting with checking a boundary volume, breaks outta loop, if its on its way to use polys outside screen, even an option to read meshes or create meshes, rotate and all transforms, and it handles several coordinates in parallel

I first need to reorganize its data and rewrite my messy experimental code

I think if I design the data right, I can modify it to call itself recursively, that way climb up and down the hierarchy tree until finished

I first need to reorganize its data and rewrite my messy experimental code

I think if I design the data right, I can modify it to call itself recursively, that way climb up and down the hierarchy tree until finished

I'm to assume that at the moment you have some kind of list or array of objects, yes? Something like I used in the TerrainDemo for objects?

hello,

mmm sorry if i sound i little insistent :oops: but......would someone please help me with my problem?

thanks

mmm sorry if i sound i little insistent :oops: but......would someone please help me with my problem?

thanks

**gallo**, wasn't the solution given to the rotation problem? The solution is to translate the object to center, rotate, then translate back. Or was there another problem? Could you restate maybe to help clarify - I've reread the thread and don't quite understand.

hello bitRAKE,

in theory the problem was solved there, but if you download the last test program that i posted, you'll see that i use the method that they gave me, but it doesn't work how i thought, or problably i didn't use the method the right way?

thanks

in theory the problem was solved there, but if you download the last test program that i posted, you'll see that i use the method that they gave me, but it doesn't work how i thought, or problably i didn't use the method the right way?

thanks

Sorry, for my lame art, but my tools here are limited. I've outlined the steps based on your explaination and replies. I'll check out your proggie when I get home.

(later at home...)

I might be wrong, but I think you just have to multiply the matrix the other way around. Matrix multiplication is not commutative (i.e. A * B <> B * A ). The order of the multiplication is

(later still...)

Okay, I reversed the order in the final multiply and it worked.

(later at home...)

I might be wrong, but I think you just have to multiply the matrix the other way around. Matrix multiplication is not commutative (i.e. A * B <> B * A ). The order of the multiplication is

*very*important!(later still...)

Okay, I reversed the order in the final multiply and it worked.

`invoke D3DXMatrixMultiply,addr matrix1,addr matrix2,addr matrix1`

hello bitRAKE,

i've done what you told me, but what now happends is that the object rotates relative to the world's origin and not to its origin, and the object doesn't move how i thought, like a space ship moves through the space...is this possible?

thanks

i've done what you told me, but what now happends is that the object rotates relative to the world's origin and not to its origin, and the object doesn't move how i thought, like a space ship moves through the space...is this possible?

thanks

everything is possible :)

Think carefully about the order of operations you want.

You really should be rotating the object while it's still at world zero (origin of object and world coincide), and having rotated it, then translate it into position in the world... if you do it the other way, you will rotate about the world origin, which isn't what you want.

Now having decided on the order of operations (rotate, then xlate) we simply need to make sure our concatenated matrix (our final combined "object matrix") has been concatenated in the right order.

I'm pretty sure that you need to do it backwards, that the last thing you mix into the matrix will be the first thing applied... don't quote me on that, but I've said it more than once and noone has kicked me yet :tongue:

Think carefully about the order of operations you want.

You really should be rotating the object while it's still at world zero (origin of object and world coincide), and having rotated it, then translate it into position in the world... if you do it the other way, you will rotate about the world origin, which isn't what you want.

Now having decided on the order of operations (rotate, then xlate) we simply need to make sure our concatenated matrix (our final combined "object matrix") has been concatenated in the right order.

I'm pretty sure that you need to do it backwards, that the last thing you mix into the matrix will be the first thing applied... don't quote me on that, but I've said it more than once and noone has kicked me yet :tongue:

hello,

well i really don't know what's happening, it looks like i don't get something...it should be working but it doesn't, i've tried all the possible combinations of rotation in X, Y and Z and translation in X, Y and Z (all with matrices), but what i get are just two things: the object moves straight forward and doesn't go neither up nor down nor left nor right if i rotate it in any axis, and the object moves up, down, left or right and it moves forward, but it rotates relative to the world's origin...so i don't know what's happening, i've followed the advices of EvilHomer2k, and Scronty, and even bitRAKE said that it worked fine when he changed the multiplication order of the translation and rotation matrices, but it wasen't what i thought...or probably i haven't made my self understand...well what i'd like is more or less that an object, in this case a cube, which is going to the north (forward) in the space will rotate to the left if i press the left key and then it will start to go to the north-west (more or less), then if i press the down key that it'd go to the north-west and down...just like a real space ship, i don't know if that can be done by the matrices method you have pointed me...but if not, i'd like any type of advice

this is what i have until now...i left it in the more logical way i found

thanks for your atention :alright:

well i really don't know what's happening, it looks like i don't get something...it should be working but it doesn't, i've tried all the possible combinations of rotation in X, Y and Z and translation in X, Y and Z (all with matrices), but what i get are just two things: the object moves straight forward and doesn't go neither up nor down nor left nor right if i rotate it in any axis, and the object moves up, down, left or right and it moves forward, but it rotates relative to the world's origin...so i don't know what's happening, i've followed the advices of EvilHomer2k, and Scronty, and even bitRAKE said that it worked fine when he changed the multiplication order of the translation and rotation matrices, but it wasen't what i thought...or probably i haven't made my self understand...well what i'd like is more or less that an object, in this case a cube, which is going to the north (forward) in the space will rotate to the left if i press the left key and then it will start to go to the north-west (more or less), then if i press the down key that it'd go to the north-west and down...just like a real space ship, i don't know if that can be done by the matrices method you have pointed me...but if not, i'd like any type of advice

this is what i have until now...i left it in the more logical way i found

thanks for your atention :alright:

Your moving object needs to keep some variables:

Position. You will need a 3D vector to store the position in the world that your object is located (the object's origin is it's handle for positioning).

Rotation. It's common to keep the object rotation as per-axis angular rotations, but the choice is yours, as long as you can produce a rotation matrix from it.

Direction. This is which direction, and what "velocity", your object is moving. It has nothing to do with the Rotation !! It's common to keep this as a 3D vector, we can imaging the vector representing a 3D arrow, with the length of the arrow indicating the "velocity".

Note that the direction your object is travelling has nothing to do with the object's orientation (rotation) in space. If you want the object to neatly veer to the left or right, then you simply need to ensure that the object's rotation is dictated by the direction it is travelling in... find a way to obtain a rotation matrix implied by a vector :) Now hook your keyboard controls for turning left and right to modify slightly the direction of travel (the direction vector itself can be rotated ;) ) and let the rotation be deduced and applied in realtime based on the direction.

The advantage of the described setup is that if you want to make the object spin crazy out of control, you only have to force the object's rotation values instead of deducing them from the direction vector.

Of course, there's more than one way to do anything :)

Position. You will need a 3D vector to store the position in the world that your object is located (the object's origin is it's handle for positioning).

Rotation. It's common to keep the object rotation as per-axis angular rotations, but the choice is yours, as long as you can produce a rotation matrix from it.

Direction. This is which direction, and what "velocity", your object is moving. It has nothing to do with the Rotation !! It's common to keep this as a 3D vector, we can imaging the vector representing a 3D arrow, with the length of the arrow indicating the "velocity".

Note that the direction your object is travelling has nothing to do with the object's orientation (rotation) in space. If you want the object to neatly veer to the left or right, then you simply need to ensure that the object's rotation is dictated by the direction it is travelling in... find a way to obtain a rotation matrix implied by a vector :) Now hook your keyboard controls for turning left and right to modify slightly the direction of travel (the direction vector itself can be rotated ;) ) and let the rotation be deduced and applied in realtime based on the direction.

The advantage of the described setup is that if you want to make the object spin crazy out of control, you only have to force the object's rotation values instead of deducing them from the direction vector.

Of course, there's more than one way to do anything :)

hello EvilHomer2k,

what kind of units should i use in the Direction Vector, i mean, what does that vector store? the angle of the movement of the object or the position to which is moving; and having the direction and position vector how can i deduse the rotation vector, and something more: suppose that i get the direction and actual position of the object, now, having that, how can i calculate the new position of the object??

thanks :alright:

what kind of units should i use in the Direction Vector, i mean, what does that vector store? the angle of the movement of the object or the position to which is moving; and having the direction and position vector how can i deduse the rotation vector, and something more: suppose that i get the direction and actual position of the object, now, having that, how can i calculate the new position of the object??

thanks :alright:

The Direction Vector is a 3d vector, ie 3 floats, for X, Y, Z

What you should realize about the Direction Vector is that it is a "pure vector", no matter what it contains you should assume it always starts at 0,0,0 (regardless that your position is not 0,0,0) - I said to imagine that it is an arrow, now imagine it is an arrow in 3D, starting at 0,0,0 and ending at (xfloat, yflaot, zfloat) - this arrow is pointing in a direction, yes? :)

Some people like to "normalize" the direction vector so that its 3D LENGTH is ONE (retaining the direction, by scaling the x,y,z values all at once so the largest axial value = 1.0f) but thats totally up to you.

Now why don't we keep a direction vector based on our current position? Because we don't need to - the direction vector can simply be added to the position at the last moment, if you want that.

So.. direction is not related to position, both are kept as a "3D vector", but position xyz values are absolute values in the world, whereas direction xyz values simply imply a direction from 0,0,0 (which is actually the classical use of a vector, not simply a coordinate but an arrow).

Example direction vectors: x0y1z0 is straight up (if Y+ is up)

X0Y0.5Z0.5 is forwards, tilted up at 30 degrees (if y+ is up and z+ is depth)

What you should realize about the Direction Vector is that it is a "pure vector", no matter what it contains you should assume it always starts at 0,0,0 (regardless that your position is not 0,0,0) - I said to imagine that it is an arrow, now imagine it is an arrow in 3D, starting at 0,0,0 and ending at (xfloat, yflaot, zfloat) - this arrow is pointing in a direction, yes? :)

Some people like to "normalize" the direction vector so that its 3D LENGTH is ONE (retaining the direction, by scaling the x,y,z values all at once so the largest axial value = 1.0f) but thats totally up to you.

Now why don't we keep a direction vector based on our current position? Because we don't need to - the direction vector can simply be added to the position at the last moment, if you want that.

So.. direction is not related to position, both are kept as a "3D vector", but position xyz values are absolute values in the world, whereas direction xyz values simply imply a direction from 0,0,0 (which is actually the classical use of a vector, not simply a coordinate but an arrow).

Example direction vectors: x0y1z0 is straight up (if Y+ is up)

X0Y0.5Z0.5 is forwards, tilted up at 30 degrees (if y+ is up and z+ is depth)

hello EvilHomer2k,

ok, with your explanation i've done the next test program, what i do is just to take in to count the position and direction vectors, am i using them correctly?, and how can i calculate the rotation from the direction and position vectors?

thanks

ok, with your explanation i've done the next test program, what i do is just to take in to count the position and direction vectors, am i using them correctly?, and how can i calculate the rotation from the direction and position vectors?

thanks

Without looking at your source (please forgive me, quite busy these days) to calculate rotation implied by a direction vector, we use the math from "ArcBall" - seen an ArcBall demo? usually used to rotate a single 3d model using the mouse cursor to "drag" the object rotation...

I started to explain the details in this post but decided against it.

Basically we take a 2d vector implied by the mousecursor under drag (from point where mouse button depressed to current location) and we map that 2d vector against a VIRTUAL 3d sphere, so that the 2d coordinate is now a 3d vector that is no larger in 3d length than the radius of the imaginary sphere (radius normally based on screen dimensions)

Now we have a 3d vector which implies a 3d direction (you should wake up now - this is where it relates to you) we next calculate a rotation matrix based on that 3d direction vector - ie, the rotation IMPLIED by the 3d vector... we now ACCUMULATE the rotation matrix we calculated by concatenating it with the "current rotation matrix" for the object. There is a small chance of error here, deal with it if you care enough. We now have an object rotation matrix that changes in realtime with the direction vector. Cool, huh? Want source? See ArcBall as I said earlier... don't like C? Me either :P

Tenacity is a virtue, and you are persistant. I like that.

I started to explain the details in this post but decided against it.

Basically we take a 2d vector implied by the mousecursor under drag (from point where mouse button depressed to current location) and we map that 2d vector against a VIRTUAL 3d sphere, so that the 2d coordinate is now a 3d vector that is no larger in 3d length than the radius of the imaginary sphere (radius normally based on screen dimensions)

Now we have a 3d vector which implies a 3d direction (you should wake up now - this is where it relates to you) we next calculate a rotation matrix based on that 3d direction vector - ie, the rotation IMPLIED by the 3d vector... we now ACCUMULATE the rotation matrix we calculated by concatenating it with the "current rotation matrix" for the object. There is a small chance of error here, deal with it if you care enough. We now have an object rotation matrix that changes in realtime with the direction vector. Cool, huh? Want source? See ArcBall as I said earlier... don't like C? Me either :P

Tenacity is a virtue, and you are persistant. I like that.

Hello Gallo

Let's say you want to rotate your object 45 degrees about the origin,

you can use this formula:

RotateZ = 6.283185307179586232 / (360 / 45) ;360 degrees equals 6.283185307179586232 radians

This piece of code is what I use in my proggies to place all the objects in my 3D-world

ObjectToWorldTransformation proc ScaleX:FLOAT,ScaleY:FLOAT,ScaleZ:FLOAT,RotateX:FLOAT,RotateY:FLOAT,RotateZ:FLOAT, TranslateX:FLOAT,TranslateY:FLOAT,TranslateZ:FLOAT

align 16 ;keep matrices 16-byte aligned as preferred by P4 cpu's.

LOCAL WorldMatrix:D3DXMATRIXA16

LOCAL TransformMatrix:D3DXMATRIXA16

D3DXMatrixIdentity(WorldMatrix)

invoke D3DXMatrixScaling,addr TransformMatrix,ScaleX,ScaleY,ScaleZ

invoke D3DXMatrixMultiply,addr WorldMatrix,addr WorldMatrix,addr TransformMatrix

invoke D3DXMatrixRotationYawPitchRoll,addr TransformMatrix,RotateY,RotateX,RotateZ

invoke D3DXMatrixMultiply,addr WorldMatrix,addr WorldMatrix,addr TransformMatrix

invoke D3DXMatrixTranslation,addr TransformMatrix,TranslateX,TranslateY,TranslateZ

invoke D3DXMatrixMultiply,addr WorldMatrix,addr WorldMatrix,addr TransformMatrix

coinvoke g_pD3DDevice,IDirect3DDevice9,SetTransform,D3DTS_WORLD,addr WorldMatrix

ret

ObjectToWorldTransformation endp

You can leave the "Scaling" stuff out of it when not needed.

Hope this is usefull for you?

Let's say you want to rotate your object 45 degrees about the origin,

you can use this formula:

RotateZ = 6.283185307179586232 / (360 / 45) ;360 degrees equals 6.283185307179586232 radians

This piece of code is what I use in my proggies to place all the objects in my 3D-world

ObjectToWorldTransformation proc ScaleX:FLOAT,ScaleY:FLOAT,ScaleZ:FLOAT,RotateX:FLOAT,RotateY:FLOAT,RotateZ:FLOAT, TranslateX:FLOAT,TranslateY:FLOAT,TranslateZ:FLOAT

align 16 ;keep matrices 16-byte aligned as preferred by P4 cpu's.

LOCAL WorldMatrix:D3DXMATRIXA16

LOCAL TransformMatrix:D3DXMATRIXA16

D3DXMatrixIdentity(WorldMatrix)

invoke D3DXMatrixScaling,addr TransformMatrix,ScaleX,ScaleY,ScaleZ

invoke D3DXMatrixMultiply,addr WorldMatrix,addr WorldMatrix,addr TransformMatrix

invoke D3DXMatrixRotationYawPitchRoll,addr TransformMatrix,RotateY,RotateX,RotateZ

invoke D3DXMatrixMultiply,addr WorldMatrix,addr WorldMatrix,addr TransformMatrix

invoke D3DXMatrixTranslation,addr TransformMatrix,TranslateX,TranslateY,TranslateZ

invoke D3DXMatrixMultiply,addr WorldMatrix,addr WorldMatrix,addr TransformMatrix

coinvoke g_pD3DDevice,IDirect3DDevice9,SetTransform,D3DTS_WORLD,addr WorldMatrix

ret

ObjectToWorldTransformation endp

You can leave the "Scaling" stuff out of it when not needed.

Hope this is usefull for you?

Possibly not - he was asking how to convert a 3d vector into a rotation matrix, where the 3d vector 'implies a rotation'. Basically he wants to convert his Direction vector into an Orientation matrix - so that the object rotation is locked to the direction the object is facing, so that change in direction results in equivalent change in rotation.

I know the ArcBall stuff is beyond him at this point, but he only needs the ass-end of the arcball code, since he already has a direction vector :)

I know the ArcBall stuff is beyond him at this point, but he only needs the ass-end of the arcball code, since he already has a direction vector :)

Why doesn't the rest of the world speaks DUTCH

It would be a lot easier for me to understand. :lol:

You are right EvilHomer2, sorry my mistake.. :oops:

It would be a lot easier for me to understand. :lol:

You are right EvilHomer2, sorry my mistake.. :oops:

I really thought it was worth mentioning that this really is a classic example of a "constraint".

In this case, the 3d orientation of the Object is constrained to the Direction it is about to travel in, so that changing the direction of travel will automatically rotate the object to face the new direction.

Constraints are something that are often used in 3d animation applications in order to automate some of the animation workload.

An example of this I've given previously describes a 3d jetplane which has a constraint placed on the rotation of its landing gear, so that as the jetplane approaches the ground, the landing gear automatically swings out into landing position, and the reverse on takeoff.

If we write code that creates this association, this "constraint", then we don't need to animate our jetplane landing gear, and we may have a number of jetplanes in our airforce :)

Constraints are a rather high level subject as far as I am concerned, but one that should be broached sooner rather than later, and mastered over time.

In this case, the 3d orientation of the Object is constrained to the Direction it is about to travel in, so that changing the direction of travel will automatically rotate the object to face the new direction.

Constraints are something that are often used in 3d animation applications in order to automate some of the animation workload.

An example of this I've given previously describes a 3d jetplane which has a constraint placed on the rotation of its landing gear, so that as the jetplane approaches the ground, the landing gear automatically swings out into landing position, and the reverse on takeoff.

If we write code that creates this association, this "constraint", then we don't need to animate our jetplane landing gear, and we may have a number of jetplanes in our airforce :)

Constraints are a rather high level subject as far as I am concerned, but one that should be broached sooner rather than later, and mastered over time.

hello,

well what i did was to manage the direction vector as EvilHomer2k toldme, like pointing where to go, then i normalize it and finaly i add each value to the new position vector, but what i still don't know is how can i create the rotation vector...and something more, i'd love to see that "constraint" that EvilHomer2k said

thanks

well what i did was to manage the direction vector as EvilHomer2k toldme, like pointing where to go, then i normalize it and finaly i add each value to the new position vector, but what i still don't know is how can i create the rotation vector...and something more, i'd love to see that "constraint" that EvilHomer2k said

thanks

Please try to find and read one or more tutorials on the subject "ArcBall", you will find exactly what you want.

Should you do this and still not understand what is required, I will attempt to explain ArcBall theory in laymans terms, at least as much as relates to the "constraint" I mentioned :)

A constraint is not something you can see, it's just an association made between some values .. for example, your direction of travel is constrained to the normalized direction vector , that is a constraint already... who says you have to move the direction you are facing? YOU do, you enforced this constraint. Your object can't move in any old direction it likes, it HAS to move the way it's facing, because your math and programming forces it to - CONSTRAINS it to do so.

Should you do this and still not understand what is required, I will attempt to explain ArcBall theory in laymans terms, at least as much as relates to the "constraint" I mentioned :)

A constraint is not something you can see, it's just an association made between some values .. for example, your direction of travel is constrained to the normalized direction vector , that is a constraint already... who says you have to move the direction you are facing? YOU do, you enforced this constraint. Your object can't move in any old direction it likes, it HAS to move the way it's facing, because your math and programming forces it to - CONSTRAINS it to do so.