Revelation Test

Discuss anything not covered by any of the other categories.
nbohr1more
Posts: 54
Joined: Fri Dec 09, 2011 7:04 am

Re: Revelation Test

Post by 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
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by 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 :)
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by 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 :)
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by revelator »

Latest source here http://sourceforge.net/projects/cbadvan ... z/download

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.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by revelator »

A rather extreme warning here.

Remember the bug i had with shadows ? well guess what i just found out :shock:
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.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by 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.
Productivity is a state of mind.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Revelation Test

Post by 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.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by 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).
Productivity is a state of mind.
nbohr1more
Posts: 54
Joined: Fri Dec 09, 2011 7:04 am

Re: Revelation Test

Post by 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
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by 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.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by revelator »

And your example looks sound :) that seems to indeed be the way its handled.
Productivity is a state of mind.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Revelation Test

Post by toneddu2000 »

Hey revelator, compiled last sorce (and even an older one - two weeks older or something) and it freezes on loading screen (about 15/20% loaded) on Steam Doom3. Tried also to launch a map via "map" console command but it crashes the same way.
Debug version, instead, crashes imediately after exe launch. Did this also happened to you?
I compiled with Visual Studio 2013
Remember the bug i had with shadows ? well guess what i just found out :shock:
its caused by building with msvc 2013.
Unbelievable. I'll try with 2010 and let's see what happens! :D
Meadow Fun!! - my first commercial game, made with FTEQW game engine
nbohr1more
Posts: 54
Joined: Fri Dec 09, 2011 7:04 am

Re: Revelation Test

Post by 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... :D
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by 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.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by revelator »

http://stackoverflow.com/questions/2432 ... 8-and-2013

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.
Productivity is a state of mind.
Post Reply