3D - On The Fly!

[stevmjon]

i like helping others. it keeps me on my toes to remember all the theory / maths.

*** i added a new pic to reply #28. it shows a method to visualise cross product calc.

also, there is a dot product pic in reply #2. dot product compares vectors for different uses. come in handy. if 1 vector is perpendicular to an axis, you can usually get away with skipping dot product, otherwise use dot product calc.

well, the video tracking sounds complicated. i haven't gone into this at all. so much to learn in 3D.

[Scott_Bro]

Thanks for the new info steven.

Is there anyway you can teach me a bit about the rotation and projection matrixes???

My rotations are usuallly sin/cos could be stored into arrays for speed-ups.
My projections are conversion formulas for 3d/2d screen coordinates.

Can you explain more to me how to use and setup rot/proj matrixes and why we use them????
Thanks
Scott B.

[kevin]

 

setup rot/proj matrixes and why we use themp

  You've basically answering your own question...  They're used to rotate / project vectors.

 Jump onto YouTube and search for tutorials for matrix rotations.  
 

[stevmjon]

hey scott

understanding the how and the why took me some time, watching many youtube videos.

i have been working on a tutorial video, to explain the whole 3D process in a very visual way, using 3D software and photoshop.
the video will be in 3 sections, and i already have the 1st section pretty much completed. it will be beginner friendly too (hopefully).

i put a hold on this this year because i was working on a ray tracer and an editor for the ray tracer...

so in the meantime i can make up a few images showing the transformation stages in order with a description, if that will help until i get the video done.
i find this process interesting, and it is actually not that difficult to learn, once you get though all the stages. it actually makes 'logical' sense.

* did you want to learn why we use the matrix calculations themselves, or the theory about why we use the transformation stages?
you already seem familiar with these > translate , rotate , perspective projection , screen space.

the matrix calculations themselves are just placeholders for what to calculate. when you use these calculations, you actually don't use the matrix itself, as it has many unnecessary calculations (there are a lot of zeros, better to ignore them).
so just shorten them to use the placeholders that have actual values in them.

* or are you interested on the additional values with the prespective projection matrix?
there are 2 ways to calc this. divide by z, so all points lie on the same plane, or modify z component so the points lie in a cube (canonical cube)? this is great for better texture accuracy if polygons overlap, and for zbuffers.

another thing to be aware of is that the 3D world can be structured coordinate wise as a left hand / right hand world. so the matrix calculations may slightly vary, especially the location of the values in the matrix. the perspective projection is noticable. it may be set out to 'solve' via row or via columns. when you work this out, then it may be left handed or right handed so the minus sign needs to be moved (meaning the camera is looking down -z or +z).

why we use the transformation stages is basically to convert the 3D data to draw onto a 2D screen.
the different stages are there to help us determine where all the points are from the 'center' of where the camera is looking (basically if you shoot a ray from the center of the camera, we need to know how far from this center ray, on all 3 axis attached to the camera, not the 3D world, the points are from this 'look ray'). we consider how far left/right from the look ray (consider x value) , how far above/below look ray (consider y value), and how far along the look ray (consider z value). these x,y,z values are considered lined up with this look ray (not the 3D world).

instead of calculating this information from where the camera actually is, which will require a lot of more complicated calculations, we transform them around the center of the 3D world then rotate to look down the z axis. then, the new location of all the points in the scene are now lined up with the actual 3D world axis, and these locations are how far from the look ray we needed (this is why the camera is rotated to point down the z axis). so the world z axis is where the camera is now facing, so the z value of the points new position is how far from the camera it is along the look ray (z axis), the distance left/right from the look ray is now the x value, and the distance up/down is now the y value.

so basically the translate then rotate sets up to know how far the points are from the camera 'look ray'. this saves us more complicated calculations.
then the 'perspective' projection that follows applies 'perspective' calculation, that revolves around the camera center 'look ray', which is now the z axis.
when we divide x/z and y/z these points are now moved closer to the screen center because the center of our camera is x=0, y=0. as the x and y values are changed, it will either move directly towards this center (if objects are further away), or directly away from this center (if the objects are closer). this gives us perspective correct looking polygons.

you also do not have to calculate this divide by z if you want the objects to remain their original scale (so distance is not taken into consideration).

then the screen space that follows projects whatever points/objects/polygons that lie inside the -1 to +1 on the x axis and y axis. this is scaled to fit any size screen. this is why aspect ratio is needed for widesceen. you take a evenly spaced 'square' data from the 3D world, then place these on a non-square screen. so that is why objects squish on widescreen, if you don't take into account aspect ratio.

anyway, you probably know a lot of what i just wrote. thought i would add this in anyway as i like explaining how this works.

let me know what you want to focus on and i can make up images.

   stevmjon

[stevmjon]

something that is interesting, is you want the distance of points from the camera as distance perpendicular from the look ray, not actual distance.
the reason is actual distance will cause the edges that are supposed to be straight to be distorted. because the camera look ray, in the above post, is facing down the z axis, just take the points z value as distance.
this will make straight edges.

[stevmjon]

hey scott

here is a pic i made up to explain the Perspective Matrix.
this one is usually found on the net, so i used this one. i needed to move the - sign to allow for camera looking down + z axis.
* the neg sign was moved from the -1 in the Z column then moved to be placed at the -(2*f*n)/(f-n) so the points get transformed towards the camera.

hope this helps stevmjon

[stevmjon]

with the Rotation Matrix, this one is a little technical to explain, but it is really handy because you can rotate an object a given value, without needing to know the current angle first.

x = radius * cos(angle)    :    need to know the radius & 'current' angle, then need to modify this angle by how much you need to rotate to give the destination angle (pain).

x = x * cos(angle)  +  y * sin(angle)    :     no need to know radius or current angle. this 'angle' value is just how much do i need to rotate by (awsome).

inside a 3D engine, you usually need to rotate around at least 2 axis, usually heading (around y axis) and pitch (around x axis).
this way the camera can look left to right (heading) and also up and down (pitch). can add tilt (bank) also if you want to fly around.

[stevmjon]

pic of the Rotate Matrix, showing heading.

this shows how the x & z (heading) work together to rotate by any value.
i chose to rotate by 45 deg here.

hopefully this helps, at least to visualise the process.