With the Doom 3 source release hopefully coming closer, I've thought about it a little more and it's now looking likely that I will be doing something with the code. I haven't yet decided if this will be for public release or private use but it may make for some interesting discussion. There are a few things I want to try out in a more modern rendering environment than Quake allows, and Doom 3 seems like it might provide a nice platform (if nothing else the amount of work required to get it up to basic spec should be lessened).
Assuming that I do make the final decision, here's how I see it working out.
It will be Direct 3D. I haven't yet decided whether the version will be 9 or 11, as each has factors that would recommend it over the other (I know 9 better but there are some things in 11 that I'd like to play with).
Line for equivalent line Direct3D has always come out about 25% or so faster than OpenGL in any work I've ever done, so that should be good for integrated graphics chips (I have one that I played Doom 3 on once - it was a horrible experience).
Doom 3 uses OpenGL shaders, but the version it uses is the older ARB Assembly shading language. It should be relatively easy to write a simple parser to convert these to HLSL (the resulting code won't be pretty but it should work OK) and that's the first thing I want to try out. That necessarily limits use of the result to the original game (I can't recall what RoE used) but that's OK - it won't be a design goal to be all things to all people.
Because of the technology level it was aimed at it uses multiple passes to draw lit surfaces. There's one potental avenue for optimization - seeing how many of these we can collapse into a single pass. This should be easier if I normalize in a shader instead of using a cubemap, so I might also just hard-code the default game shaders into the engine. That rules out the shader parser/converter of course, so I'll probably end up flipping a coin on this one.
From my explorations so far of GL Intercept logs and shader code included with the game it seems as though there is a lot of work being done on the CPU that could be usefully moved to the GPU.
I want to explore some shadow mapping and try get soft shadows into the engine - it's always been something of an ugly visual clash that some of the pre-baked shadows are soft-edged whereas the dynamic stencil shadows are hard-edged (which I loathe to begin with). Don't know how that one will turn out, and there are obvious performance tradeoffs to consider. I've never really done any serious work with shadows and it would be nice to get something good for Quake out of that too.
Seeing if anything can be done to improve load times is interesting too. They're just too long. I know that DDS textures are available with the game, and making some creative use of these could be fun.
Some general visual improvements and nips and tucks on things that annoy me about the game seem in order. Ideas for these will probably evolve organically.
So that's a bunch of stuff that seems cool and fun to explore, but no promises, no due dates, and it will have to take a lower priority to other work.
This should be in 10-foot high letters on everyone's wall ("anatomy of a mis-feature"):
...Ah well, someone might use the feature for something, and it's already finished, so no harm done, right? Wrong. ..... The addition of a feature early on caused other (more important) features to not be developed. ..... The important point is that the cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion.It's also the reason why I sometimes remove features from DirectQ, or sometimes resist the addition of new ones.
Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web.
The trick is to pick the features that don't fight each other. The problem is that the feature that you pass on will always be SOMEONE's pet feature, and they will think you are cruel and uncaring, and say nasty things about you.
6 comments:
About misfeatures. From the perspective of a content designer *g*
One man's owl is another man's nightingale.
What might drive the tears into an elite coder's eye ("but we could have twice the FPS without it!") might be a coldly and heartlessly calculated loss with the goal of getting something that outweighs the loss.
In someone's opinion.
What exactly outweighs what, and what's worth what, and what is just too horrible to consider, is again a question of perspective, and opinions will differ according to whom you ask - the engine coder, the playtester, the level designer, the texture artists or project leaders.
It is never easy for sure.
Obviously the number of interests involved is smaller when the engine IS the project.
The entire question reminds me of Carmack vs. Romero when content people want more freedom, higher limits, crappy speculars and pretty lighting while engine people aren't content with an engine that is slave to "running the damn game". Understandably so.
It is quite interesting and I'm not saying one side is right or wrong. It's one of the things that have to be balanced, and finding the balance is often not easy since both sides are tugging at the tablecloth in opposite directions, somehow.
Design not reigned in by technical considerations results in 1000x1000 pixel skins for an arrow, or however much it was in the famous Daikatana example.
Technology not bolstered by enthusiastic design (and its often pain-inducing requirements) results in a tech demo.
A compromise is needed.
I think balance and compromise is the right way to go. In the specific case covered by the Carmack quote I posted, it can cut both ways - the extra features made code horrible to work with (not necessarily slow though) but also prevented useful extensions to the format from a designers point of view.
I do sometimes err on the side of faster code, but better performance is much more than just some kind of dick measuring contest. It also enables designers to go nuts by cramming in more content.
Tech 4 always seemed to me like a very strong candidate for a deferred rendering approach. In 2004, the concept of deferring certain rendering processes wasn't well-explored and was probably infeasible for a production engine at that time anyway. These days, though, things are certainly quite different, and it's gotten to the point where it's actually quite unusual to see a traditional forward renderer in a AAA title.
Is this something you're thinking about or are you leaning more toward a straight-up forward rendering approach for this project?
On the subject of non-traditional rendering techniques, have you taken a look at NVIDIA's FXAA anti-aliasing for DirectQ? Given the level of complexity in Quake, I suspect there might not be any particular performance advantage versus traditional multisampling (on most hardware, anyway), but the 'newness' factor of it is kind of intriguing to me.
I tend to shy away from vendor-specific stuff, I don't like the idea of saying "I have cool feature X but you can't use it unless you have hardware from vendor Y". As much consistency as possible on as many (hardware) platforms as possible is important, and maintaining a single code path makes the dreaded testing, troubleshooting and bugfixing infinitely easier.
Aside from that D3D doesn't tend to expose newer vendor-specific technologies too well (DirectQ does have one hack for hardware instancing on SM2 ATI cards but that's all). That's both a good thing (enforced driver stability and consistency) and a bad thing (you may need to wait longer and/or upgrade to a new version if you want to play with new stuff) but for the specific goals of DirectQ the good comes out on top of the balance.
When I do get round to implementing AA it will be pure native D3D AA.
Haven't given much thought to Doom 3 specifics: right now it's more "this is what I'd like to do" than "this is how I'd like to do it".
Actually, FXAA is non-vendor specific. It's simply a post-process shader that does some rather clever edge detection similar to AMD's MLAA implementation. It's been released to the public domain as well, so GPL compatibility shouldn't be an issue.
FXAA_WhitePaper.pdf
Just in case anyone (like me) wondered what the hell this was all about ;)
Post a Comment