Doom 3 engine release and game code

[revelator]

hehe seems so im not sure if its part of that map but else it looks normal

heres one from Doom3 itself same options



i gues some will like the less plasticy effect

[motorsep]

Neat stuff. How does Doom 3 look in GLSL without all these fancy shaders? (can you take some screenies please) I'd like to see if heat haze and glass works already, and portal sky

[revelator]

that part not yet done so i guess they wont work yet but ill take some screenies of it with the new backend for the curious.
Sikk has made some additions in that regard but atm his code crashes doom3 and noone seem to have made glsl versions for those effects yet so even if the backend could load them i couldnt show you .

[revelator]

haze seems to work but i noticed the spirit portal in the first room when you enter hell shows no spirits hmm ???

[revelator]

Think i have to explain why the glsl shaders are not there yet

The code you saw in the previous post gets its registers directly from the vertex and fragment shaders but cubemaps glasswarp etc gets it from the material shader parser.
So whats needed is an interface to get the correct registers from there as well as glsl specific code to handle those extensions. Atm only arb2 has those extensions in draw_common.cpp.
One would wonder then why not just let the ARB2 backend handle those ? well for one when the glsl backend is enabled the ARB2 backend is not so none of these extentions ever get used.
Furthermore disabling the check for the ARB2 backend to force it messes up stuff so you get a weird viewport effect because both backends will try and draw the same stuff (bit like standing in front of a mirror and holding another mirror behind you. So lots of smaller images going back into infinity. It looks totally crap then comes the problem with missing vertex and fragment shaders to do what ARB2 does, so far noone has made any as far as i know so even if the backend supported them it wouldnt work

Those shaders are not code in the engine there more like text files with instructions to tell the backend what to do and if missing the backend will just disable those extentions and do nothing at all.
ATm im studiying Sikks code to get an idea of expanding the registers to handle more stuff but even his version has no material interaction with the glsl backend yet.

[revelator]

Had a look at justin marshall code and noticed he uses a different approach to glsl basically merging it with the ARB2 backend to handle the same materials quite a nice idea actually.
The downside is that his code will take a humongus effort to port for Doom3 :S as he totally rewritten the entire rendering system. Tbh im not sure im good enough to take on that feat

[mh]

Switching between GLSL and ARB assembly at runtime is something that's theoretically possible, but I'd feel a little nervous doing it on some platforms. In other words - I'd expect it to work on NVIDIA as they can take some of the most awful programmer abuse (lesson #1 in "why you should not develop on NVIDIA"), it should work on AMD but I wouldn't rely on it, and as for Intel - gettouttahere...!

[revelator]

[revelator]

Oh btw i got a nvidia and no it wont take that hehe. Atleast not with anything i tried feeding it.

[taniwha]

[nbohr1more]

Yeah, Justin Marshall's code is probably too alien to integrate into a "vanilla" branch of Doom 3.

He's trying to tackle next-gen paradigms in a similar fashion to RAGE or some of the other
Virtual Texture \ Virtual Normals \ Virtual Geometry? It's a forward looking approach
but has a lot of overhead for hobbyist users. That whole paradigm might be the best
approach to maximize the look of deployed content. It reminds me of old 8bit games
that were sprite sampled from 16bit games (R-Type for the Sega Master System)
and looked better than thought possible on the 8bit hardware.
Here the idea is to boil-down a gang of beefy workstations and terabytes of data into something
that will run on a normal PC. As you can see, this approach requires the mapper\hobbyist to
have a muscular rig to take advantage. From a purely social\political POV it's kinda divisive between
the "haves" and the "have nots" in a way not seen before in hobby\mod culture.

I doubt that was Justin's intention though, it's more likely that he is taking the long view
that by the time his work is complete and has caught-on most of the target audience
will have better hardware than now and thus they could use their own single workstation
rather than a NAS array and 20 workstations... (and of course, the solution is scalable so
you could just scale-down the scope of what you bake... though you'd probably be mocked
and scorned for poor texture quality ala RAGE etc...)

That snippet you grabbed seems to cover only the "forward" portion of his renderer. AFAIK
a significant amount of the renderer is "deferred"...meaning; if you merged that code
it might still look wrong because the other visual aspects are handled in the other
render mode.

I find his project exciting and interesting but I am dismayed that such a talented
fellow didn't instead focus on keeping the existing engine paradigm and just expand
features, optimize performance, etc. How much better would it have been to
see "existing" Doom 3 mods run on an improved engine than throwing out the
baby with the bath-water and making modders start fresh in what is essentially
a whole new platform.

Of course, The Dark Mod is already kinda guilty of it's
own divergence well before the GPL release. Other mods would be hard-pressed
to use it's AI, extinguishable lights or Light-Gem systems so I guess that puts
me as the potential stone thrower in a glass house...

It would've been better if TDM had worked with the community to make more generally applicable
versions of it's core systems so the other Doom 3 mods would have stealth
and advanced AI too but I suppose that's down to no other mods showing interest
in collaborating on that work and therefore no votes in the process. (And TDM
folk being more into Thief than Doom 3 therefore more isolated... )

shrugs...

[mh]

There's nothing in that shader code that's overly advanced. He's even carrying forward some of the old low-quality stuff from the original shader, and doing a normalize per-vertex - that's going to lose him some quality as square roots don't linearly interpolate.

His blur code is evil - 25x9x2 texture samples per-fragment I make it - that's going to utterly crucify his framerate, even if he is using a 512x512 scene texture. He may even be faster just copying it to CPU-side (pipeline stalls and all) and doing a gaussian on the CPU, then TexSubImaging it.

[motorsep]

I thought extinguishable lights are possible with vanilla Doom 3 o_O

What are Light-Gem systems ?

[revelator]

Might have another solution upcomming when sikk gets his engine done
its atleast somewhat closer to the code in Normal Doom3 and he allready moved code parts out of the CPU and onto the GPU though he allso made changes to the editor but so far only in regards to lighting (Ambient term) which seems to have been missing in the light editor. My guess is that Doom3 didnt support Ambient lights natively ?. Only downside i can see is that you need an updated set of shaders but he allready made the bulk of them. Ill see if i can get him over here so we can have a discussion about his ideas for it.

[nbohr1more]

In TDM the light sources are usually made of multiple entities and often combine a real light and ambient light.
To make the aesthetics look correct, shadows are often disabled when the candle-holder or torch are lit.
Various conditions such as water arrows and simple finger-snuffing can extinguish different lights and
this is all setup in the SDK code. Scripts could do most of this of course but it has be made a systematic
part of the mod so that mission authors do not need to arrange light scripting all over their maps.

AI have been given awareness of light levels, whether lights are lit or extinguished and have
a visibility system to determine whether the player can be seen "in the light" or if he is
blending into the shadows. The "Light Gem" shows the player how bright he is and whether the
AI are likely to see him. This is a concept taken from the Thief games which the mod emulates.
Apparently similar "light detection" systems are present in games like System Shock and Deus Ex
from the same parent company as Thief (Looking Glass Studios).

There was once a Doom 3 mod called Sapphire Scar which planned to remake something
like System Shock in a similar fashion as The Dark Mod. Doom 3 has some hints and echos
of that game and it's surprising that there is no real stealth in the game given the
survival horror vibes it has. What would it be like hiding in the shadows from the roaming
eyes of those demons and zombies? Thus far nobody has tried such a thing...