Page 3 of 4

Re: Doom3 shadow optimization

Posted: Fri Jun 27, 2014 8:51 pm
by 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.

Re: Doom3 shadow optimization

Posted: Mon Jul 07, 2014 4:42 pm
by 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?

Re: Doom3 shadow optimization

Posted: Tue Jul 08, 2014 7:21 am
by r00k
motorsep wrote:Doom 3 BFG already does everything and more than what people have tried doing with old Doom 3. Seems like counter productive, unless it's for personal learning experience.
I read that doom3 BFG uses the rage engine? And was released as a tribute to doom's 25th anniversary ?

Re: Doom3 shadow optimization

Posted: Tue Jul 08, 2014 8:25 am
by 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.

Re: Doom3 shadow optimization

Posted: Tue Jul 08, 2014 12:59 pm
by 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.... :(

Re: Doom3 shadow optimization

Posted: Tue Jul 08, 2014 1:19 pm
by motorsep
r00k wrote:I read that doom3 BFG uses the rage engine? And was released as a tribute to doom's 25th anniversary ?
Old engine wouldn't work on consoles. And idTech 5 is designed to run on consoles and PC alike. So to bring Doom 3 to modern consoles, and to release some of the idTech 5 to the public (I bet JC knew he isn't going to be at ID any longer and that would be last chance to release idTech under GPL), Doom 3 BFG was conceived. Quick cash injection :)

So anything related to rendering, Flash menus, new fonts, a lot of internal stuff, virtual file system, input, networking and multithreading was brought up from idTech 5 (not Rage, but idTech 5 version in between Rage and Doom 4; at least for Flash framework for sure).

Multithreading is a bit cut down compare to Rage's multithreading.

Re: Doom3 shadow optimization

Posted: Tue Jul 08, 2014 1:25 pm
by motorsep
nbohr1more wrote: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.... :(
Not to be a jerk, but Mr. Beckebans has been saying this before even Doom 3 BFG was released under GPL. And since that time, there is zero proof he did so. No screenshots, no videos. Blah blah blah is what I hear all the time. If he implemented forward+, why didn't he bring it along with shadow maps into BFG ? Why did he implement horribly slow shadow mapping without a way to scale it down to match shadow volumes performance? And why implement shadow mapping that doesn't run on older hardware (note that Darkplaces has shadow mapping and can run on _old_ hardware by today's standards) ?

Re: Doom3 shadow optimization

Posted: Tue Jul 08, 2014 6:26 pm
by 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...

Re: Doom3 shadow optimization

Posted: Tue Jul 08, 2014 6:38 pm
by motorsep
nbohr1more wrote: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?
Lol, you want for your mod / game to play as many people as possible, right? Why make it possible only for people who has quite expensive hardware to be able to enjoy your product?

I tried messing with cvars for shadow mapping, but they don't seem to work.
nbohr1more wrote: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...
How do you know what issues Doom 3's experimental rendering path had if it was never working in Doom 3 to begin with ?

The amount of objects casting shadows is the same as with shadow volumes. It's just shadow volumes are cleverly implemented, threaded, etc. It seems that shadow maps were just thrown into RBDoom 3 BFG just for a checkmark "I did it, because I can" without giving too much thought to design and optimization.

Deferred rendering has its cons..

Re: Doom3 shadow optimization

Posted: Wed Jul 09, 2014 12:52 pm
by 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.

Re: Doom3 shadow optimization

Posted: Sun Jul 13, 2014 12:11 am
by 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.

Re: Doom3 shadow optimization

Posted: Sun Jul 13, 2014 5:51 pm
by nbohr1more
revelator wrote: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.
Whoah, where's the like button :)

Re: Doom3 shadow optimization

Posted: Mon Jul 14, 2014 4:50 am
by 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/

Re: Doom3 shadow optimization

Posted: Mon Jul 14, 2014 12:53 pm
by revelator
Thanks m8 :)

Re: Doom3 shadow optimization

Posted: Sun Jul 20, 2014 11:01 pm
by nbohr1more
BTW. How does the OMP implementation compare to this patch by vector fabrics:

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

?