Revelation Test

[nbohr1more]

Yeah, he stated on D3W shortly after the GPL release, that he already tried to do this but found the GPU memory needed was
too high to make it practical. It seems he's trying again...

[revelator]

Indeed

just tried it still has some bugs to iron out like depthmask issues all models are transparent and brush models are bleeding through them (could actually see a console popping right through my marine).
also some issues with light hmm.

using FBO's is a nice goal though

[revelator]

from the code it looks a bit like a variant of justins marshalls defered version but mixed with the arb2 renderer hmm, the defered version uses glsl though so it will be a bitch to find the correct places to turn off
the arb2 renderers state changers, i guess thats why its still buggy. Had the same problems with earlier glsl backends only MH's version seemed to work somewhat reliable.

Ill keep an eye on development though

[revelator]

Latest source here

changes:

exposed CopyDepthRender to the game dll's, supports saving depthimages to savegames.
reenabled some old code used for removing degenerated triangles.
added nedmalloc support.
removed one function that was used for the old renderers and was now defunct.
cleanup.
reformatting.

[revelator]

A rather extreme warning here.

Remember the bug i had with shadows ? well guess what i just found out
its caused by building with msvc 2013.
Not sure what the hell can cause this but i noticed some pointers.
Builds using msvc 2012 and earlier are also bigger, so 2013 obviously either tries to optimize some stuff away or the libraries it links to are different in a way that causes problems.

[revelator]

reverted solution to use msvc 2010 and the problems with shadow cut off are a thing of the past.
I reported the problem to microsoft so lets see if they can fix it.

[frag.machine]

Can it be related to precision loss when casting doubles to float or vice versa ? It wouldn't be the first time this problem pops in a Microsoft compiler IIRC.

[revelator]

Could be tbh its mostly guesswork whats causing it atm but im not alone, one of the devs over at the darkmod forums has the same problem :S.
Question would then be if its intended behaviour and in that case how to fix it in code (i got a hunch it might be).
In case it is then i kinda understand why RBDoom3 BFG works fine with 2013 (uses double precision float by default in idlib).

[nbohr1more]

Excuse me if I'm bringing in some nonsense but I went looking at the depth buffer code again to how it related to overdraw and noticed that
the loop sorta looks like:

For each light
Get view
fill depth buffer
allocate vertex
clear depth buffer
paint light
paint non-lit surfaces
paint post-process

Am I reading something wrong? Is this engine not reusing z-buffer for all lights and instead making a new per-light z-fill?
Is this to save GPU memory by only doing z-fill per the light bounds (at the expense of fillrate!?!)?
Tell me I'm crazy please?

[revelator]

That might very well be, remember idtech4 is rather old "2003" and i guess to cut down on the heaviest elements (there where barely any gfx cards back then that could run Doom3 on high or ultra) ,
they probably optimized a lot of stuff away. Might also explain why the floating point math was less strict and now breaks with newer compilers.
So theres lots of room for improvement but it might be a bitch.

[revelator]

And your example looks sound that seems to indeed be the way its handled.

[toneddu2000]

[nbohr1more]

Yeah, that doesn't quite line-up with how it's explained at iddev.net

Step 1:
Renders all solid (non-translucent) geometry in black. If a stage has an alpha test, then it gets rendered with the alpha test enabled. This is to fill the depth buffer so early z can prevent expensive shader ops later.

Step 2:
Render all light interactions.

For each light {
Render shadows into the stencil buffer;
For each stage in the light material {
For each surface in the light volume {
inter.diffuse = inter.specular = inter.bump = NULL;
For each stage in the surface material {
if stage is Diffuse {
if ( inter.diffuse && inter.bump ) Render( inter );
inter.diffuse = thisStage;
}
if stage is Specular {
if ( inter.specular && inter.bump ) Render( inter );
inter.specular = thisStage;
}
if stage is Bump {
if ( inter.bump ) Render( inter );
inter.diffuse = inter.specular = NULL;
inter.bump = thisStage;
}
}
Render( inter );
}
}
}

Step 3:
Renders any stage with "blend" set to something other than "diffusemap", "specularmap", or "bumpmap". This is where guis and other translucent or alpha blended surfaces get rendered (including particles).

Step 4:
Render any stage that references _currentRender. This would be heat haze, glass distortions, and other crazy post process effects.

To stay safe, I would always put my stages in the following order: bump, diffuse, specular. That way you'll always know how it will get rendered.


If the above is true, then it should be possible to reference the internal depth buffer for SSAO without writing a new one. Too bad I'm not bright enough to
tell either way...

[revelator]

hey tonnedu.

you need to use the game dll's compiled from my sources else it will crash.
The reason being some small changes in the editors (removed some unused stub functions) which also affect the game dll's.
not entirely sure if its compatible wit the steam version either

And ah nbor i misunderstood i thought you where refering to sikkpins depth functions.
well we still need to copy of the dethbuffer but that function allready exist, it was used for the exp renderers shadowmap functions, take a look inside it you will see.
But yeah that should work im not good at shaders though so someone who is needs to fix that part atleast.

[revelator]

Hum seems were not alone when it comes to floating point weirdness.
Unfortunatly for us its msvc thats correct and we have to fix the bug in vanilla :S
Msvc from version 12 has switched floating point correctness from FPU to SSE math.
So either we fix that or the only other option is using an older compiler for vanilla,
and no using an older compiler from within the msvc 2013 ide does not work,
it will still enforce SSE math no matter what you set it to.