Ive been programming in VB for about 3 years now and about 2 years back i started getting into 3d stuff. This was back when VB didn''t have DirectX support so i read articles on 3d theory and stuff like that and i made a basic as 3d engine in pure vb. It was only wireframe but it worked. So the thing is i just recently started learning DirectX 8 and it''s so easy because you dont have to worry about the z-buffering or all the other complicated stuff that i had to do with my first engine. Apart from setting up the matrices and stuff DirectX does it all for you. So what is the point of all these articles on clipping and z-buffering? are these for openGL or something like that? because as far as i can see which i admit isn''t all that much you don''t really have to worry about all that sort of stuff with DirectX. Sorry if this is the stupidest thing you,ve ever heard but i can''t help it i''m dumb.

well, yeah direct x can handle the z-buffer for ya, but i think that if you handle it your self, you can handle it more efficiently. What i mean is (right now i want to say i am new to 3d graphics, and have been working with dx8 for about half a year, so anything after this point could be totally wrong) the best situation for letting direct x 8 handle the z-buffer is for small demos and what not. If you want to pump out some serious polygons in your 3d world you would want to do it yourself, that is for the reason for all the tutorials around (they arent aimed at opengl, but both api''s), because it is 3d theory, you can apply it to anything. I hope that makes sense, later-

what we do in life... echoes in eternity...

Actually, you''d never want to handle z-buffering on your own these days. DX and GL do it all in hardware, which is much faster than anything you''d be able to do in software. The same goes for a lot of the 3d pipeline, eg. texturing and clipping. These APIs are optimized to perform these operations for you, and for the most part you should just let them.

The reason for the articles is simple understanding. If you don''t know what z-buffering is, how it works, advantanges and pitfalls, then you''ll have a hard time using it properly, even if most of it is done for you. For example, z-buffering is not free: every over-drawn polygon is a hit to your performance. Things like this are important to know.

It''s all too easy to skip learning how things work when they''re done for you. But having an underlying understanding of whatever system you''re working with is invaluable when it comes to designing, trouble-shooting, and optimizing. Just because we all have calculators, doesn''t mean we shouldn''t learn how to add and subtract.

Well Z-Buffering in itself you should definitely let the hardware handle. But that doesn''t mean you shouldn''t worry about removing polygons that shouldn''t be drawn or sorting. DX8 and OpenGL can efficiently remove hidden faces from the data that you send it but you still have to send it in large chunks. If you use a BSP tree or Octree/view-frustrum culling before sending your data to the card it can help alot. Also a quick limited z-sort (front to back) can help a little too because that will reduce the number of write operations on the z-buffer.

Ok thanks for your input guys i''m glad I read all those tutorials on z-burrering and so forth now, i was a bit pissed for a while cuase i thought i wasted heaps of time but it works out for the best now but.

Plus, knowing stuff is cool. Learn how to draw lines and circles and triangles in software. You''ll start getting noticed by girls and be invited to all the cool parties. Well, maybe not, but it can be fun anyway.