 |
 |
I went over many prototypes in my development, in fact 4 major ones with some variations as testing beds. I've tried binary triangle trees, quadtrees, split-only versions, leaf split-mergers, weird split metrics, vertices buffers, dynamic variance, diamond combiners, fan optimizers, 5 point strips, top-down, bottom-up, well, the works. Of all this what I didn't do was a full ROAM implementation, because I felt that due to the special requirements of an RTS, all those priority queues and the frame coherence side to it would soon turn into overhead. Judging by the news of recent implementations of others who did, this fact was confirmed. I'm glad I took the right decision, it certainly saved me a great deal of trouble. The current engine is by no means finished, and I will probably end up with yet another one. Prototypes are a very good way to get a feel of a broad problem but the fact is that I totally underestimated the amount of work required to make a full blown terrain implementation with all the bells and whistles turned on. This is a research field. Many papers written on the subject describe the fundamentals very well but fail on the internal logic. They are hard to read, hard to follow, only to be off the mark in the end. Indeed there is still a long chasm between academics and you're standard graphics programmer enthusiast . Any implementation is about details, is about tradeoffs and iterative processes, what looks good on paper more often than not doesn't apply well to practical computer science. Terrain rendering is one of them.
-Rui Ferreira mail to: t5rui@hotmail.com
|
T-Minus 5 The Multi-Server Real Time Strategy Engine |
Copyright © 2000 Rui Ferreira, the standard disclaimer applies. |