Post by Kyle Gagner on Nov 28, 2011 21:46:52 GMT -5
I have wanted to program 3D games for a long time. When I got into DirectX (with Visual Basic) however, I felt I was cheated out of programming. There was a bunch of kinda random stuff to remember to put in your project and the rest was working with really abstract stuff like functions that made matrices for you... I learned a lot about 3D graphics, but I decided it wasn't for me. Later, when I learned Python, I started looking deeper into 3D graphics. I wrote all of the code to set individual pixels on a screen and render 3D objects with Phong shading, bump maps, textures etc. But Python is far too slow. Now I'm into SDL and C, and I'm ready to once and for all have a satisfying 3D experience. C is fast enough to do CPU only graphics, and I'm not messing around with OpenGl or DirectX. Yeah, it's a bit impractical, I don't program for practicality.
I have decided that my 3D graphics program will be fairly simple. I don't feel like cramming in a lot of features, because I don't even have any modeling tools other than programs I write. Also, I'm worried about speed. Even drawing a blank screen in full screen mode can be a bit slow on my computer (I mean, think about it, 1366 by 768 pixels... That's a lot of operations). Flat shading and phong shading will not be options, only Gouraud shading. Lighting will come from one directional source. There will be emissive, ambient, and diffuse light, but no specular lighting (specular sucks on Gouraud shading). There will be no shadows. Colors will be stored on a per triangle basis, not per vertex. And, there will be no transparency. As of now, I don't even plan to use texture maps, but I may change my mind.
"What is this insanity?" you say. Well... If I'm going to shoot for crappy CPU graphics I might as well shoot for "omg these graphicz are so bad there good". So, without further nonsense, my graphics pipeline.
Models stored as an array of vertex trios (for triangles) with emissive, ambient, and diffuse colors. Each vertex will have its own normal (duh, why else would I prefer Gouraud over flat?).
double x1
double y1
double z1
double nx1
double ny1
double nz1
double x2
double y2
double z2
double nx2
double ny2
double nz2
double x3
double y3
double z3
double nx3
double ny3
double nz3
double er
double eg
double eb
double ar
double ab
double ag
double dr
double dg
double db
Why doubles for colors? I've always wanted to do it that way. Go ahead, laugh at me. I almost always store colors as doubles. It's probably an idiotic thing to do.
Models can be transformed by matrices and stored to a vertex buffer. In this process the light values at vertices will be computed and, from that, their final color will be found. At this point, the normal data becomes worthless, as do the color values. Any triangle with all three points with a z less than 0 become worthless, and I may implement an optional triangle culling that removes counterclockwise So a triangle will now be...
double x1
double y1
double z1
double x2
double y2
double z2
double x3
double y3
double z3
double r1
double g1
double b1
double r2
double g2
double b2
double r2
double g2
double b2
Once all of the models are written to the vertex buffer for one frame, the triangles will then be rasterized using a z buffer.
Okay, now time to get to work.
I have decided that my 3D graphics program will be fairly simple. I don't feel like cramming in a lot of features, because I don't even have any modeling tools other than programs I write. Also, I'm worried about speed. Even drawing a blank screen in full screen mode can be a bit slow on my computer (I mean, think about it, 1366 by 768 pixels... That's a lot of operations). Flat shading and phong shading will not be options, only Gouraud shading. Lighting will come from one directional source. There will be emissive, ambient, and diffuse light, but no specular lighting (specular sucks on Gouraud shading). There will be no shadows. Colors will be stored on a per triangle basis, not per vertex. And, there will be no transparency. As of now, I don't even plan to use texture maps, but I may change my mind.
"What is this insanity?" you say. Well... If I'm going to shoot for crappy CPU graphics I might as well shoot for "omg these graphicz are so bad there good". So, without further nonsense, my graphics pipeline.
Models stored as an array of vertex trios (for triangles) with emissive, ambient, and diffuse colors. Each vertex will have its own normal (duh, why else would I prefer Gouraud over flat?).
double x1
double y1
double z1
double nx1
double ny1
double nz1
double x2
double y2
double z2
double nx2
double ny2
double nz2
double x3
double y3
double z3
double nx3
double ny3
double nz3
double er
double eg
double eb
double ar
double ab
double ag
double dr
double dg
double db
Why doubles for colors? I've always wanted to do it that way. Go ahead, laugh at me. I almost always store colors as doubles. It's probably an idiotic thing to do.
Models can be transformed by matrices and stored to a vertex buffer. In this process the light values at vertices will be computed and, from that, their final color will be found. At this point, the normal data becomes worthless, as do the color values. Any triangle with all three points with a z less than 0 become worthless, and I may implement an optional triangle culling that removes counterclockwise So a triangle will now be...
double x1
double y1
double z1
double x2
double y2
double z2
double x3
double y3
double z3
double r1
double g1
double b1
double r2
double g2
double b2
double r2
double g2
double b2
Once all of the models are written to the vertex buffer for one frame, the triangles will then be rasterized using a z buffer.
Okay, now time to get to work.