I've been trying to put together a small 3d renderer without using Direct3D or OpenGL. I've done some research on 3d but I can't stick all the things I've learnt into a program that works. How do you link the parts of the program like the clipping, shading, lighting, etc. so that they work together to creating a 3d scene? I'm sure I have to make a rendering pipe line but I don't know where to start. Should I start from a plot pixel function, then a draw line function, then a clip line function, in a bottom up approach? Any hints? Thanks --Bretto Edited by - Bretto on April 4, 2001 12:30:48 AM

I like to start with the lowest level functions - pixels, horizontal lines, etc. - then move up slowly to polygon filling, then clipping, then transformation, and so on.

~~~~~~~~~~
Martee
http://www.csc.uvic.ca/~mdill

Well, you shouldn''t build your filled polygon-routine on your plot pixel-routine. However starting out with a line-drawing routine (Bresenham is fast and easy to implement), will give you much good, since the knowledge you get from that will come in handy when you write your filled polygon-routine. Clipping should be done at the highest level possible to make it fast, however this is a tradeoff, clipping at pixel-level is the easiest to implement and least error-prone, but also the slowest.
Lighting should be done at some render world level, where you for every polygon have to calculate the (dynamic) lighting caused by every (dynamic) light for that polygon.

If you''re serious about this it might be good to look at the book "Black Art of 3D Game Programming" by Andre LaMothe, ISBN:1571690042, although a bit old it explains the pipeline and stuff in an easy way. Don''t expect it to be very high-tech though.

A modular approach is a good one to take - first divide the pipeline into rough component parts (on paper):

APPLICATION LEVEL:
1) Models & Scene (complete objects, the scenegraph, animation).

VERTEX PIPELINE:
2) Transformation & Lighting (transforming lists of vertices into clip space).

3) Polygon assembly (use indices to find 3 vertices to form a single poly) and backface culling. (*)

4) Poly clipping (rejecting whole polygons and making new vertices for those which straddle the clipping volume. (*)

5) W divide, Viewport mapping (*)

PIXEL PIPELINE
6) Rasterisation (*):
a. Scan conversion of complete polygons.
b. Interpolating colours across scans (gouraud).
c. Texture lookup while doing a.
d. Perspective correct texture lookup (interpolate 1/w * u or v)
e. Z buffer comparison to early out rasteriser.
f. destination pixel blending.



Second, the vertex part of the pipeline is probably going to be easier of the two to get working quickly & properly. The pixel pipeline is more fun to code and optimise though.

If you want to proove the whole pipeline more quickly, then a good approach would be to start with the vertex part (T&L) of the pipeline and use somone elses working rasteriser to check that it works properly - you could even use D3D or OpenGL as pure rasterisers here, so you do all the setup work, they purely fill in the triangles.
One reason for doing it this way round is you''ll find a lot of potential bugs in the T&L part, which can be extremely hard to find if you also have suspicions that the rasteriser may also have a bug.

The alternative (depending on your own personal approach to coding) is to start with the pixel pipeline and get it to a stage where it draws single triangles based on input data - this suits the unit test approach because you can get test that one function to destruction. If possible, use someone elses T&L pipeline to prove it (eg. use D3Ds ProcessVertices() to generate some post transformed data for you).


I do think that you should approach each major part of the pipeline separately though rather than viewing the whole thing as one big top-down or bottom-up project.
Actually I think the pixel part (drawing triangles, doing Z buffer tests etc) is best suited to a top-down approach (start with 3 clip space vertices, then scan conversion for flat shading, then add in scan line interpolation of vertex colours etc).
And the vertex part (T&L, triangle setup etc) may be well suited to a bottom-up approach (start with clip space poly edge clipper, move onto triangle assembly and culling from a list, then transformation of vertices to clip space from other spaces etc).


(*) The order of some of the elements of the pipeline can vary depending on the methods and algorithms you use - for example backface culling could be applied in camera space


Finally, having source to someone elses routines often helps.

The source code to the D3D RefRast is available in the DirectX DDK (Driver Development Kit) - older versions are available somewhere on (www.microsoft.com/hwdev). Bear in mind that the refrast isn''t meant to be an example of how to write fast rasterisers - its sole purpose is accurate rendering (at the cost of speed).

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

thank you all very much.

I see that i''ll have to do a lot of planning before i even start my engine. I might have to get a book to help me. But i don''t want to be spoon fed the code, like in some books. I''m lazy and i''ll end up just making an exact copy.

I''ve read "Tricks of the windows games programming gurus" by Andre Lamoth, and i liked it, so i might have a look at "Black Art of 3D Game Programming". However, I might wait until he releases the second book of the "Tricks of the windows games programming gurus" series. If it is like the first one then it should be good. Does anyone know if this book would have what i am looking for?

thanks
--Bretto