Doom3 shadow optimization

[revelator]

Old code is still plenty viable even with BFG around it just had some nasty bugs with ATI cards and ill be damned if i let that keep me from making it work

But if you look at the thread for the revelation test i dug up why the weird shading is happening, it has actually nothing to do with the shadow code but with ATI/AMD using adaptive multisampling which screws up image_filter = GL_LINEAR_MIPMAP_LINEAR -> trilinear texture filtering. if you set it to GL_LINEAR_MIPMAP_NEAREST it works great . I have modified the engine accordingly and am now focussing on getting the internal editors finished (some need some work like the PDA editor) and hopefully gathering someone who can help me port them to WxWidgets for multiplatform use.

[nbohr1more]

So this is now the Relevation repo at Github?

I see that you've added the constrain shadow volumes to light volume and vis leaf optimization?

I created a bountysource tracker for GPU skinning against raynorpat's "Morpheus" branch since I wasn't sure whether you'd be including his GLSL
work. Do you plan on trying to port GPU skinning too?

[r00k]

[revelator]

part Vanilla part rage and none of rages megatextures.

Not sure if even possible to port bfg's gpu skinning to Vanilla but rest of the glsl backend should be possible - the bink code.

[nbohr1more]

Well, according to Mr "Robert Beckebans" the entire renderer from BFG was ported to vanilla Doom 3 for his commercial project. Though
that still doesn't tell you whether you need to throw out some vanilla map\asset\script etc features to get it working... (So the word possible
may be relative...)

He also claimed to have changed the light rendering to a forward plus implementation and added his parallel split shadow map implementation
prior to doing the BFG port operation. That yielded performance improvements similar to BFG but he choose to do the BFG port since it
would also improve the general infrastructure for the engine and grant better multi-core scaling.

A pity he is keeping this work behind closed doors until he either has completed the commercial project or switches to UE4....

[motorsep]

[motorsep]

[nbohr1more]

Heh, well I don't have the credentials to doubt one of the core ioquake coders and the creator of XTReal but... sure, it's possible that his
claims are exaggerated or false.

The shadow-mapping in RB BFG seems to have more shadow map samples at default that a typical commercial release, but he has the luxury of not needing
to care about the low-end.

I haven't played with it but have you tried lowering the sample taps?

That said, Carmack's EXP renderer also had problems with Shadow Maps. The amount of shadowed objects per scene in this game is much
larger than a typical light-mapped game. Yes, a deferred solution would help there too...

[motorsep]

[nbohr1more]

I believe raynorpat tried his hand at getting shadowmaps working earlier on after the Doom 3 release (as I recall from the D3W forums) and found that the memory
footprint was too large. Deferred rendering didn't help that and also had it's own memory footprint issues. Of course, it would help if D3's assets were using more modern
compression and I don't know what he choose to do about packing the gbuffer since most deferred solutions sacrifice some quality attribute in one or more of the passes
to save space in the gbuffer (usually mushy looking normal maps for the commercial engines I've seen, not really possible to get away with such degradation in Doom 3
since it relies on those so heavily)...

From what I can tell, Forward+ rendering does seem to be a better fit (if anything) because Doom 3 already sorta acts like a Forward+ renderer with
it's z fill pass and light visibility evaluations.

[revelator]

Atleast on modern Cards shadow volumes should not be a problem but it puts a considerable strain on older Cards
shadowmaps also have there downside like not working on certain objects so its a bit of a mixup between shadow volumes / maps.
Vanillas exp renderer was rather nasty (using WGL functions) so it was not really portable, looking at RBDoom3's version atm might be able to get it working on Vanilla as well.

[nbohr1more]

[nbohr1more]

I'm not sure this will help but here's a link to jmarshall's radical doom 3 engine revision. It has shadow mapping code so perhaps it can act as a guide to where you might hook treb's implementation?

https://bmgame.googlecode.com/svn/

[revelator]

Thanks m8

[nbohr1more]

BTW. How does the OMP implementation compare to this patch by vector fabrics:

http://www.vectorfabrics.com/blog/item/ ... ame_engine

?