Originally posted by Zeno:
[b]While it’s true that engine development started a long time ago, I’m guessing most of the artwork is more recent. The engine’s poly-pushing capability should scale up with the newer cards, and it seems (to me) that they would notice this and increase the polygon detail in their artwork.
Now, like you said, there are other excuses besides age of the engine that could explain the low poly counts. For instance, maybe they want it to run well on all GF2+ cards. Maybe there will be tons of monsters in some rooms. Maybe they have to use 9 passes to render some scenes so the visible poly count is misleading.
[/b]
The “low” polygon counts make a lot of sense. Creating shadow volumes for the entire scene adds a lot of geometry ( Carmack mentioned 3x the original model is possible per light ). Then add in all passes for the lights ( 2-3x geometry per light on GeForce3 ).
The way rendering of light sources is accumulated to the framebuffer, Ambient could be drawn during the full scene z fill pass (I’ve described this in other threads). It would be almost free although I assume it would cost some texture for a purely indirect illumination light map to apply as the ambient value, rather than a dumb global value. I might be tempted to go with a light vector RGB + alpha intensity for this zfill pass to give some slightly dominant directionality to ambient on the diffuse term, but that’s getting more complex than just ambient.
Ah… it starts off with no lights, I needed to press A to get one. There’s barely any ambient in the scene to start with. If I crank up the monitor brightness I can make out the ambient… barely.
[This message has been edited by dorbie (edited 07-31-2002).]
Originally posted by dorbie:
[b]It required DevIL libraries installed.[b]
Yep, that was it, thanks Dorbie. Nice demo Nutty I have been thinking about making a generalized per-pixel lighting model something like this. Still haven’t worked out all the details, though.
I made a really cool light engine once, very easy to use and stuff. The bad thing is that it doesn’t work. Haha! I still don’t see wth is wrong. So thats why i’m re-writing it with a different approach (and with a better understanding on what im doing and how to do it) this time so maybe it will turn out better.
I like my multi-light demo (http://area3d.net/story.php?id=49), two lights with Specular (n.h^32 via dependent read), the only problem with it is that only the Radeon 8500 can handle it (ATM) in one “pass” (the GF3/4 would need at least 2, one for each light).
T think for a game like doom3 it is fine to use one single lighting and shadowing technique for everything. But it wouldn’t be a good idea for a engine which you want to re-use also for different kind of games. For example, for scenes having daylight or bright rooms, you may want to combine precalculated radioisity lightmaps or vertex lighting with dynamic shadow-volume lights. I think that’s one reason for a flexibly shader system, where you can plug together different rendering techniques as you need instead of a fixed rendering pipeline.
~While it’s true that engine development started a long time ago, I’m guessing most of the artwork is more recent. The engine’s poly-pushing capability should scale up with the newer cards, and it seems (to me) that they would notice this and increase the polygon detail in their artwork.~
Hm, this could be a problem… The reduction from half a million to a few thousand polygons probably takes some time, so it would be done offline. They probably don’t want to keep a high polycount version in memory at runtime, only to have it be onscreen in a 30% collapsed state 90% of the time (and having it cast shadows 50% collapsed 100% of the time), so, it’d be logical to make the polycount in which it ships not too high (and/or do a bunch of collapsing at load time based on performance ‘estimates’)…
So any scalability is not in the engine, but in the offline processing – kinda like making all your textures in a procedural package, so you can batch-recreate the images in a higher res when you notice that GPUs these days come with much more memory than when you started…
In that sense the runtime component is actually less scalable than Q3’s Beziers… ?
Originally posted by bpeers: In that sense the runtime component is actually less scalable than Q3’s Beziers… ?
Yes, curves in DOOM3 are tessellated in the editor ( to quote John Carmack: “before it even gets to the game” ). I don’t think the engine even has runtime LOD selection - it’ll make the shadows look terrible ( in the case of huge shadows from far away objects ). It might work in some cases but I doubt it’s worth the effort to implement.
Originally posted by PH: MZ, are you blind ? I said curves in DOOM3 not Quake3.
Oh sith.
I’m not 100% blind yet, but I always thought these computers will make me need to wear glasses sooner or later…
You were talking as if you have seen the editor, so Q3 flashed in my tired mind
)