Well, Xmas is looming large on the horizon, and as per usual around this time, Team17 are busy little bee's trying to get everything done and mastered (its always the same around this time).
Fortunately for me, I'm on a different deadline, so i can happily sit and watch all the chicken-with-head-cutoff producer types rushing round.
Of course i try and tell myself that it wont be me in that position soon enough.
Recently, Ive been looking into terrain rendering and how to tie in other types of rendering with it. One of the things I normally have a problem with is getting content to test with. With so many people out there that are capable of producing good stuff, it always strikes me as crazy that I can never get any help with models and stuff even if I offer to pay.
Anyway, this last few weeks Ive been trying to remedy the situation, be working at getting tools in place so that I can either generate content (i.e. landscapes using a heightfield editor/map generator) or load content for use with other games (note: this is for my own tests, not commercial ventures, so I dont mind "borrowing" models etc). I'd already gotten some code in place for my last personal project (anim code, model loaders etc), so I fleshed it out with Q3A and Halflife bsp loaders (although I STILL cant get the texcoords of halflife lightmaps correctly).
Once I get the heightfield editor finished (waiting for a book to use for some texture generation algo's), I'll be able to integrate it all together into a nice object based editor.
I have to come clean here, I am NOT that much of a graphics programmer. I love 3D, but personally, my mind just isnt into advanced maths enough to cope with doing the really high end stuff required to push the boundaries. BUT Ive always felt that people who think that just because theyve coded one engine or another that they are BETTER than other programmers were kidding themselves. Writing a game goes beyond just 3d engines and the like, its a whole different ballgame to actually create a "game" rather than an engine. Happily enough for me, 3D hardware is making it MUCH simpler for us non-math-heads, because its pushing the emphasis towards doing things in a simple way faster, rather than doing things in a complex way.
I'll give you an example. Today i was reading a document on DX vertex buffer usage at the Nvidia site. One of the things that interested me was that they are advocating object based culling rather than some fine grained, highly complex system. The essence of this is "Stear clear of doing ANYTHING on a per polygon basis". This is great for me!, I love that!, because I was always planning on doing that anyway.
So what does this give me? well, I create a bunch of similar size "objects", these can be terrain patches, player models, landscape features etc. I shove these in some simple structure (octree, quadtree, take your pick), when I come to render, I cull at the coarsest level possible, with the coarsness coming from the structure, and the finest granularity being the object level (sphere or bounding box cull). I then render all "visible" objects in as efficient manner as I can. Static objects are done as compiled striplists, dynamic objects as vertex buffers or arrays. Thats it.. nothing more complex than that really.
The point about all this, is that I can concentrate on making a great GAME and not on writing some godlike engine.. Ive always thought that tools to create content were much more complex than tools used to render it, and this makes it even more so.
My other little subgoal for this month is to get to grips with DX8, to really see if I can get into it, now that its changed significantly since I last visited. DX8 seems actually genuinely to be trying to get towards a simpler to use API, and is almost touching on the ease of programming as OGL. As I plan on working on Xbox titles for the next few years, I am kind of revisiting DX8 to get a feel for it as it is now, without my prejudices from 3-4 years ago.
Well, enough for now, if anyone wants to take a stab at reverse-engineering the code to calculate lightmap tex-coords for halflife .bsp files for me, I'd be happy to send my (nightmarish) source along. The aim of this stuff is to be able to export .bsp files into a format most "real" modellers can read (probably .3ds), thus I can place models and animations inside a nicely lit scene for testing with).
I'm actually looking forward to working now, which is something that wasnt always the case over xmas (especially deadline time), I hope you are too!.