As I said, I’m using a drawing order. This is how the program looks. Of course, I just mapped the actual maps to the spheres, used an ambient light always present at 0,0,0. The engine that drive the bodies was already written before I discovered OpenGL. OpenGL allows rotation of the object about their axes. http://home.pacbell.net/goedel/orbit2.jpghttp://home.pacbell.net/goedel/orbit1.jpg
[This message has been edited by Kurt B (edited 05-27-2000).]
[This message has been edited by Kurt B (edited 05-27-2000).]
I dunno, Hummus… I’m sure you’re right about Glide, but I’m almost positive that under other 3d api’s the whole system is different (not just the letters)
Here’s another quote from RTR :
“For the Z-buffer, we store the value of z/w after projection. The characteristics of the perspective transform result in greater precision for objects closer to the viewer.”
Do you see what I’m getting at? Hopefully this is helpful to you in some way (and if not, hey, you can never learn too much )
I know and understand the math behind this since I had to provide Glide with those w, 1/w, x/w, y/w … etc … nothing is free in Glide you know …
But i can’t figure out why we would use integers for storing non-uniformed depthvalues . Floating point values is already non-uniform and it’s easy to implement in hardware. I know that 3dfx hardware uses floating point numbers, don’t know with other vendors though …
Ok, i get what you mean … but if you use a float depthbuffer you don’t need this extra math, you can just store the depthvalue directly and get the same effect.
)
. Floating point values is already non-uniform and it’s easy to implement in hardware. I know that 3dfx hardware uses floating point numbers, don’t know with other vendors though …
