3D engine math and a LOT of stuff

[k_girl]

i just wrote a 3d engine in c++
of course it is spaghetti code, but i did go through all of the math.

here is a link to some code from a textbook:
http://archive.ncsa.uiuc.edu/Vis/Graphics/code.html

it has useful stuff like 2 & 3d transformations (like rotation), polygon scan conversion, clipping, etc.

for the hidden surface issue, i would use depth/z buffering

[relsoft]

i just wrote a 3d engine in c++
of course it is spaghetti code, but i did go through all of the math.

here is a link to code from my textbook:
http://archive.ncsa.uiuc.edu/Vis/Graphics/code.html

it has useful stuff like 2 & 3d transformations (like rotation), polygon scan conversion, clipping, etc.

for the hidden surface issue, i would use depth/z buffering

Hidden face removal is just a normal(z) of your projected coordinates.

[k_girl]

actually that is one way to do it, called backface culling. it only works for convex poygons and if you always put your vertices in in the same direction (clockwise or counterclockwise). however, it is not too difficult to find the z value for each pixel on a polygon and only draw it if it is closer to the camera than all other points that have been mapped to that pixel so far

[Blitz]

PS: I will code this in C++ probably with some opengl lib, for example:
GLUT

First find out what glut is before attempting to use it. IIRC glut is a lib for setting up a window and stuff like that. And not for doing any 3d rendering or transforms. And what's wrong with actual OpenGL?

[Blitz]

Hah, the girl knows more about coding then all of you guys. Sooo funny

[k_girl]

tee hee,

thanks Blitz!

[relsoft]

actually that is one way to do it, called backface culling. it only works for convex poygons and if you always put your vertices in in the same direction (clockwise or counterclockwise). however, it is not too difficult to find the z value for each pixel on a polygon and only draw it if it is closer to the camera than all other points that have been mapped to that pixel so far

And loose memory? :*) A zbuffer in screen 13 would take a 320*200 page.

[k_girl]

Sorry, I'm speaking from c++ experience. in c++, x*y float values isn't that big of a deal. also, i've been mostly working with still shots, i'm now working on a raytracer

[toonski84]

it's not so much c++ (that's just a language) as it is the pentium class of processors. newer chips are designed so floating point math is about the same speed as integer math. but on older chips (486 and down), which a lot of people program for even now, integer math is incredibly faster than floating point, so one of the biggest optimizations you could do to a program was to remove all integer math.

of course, once again, as you implied, this doesnt even matter much on modern 32-bit processors.

[k_girl]

thanks for the clarification, toonski

i wasn't sure about the newer architectures, but i know lots of the older ones take 15+ machine cycles for fp ops, esp division, while int ops only take one cycle. anyhow, fp ops didn't seem to make such a difference on my machine, so i suppose that is what the deal is. makes sense, especially since most imperative languages are essentially the same once you lose the syntatic sugar and look at the abstract syntax