matrix question
Author
hello everybody. please dont flame this simple question, im just beginning direct3d. i have finally been able to put a cube thru the pipeline and make it appear on the screen. i go thru all the transformations and everything. my question is really not about how to do it, but why. i understand how to use matrices very well in a non directx way. because im new, i dont see the advantage of using matrix multiplication to translate something from model to world space. wouldnt it just be easier to add the amount to translate to each of the vertex''s components? again, i understand how to do it, just not why. thanks in advance.
By changing the matrix, you can reuse the same vertex buffer for multiple objects, and you can animate the object without touching the vertex buffer.
Examples:
1)You could have two cubes, one centred at (0,0,0) and one at (20, 0, 0). To do this you render the same vertex buffer, but change the matrix between rendering the cube.
2)If you apply a changing matrix each frame, you can get the cube to move, rotate, shrink, distort etc.. WITHOUT touching the vertex buffer.
Not touching the vertex buffer is very important for speed. The drivers can then keep the vertex data on the video card and not have to touch them again. In general you want to avoid locking the vertex buffer as much as you can and declare the usage as static.
James
Examples:
1)You could have two cubes, one centred at (0,0,0) and one at (20, 0, 0). To do this you render the same vertex buffer, but change the matrix between rendering the cube.
2)If you apply a changing matrix each frame, you can get the cube to move, rotate, shrink, distort etc.. WITHOUT touching the vertex buffer.
Not touching the vertex buffer is very important for speed. The drivers can then keep the vertex data on the video card and not have to touch them again. In general you want to avoid locking the vertex buffer as much as you can and declare the usage as static.
James
Author
thanks for the reply. i get what you're saying, but my question i guess is wouldnt three addition operations be less costly than the matrix multiplication? or am i missing something here. i mean, you could still keep the original buffer untouched and just translate it with addition instead.
[edited by - qbranch on August 16, 2003 3:10:47 PM]
[edited by - qbranch on August 16, 2003 3:10:47 PM]
Locking vertex buffer = expensive
And really, how many objects in your world are going to have less than 10 vertices?
And really, how many objects in your world are going to have less than 10 vertices?
Author
i dont mean that you would actually lock the buffer myself and then change the values. i mean wouldnt be easier for direct3d to do this underneath. bear with me, i have a hard time explaining things. forget that there is hardware acceleration for a minute. forget that directx does all this for us. would just the operation of addition to translate an object be quicker than the operation of the matrix multiplication, which ends up being addition and multiplication? anyone understand my babble?
[edited by - qbranch on August 16, 2003 3:26:22 PM]
[edited by - qbranch on August 16, 2003 3:26:22 PM]
Perhaps, but DirectX will (if it can) get the graphics hardware to do the math, ever heard of Hardware TnL? This is it. The GPU is designed to work in parallel (SIMD operations).
This kind of thing is why programmable graphics cards are becomming popular. With a vertex program, you can do exactly what you want, you can change the way the vertices are transformed in the pipeline, to consist of just the additions.
James
This kind of thing is why programmable graphics cards are becomming popular. With a vertex program, you can do exactly what you want, you can change the way the vertices are transformed in the pipeline, to consist of just the additions.
James
Sure, you can handle translations that way. But then, how do you handle rotations? These can usually only be done as matrices.
Now, consider the following transform : you translate, then rotate.
If you store translations as matrices, this transform is represented by a matrix, so all you have to do is
- compute this matrix
- multiply each vertex by it
If you store translations as vector sums, then for each vertex you will have to :
- add the translation vector
- multiply the matrix
so you''ll have 1 add 1 matrix product instead of only 1 matrix product. And if you translate, then rotate, then translate, etc... you''ll have a whole load of transforms to apply to each vertex instead of just transforming it by the product of all matrices.
Now, consider the following transform : you translate, then rotate.
If you store translations as matrices, this transform is represented by a matrix, so all you have to do is
- compute this matrix
- multiply each vertex by it
If you store translations as vector sums, then for each vertex you will have to :
- add the translation vector
- multiply the matrix
so you''ll have 1 add 1 matrix product instead of only 1 matrix product. And if you translate, then rotate, then translate, etc... you''ll have a whole load of transforms to apply to each vertex instead of just transforming it by the product of all matrices.
Author
ok, i think i get it. so its not really the translation that requires the matrix, it just all the other trasformation do. it kind of makes more sense when you put another transformation in it, i was only thinking of transtlation.
Even if you were only doing translation AND your camera was only doing translation, you''d still multiply everything by a projection matrix before it got to the screen. The view and world and projection matrices can be folded into one, meaning that the translation is basically free.
//no translation
for (a whole bunch of vertices)
screenTransformedVertex = Vertex * ProjMatrix
//translation
bigmatrix = projectionmatrix * translationmatrix
for (a whole bunch of vertices)
screenTransformedVertex = Vertex * bigmatrix
(my multiplication order might not be correct - I''m not thinking about it too hard)
//no translation
for (a whole bunch of vertices)
screenTransformedVertex = Vertex * ProjMatrix
//translation
bigmatrix = projectionmatrix * translationmatrix
for (a whole bunch of vertices)
screenTransformedVertex = Vertex * bigmatrix
(my multiplication order might not be correct - I''m not thinking about it too hard)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement