Sign in to follow this  

World Space vs. Object Space and Inverted Matrices

This topic is 3898 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, suppose I have an object's center in world space and a rotation. Furthermore I have a light position in world space. Now I want to know the vector between any of the objects vertices and the light. I could either transform the vertex into world space or transform the light into object space. From there on the results should be the same. Have I got this right? Here is a little test (I used d3dx to make sure there is nothing wrong with my math code):
	D3DXVECTOR4 objPos(3.0f, 4.0f, 0.0f, 1.0f);
	D3DXVECTOR4 lightPos(12.0f, 8.0f, 0.0f, 1.0f);

	D3DXVECTOR4 vertex(1.0f, 1.0f, 0.0f, 1.0f);

	D3DXMATRIX translation;
	D3DXMatrixTranslation(&translation, objPos.x, objPos.y, objPos.z);

	D3DXMATRIX rotation;
	D3DXMatrixRotationX(&rotation, 0.2f);

	D3DXMATRIX transformation;

	D3DXMatrixMultiply(&transformation, &rotation, &translation);

	D3DXVECTOR4 vertexT;
	D3DXVec4Transform(&vertexT, &vertex, &transformation);

	D3DXVECTOR4 d0 = vertexT - lightPos;

	D3DXMATRIX transformationInv;
	float det = D3DXMatrixDeterminant(&transformation);
	D3DXMatrixInverse(&transformationInv, &det, &transformation);

	D3DXVECTOR4 lightPosT;
	D3DXVec4Transform(&lightPosT, &lightPos, &transformationInv);

	D3DXVECTOR4 d1 = vertex - lightPosT; 


I expected d0 and d1 to have the same value, but this is not the case. Can somebody enlighten me please. BTW, it did work OK before I introduced the rotation...

Share this post


Link to post
Share on other sites
If you have a model centered at (0,0,0) and rotate it or move it in anyway, it's still described in the world. So I'm not sure how you checked your calculations. I'm assuming your doing some lighting? Normals go through a different matrix I believe.

Share this post


Link to post
Share on other sites
Hm, let me try to make myself clear.

The object is described in world space. So is the light. (This is not about lighting, just an example)

The object's vertices however are described in Object space.

Now, I can either transform the vertices into world space OR transform the light into object space. Am I right?

So this is what I thought:

(Vertex in World space) - (Light in World space) == (Vertex in Object space) - (Light in Object space)

I can't get it to work though...

Share this post


Link to post
Share on other sites
Generally, the light is transformed into model space once rather then transforming every vertex into world space. But you said this was only an example so that may not be relevant.

Anyway,

(Vertex in World space) - (Light in World space) = (vector in world space)
(Vertex in Object space) - (Light in Object space) = (vector in object space)

(vector in world space) != (vector in object space)

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
Generally, the light is transformed into model space once rather then transforming every vertex into world space. But you said this was only an example so that may not be relevant.

Anyway,

(Vertex in World space) - (Light in World space) = (vector in world space)
(Vertex in Object space) - (Light in Object space) = (vector in object space)

(vector in world space) != (vector in object space)

Aha, that makes sense.

Its just, that in another thread someone told me, it doesn't matter whether I use a world space or object space vector to make a cube texture lookup. But the visual results did quite obviously differ. But this explains things I guess. I wonder how it could work for him though.

Thanks for the explanation!

Share this post


Link to post
Share on other sites
Quote:

Its just, that in another thread someone told me, it doesn't matter whether I use a world space or object space vector to make a cube texture lookup. But the visual results did quite obviously differ. But this explains things I guess. I wonder how it could work for him though.


If the origin of the object space is located in the origin of the world space and the basis vectors of the world space and object space point in the same direction, then it wouldn't matter.

But with cube mapping the thing is that they are translatory independent. So you only have to ensure that your object space has the same orientation as the world space to get the same result. That's the reason why standard cube mapping cannot be used for local reflections.

Share this post


Link to post
Share on other sites
Quote:
Original post by KreK
So you only have to ensure that your object space has the same orientation as the world space to get the same result.

Well, that is impossible if I want my objects to move around and stuff, isn't it?

Share this post


Link to post
Share on other sites
With static cubemapped reflections such as from skyboxes, you can translate your object however you want as long as its object space has the same orientation as world space. The resulting reflection will be the same whether you sample cubemap with object space or world space normals because in this particular case normals in both spaces will have the same direction.

Share this post


Link to post
Share on other sites
Quote:
Original post by B_old
Well, that is impossible if I want my objects to move around and stuff, isn't it?

In fact a position vector is both rotational and translational dependent. A direction vector is rotational but not translational dependent. That can be seen e.g. from matrix vector product using homogeneous co-ordinates. Vertex position and light position are obviously position vectors. The difference of 2 position vectors is a direction vector.

Hence it is important to compute the difference of both positions in one co-ordinate frame. The result will then be given in that frame, too. As long as you move the light and/or mesh around (pure translation) it doesn't matter which co-ordinate frame you use, the resulting direction vector's co-ordinates will be the same in every frame. But as soon as rotation comes into play, the resulting vector's co-ordinates will differ with the frames due to the rotational dependency.

Share this post


Link to post
Share on other sites

This topic is 3898 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this