Doom 3 engine release and game code

[revelator]

[revelator]

shot from it running the GLSL backend

[mh]

Remove the KIL instructions and you'll probably run faster. Early outs make sense on a CPU, but they're not going to play nice with a GPU. It's likely that the entire shader will always execute anyway, and they'll fuck with any early-Z optimizations that the hardware might be doing (worst case is that they'll disable early-Z altogether as the hardware can no longer predict what Z will be before the fragment shader runs).

[motorsep]

[revelator]

Works with ARB but not with GLSL yet as i dont have any shaders for them
though the POM shader can be a bit buggy at times with some materials (they get a weird mirror effect if the texture source is not completely flat).
The offset limiting version works fine though.

Mh gonna try that thanks.

[revelator]

Heh ok it made it look a bit less weird when getting close to buggy materials but my framerate got killed somewhat.

heres a few shots to show the problem with POM.

at distance it looks ok



when you get closer you get this though.

[revelator]

and here with glsl



same with parralax offset limiting

[revelator]

hmm removing early out fixed some of it but not all unfortunatly its unplayable as you can see here



The frames pr sec here are with 2 560gtx ti overclocked in sli so say goodbye to any normal gfx card xD

[revelator]

Heres the engine and shaders if someone wants to try it out.



All backends besides the Arb fallback and ARB2/GLSL backends have been removed.

Not included the parralax shader you can get that with sikkmod 1.2 but be warned im not liable if it kills your gfx from enabling a bit to much eyecandy

[revelator]

[toneddu2000]

an amazing work you're making, guys. An amazing work.

[mh]

[revelator]

Got the answer from Sikk doom3 actually has a function for accessing depthbuffer related stuff the downside is that the infinite far z volume calculations need some modifying else it would cause some disatorous things but real SSAO is possible allthough it will take some hacking about.

From his post.

There's already a function to capture the depth buffer to a texture, "CopyDepthbuffer(...)". You just need to add an idImage to call it. See "RB_STD_DrawView()" in my source. After the depth buffer is filled (with RB_STD_FillDepthBuffer( drawSurfs, numDrawSurfs );), I capture it. Right now, I only use it for things like soft water/particles and some other basic depth effects. Doing ssao or dof with it will be tricky because you'll have to linearize it which, because of the infinite far z that this engine uses, is not so simple.

I repacked my mod with a few additional tweaks (microstutter fix by jkriege) and added the ROE hd mod. Theres now also wrapper executables which will start them with the HD mod enabled.
I also added higher resolutions.



Lost a bit of weight in the process

[revelator]

Oh you posted just as i did xD Thanks for the info though going to try and see what happens if i replace the crytek ssao shader in sikks with a pointer to that.

Forgot to mention Sikk has been trying to get hold on Error for registering here but had no luck so far, i gave him the names of the other admins to contact and just wanted to let you know.

[Spiney]

You could consider using a different parallax mapping algorithm, POM is terribly slow.
Relaxed Cone Step Mapping, Anisotropic Cone Mapping and Quadtree Displacement Mapping converge much faster and don't suffer from the stairstepping effect.