 Hey all. As this is my first entry in the tech-files I guess I'll begin with a little about me, what I've done, what I'm doing, where I'm going etc. If you've got a keen eye, you've noticed that I did the review on Crystal Space, and if not, then now you know. <SHAMELESS PLUG>Be sure to check it out sometime and submit your engine for review too. It would be nice for flipcode to have as many entries in engine review as entries in the tech-files (or more…) </SHAMELESS PLUG> So now onto 3D engine stuff, since that is what I do. My first near-complete engine (1996) was a landscape renderer using a quad-tree for face ordering. It was done in software, 320x200x256. I was pretty proud of it since it did texture-mapped, gourad shaded, z-buffer faces, and had support for 3D objects (which were z-buffered into the scene) and transparencies. I never finished it as school started again for me and I didn't have that much time to waste. From that point on I dibbled and dabbled with several algorithms, never really making much of an engine out of them, just using them to the point of seeing, yes I can do that and it's fast or it's slow. The next engine I did in a 4 week coding marathon during winter break my first year in college after months of reading docs and tutorials. My inspiration was that I had just gotten a Voodoo2 and I no longer had to worry about software rasterizing, I could focus on experimenting with various visibility algorithms. It was a pure portal engine, which ran pretty nice using Glide 2.x. I dropped it a few months later after I saw it would never stand up to the complex scenes I wanted to do. And that brings us up to the present. I'm not really interested in making a 3D engine that has the latest and greatest technology. I'd rather focus on making an engine that looks superb and runs fast without having a 500Mhz machine. My current engine is pure PVS with a BSP/simulated oct-tree only to perform fast searching of nodes for the node the camera is in. I let hardware Z-buffer take care of face sorting. It's really simple, but its fast. In a typical scene (300-500 faces) on a 150Mhz machine I get between 55-80 FPS at 800x600x64K. Not too shabby. The reason I'm going with this method is that I want to do both indoor and outdoor scenes. For indoor my PVS and BSP ends up being much like Quake's, while outdoor the tree is more like an oct-tree and I make things a certain distance away invisible, and turn on a liner fog. As soon as I get a few more things working, I'll post a demo somewhere so keep a watch out for it. If I do finish it (knock on wood,) I hope to either sell it (yeah right) or make a game, (just like every other 3D engine programmer wants to do. Hehe. ) Anyway, here's a list of things planned for the engine: These are probably the things I'll talk about in my tech-file. Or I'll just ramble about ideas and maybe spark some idea in someone's head that makes them write something great. (As that is what these tech-files are about) Right now I'm working on doing light-maps. A really common thing and not too hard too do. I'm just doing some 'faking' of real light equations instead of real radiosity. While I'm on the subject I think that's a good thing to talk about. Faking things and coming up with new algorithms and applying them. I think this is what makes some 3d programmers better than others. Why do some expensive calculations when, if your good, you can come up with something that's simpler (or more complex) but gives the same or close to the same results in a faster manner? That's why Carmack is hailed as the best. He's the one who comes up with all the ideas first and can apply them. It's coming up with the new ideas to do old things better that's hard. Even harder than doing any programming, no matter what it is. =) Right now I'm also working on trying to speed up the engine. Since you can only make transformations and clipping so fast, I'm looking for ways to speed up the engine on a macro-level instead of optimizing the low-level stuff. The basic idea right now is, "how much information can be retained between frames?" or "How much can I cache and use again in the next so many frames?" Example: Reflections. You can bet that if you have a reflective floor and you calculate that the reflection once that you can use that same info for the next frame for what was drawn, and you only have to calculate the reflection for new areas that have become visible. I have some other ideas for optimizations because it's a hardware engine, but at this point it is just speculative so perhaps I'll comment on it in a future update if it works. That's about it for now. I really rambled just about myself in this introduction, but in the future I'll focus more on algorithms and optimizations that I'm working on, or things that are just ideas that I've had floating around. Got questions, comments? Just e-mail me. 
|
