Test3D

I took a break from programming City3D and played around with a program I have called Test3D today. It was one of my first 3D programming attempts and I have used it to test out new ideas and concepts I have learned. It actually looks pretty nice, I programmed it using the Glut library, something I avoid these days as it is a dated library and you can do everything it does on your own easily. My Test3D program has a nice rendered terrain with hills, trees, a detail texture so it looks better. It has real time lighting which I was proud to finally get working and a little idea I got I called "extended terrain" which basically allows you to walk on forever, the terrain just repeats itself as you go. Probably a useless feature, but it gets rid of those ugly borders where your 3D terrain suddenly comes to an end. I may do some more work on this just to practice my 3D programming more and come back to working on my City3D program later. City3D looks more primitive in comparison, but it is a "newer" project. It was created entirely without Glut and just with normal Windows + OpenGL programming, no extra libraries. I also want City3D to be a game, so I have tried to keep it simple. I may still need to start it over from scratch. I will probably work on a more detailed design document and try and get down on paper what I want it to do and how to do the 3D optimizations. The most important thing I need to redesign is the way the maps/levels are stored. The way the data is organized is THE most important part of creating a good 3D game. For example, you need to store your levels as a list of polygons for most of them. You can have some 3D objects loaded in separately, nothing too big, but the majority of your base level needs to be a list of polygons in something like a Quad Tree or something of that nature so that you can optimize rendering for things like Frustum Culling, Occlusion Culling as well as collision detection. Without your level data organized properly you can't do any of these very well. A lesson I have learned too late. Oh, you CAN do collision detection for example, but without frustum culling, or a quad tree (or similar data structure) you would need to test EVERY polygon in your level every time you moved for collision! As you can imagine, this would get very slow. With Quad Trees you can narrow down where you are, in a small section, then ONLY check the polygons in that section of your level. With frustum culling you can use math to figure out which sections of your level fall within your field of view, then ONLY render them. With Occlusion Culling you can check the polygons of the area you wish to render (within your frustum) and only render the polygons that actually face you. As you can see, with all these optimizations in place you can really cut down on the amount of polygons you will be sending to the video card to render and speeding things up. You can go further by using Level of Detail optimizations to lower the detail of objects that are further away from you, thus lowering the number of polygons sent to the video card. Video cards are fast, but the process of sending polygons TO the video card is the slow part (also called the "bottleneck"). Anyhow, I am experimenting with all this with my Test3D program, it's also fun to work with as it is starting to look really nice. If you're interested, you can download Test3D here: Test3D.zip