just for the heck of trying something out, i wanted to try and learn how 3D programming works.
pointers to my various questions:
► why are many 3D things all wireframes? is this because of speed?
► how would you know when to shrink an object's size, and how?
This is what I know about polygon vertices:
There are two main descriptions of 3D objects:
- Wireframe: Vertices (3D points) connected with lines
- Polygon: Vertices attached to triangles, which have colors and textures defined for them
Both systems involve vertices. Every time a 3D point is drawn, it is multiplied through a series of 4x4 matrices: the projection matrix (which defines what the view looks like), the view matrix (which defines where the camera is and where it's facing), and the world matrix (which defines any translations made on the object). Various formulas that I don't know define these matrices. This matrix multiplication will turn a 3D point in world space into a 3D point in screen space (screen X, screen Y, screen Z).
Then, depending on the system, the object is drawn. For wireframe, the process is quite simple: for each 3D line, simply draw a 2D line between the two 2D-translated points, ignoring the Z-coordinate entirely. Polygon / hidden surface is a different story: you have to interpolate every point in between and, using a depth buffer or similar construct, determine whether or not to draw the point to the screen.
so texturing of 3D objects would take place during the interpolation of every point in between 3 points? definently sounds like a time muncher.
why does camera position need a 4x4 matrix? why doesnt it just use 3 points to define the position of that?
could you further explain about what the "projection matrix" is used for?
LuxenD wrote:
Yep, does sound a bit like black magic, doesn't it?
LuxenD wrote:
so texturing of 3D objects would take place during the interpolation of every point in between 3 points? definitely sounds like a time muncher.
Application of texturing and lighting is part of pixel shading (the second part of rendering after figuring out where all the vertices map to - aka "vertex shading"), so good rendering engines are optimized to not have to calculate textures for unseen points. But yes - finding out the exact color of only a few pixels is just as expensive as mapping all the points.
LuxenD wrote:
why does camera position need a 4x4 matrix? why doesnt it just use 3 points to define the position of that?
To know everything about the camera, you not only need to know the position, but also the direction it's facing and which way is up, because that is the only unique way to define a camera viewpoint. That is best consolidated into a 4x4 as well to fit with the other operations.
LuxenD wrote:
could you further explain about what the "projection matrix" is used for?
The projection matrix defines the "view frustum" of the camera. Essentially, imagine a pyramid is coming out of your camera, with a bisecting plane close to you and a bisecting plane far away from you. Anything between those planes and inside that pyramid will be seen by your camera, and where they are in the pyramid is proportional to where they will end up onscreen. A projection matrix uniquely defines that pyramid: the ratio of the rectangles, the angle of spread, and where those clipping planes are.
Plotting 3D vertices in orthographic projection is simple:
Code: x = s*(z - cam.z) + x - cam.x
y = s*(z - cam.z) + y - cam.y
where 's' is a scale factor.
Plotting 3D vertices in perspective projection is a bit more difficult...
-------------------
Step 1: Subtract the camera's location from the vertex locationCode: x = x - cam.x
y = y - cam.y
z = z - cam.z
Step 2: Build a rotation matrix from camera's rotation.Code: [ cosZ*cosY | cosZ*sinY*sinX-sinZ*cosX | cosZ*sinY*cosX+sinZ*sinX ]
[ sinZ*cosY | sinZ*sinY*sinX+cosZ*cosX | sinZ*sinY*cosX-cosZ*sinX ]
[ -sinY | cosY*sinX | cosY*cosX ]
Step 3: Multiply the vertex location with the rotation matrix 'r'
Note: [#][#] is [x][y]Code: x = x*r[0][1] + y*r[0][1] + z*r[0][2]
y = x*r[1][0] + y*r[1][1] + z*r[1][2]
z = x*r[2][0] + y*r[2][1] + z*r[2][2]
Step 4: Plot PixelsCode: x = x*z
y = y*z
For the sake of simplicity, I wrote my own equation for building the
camera rotation. It's the same asCode: zRotMatrix * yRotMatrix * xRotMatrix
Unfortunately, I don't know anything about texture interpolation, but I hope this helps out someone
And rather than rotation matrices you might also look into quaternions, which are slightly less efficient computationally, but have numerous other advantages that make them worth knowing. They are even more black magic than the matrices though.
Pseudoprogrammer wrote:
And rather than rotation matrices you might also look into quaternions, which are slightly less efficient computationally, but have numerous other advantages that make them worth knowing. They are even more black magic than the matrices though.
Regardless, if you're making your own 3D engine, using matrices is a must. (I found that out the hard way). They store the up, right, and forward vectors which are used to interpolate pixels between 3 or 4 vertices.
Plus, it's a lot easier to maneuver with matrices.Code: ; Move Right
x += m[0][0];
y += m[0][1];
z += m[0][2];
; Move Up
x += m[1][0];
y += m[1][1];
z += m[1][2];
; Move Forward
x += m[2][0];
y += m[2][1];
z += m[2][2];
Usually with quaternions you do all of your behind the scenes math with quaternions and convert to matrices as the interface with an engine.
There are other drawbacks aside from speed as well when using quaternions, such as not having a roll, only a pitch and yaw.
All these maths are making me want to have a go at writing my own 3d projection equations.
What do you mean? A quaternion can represent anything that a rotation matrix can (using less memory, too).
Pseudoprogrammer wrote:
What do you mean? A quaternion can represent anything that a rotation matrix can (using less memory, too).
except roll. quaternions are locked to an x/y axis
SoulofDeity wrote:
Pseudoprogrammer wrote:
What do you mean? A quaternion can represent anything that a rotation matrix can (using less memory, too).
except roll. quaternions are locked to an x/y axis
[ image ]
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
