Doom3 shadow optimization
Re: Doom3 shadow optimization
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.
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.
Productivity is a state of mind.
-
- Posts: 54
- Joined: Fri Dec 09, 2011 7:04 am
Re: Doom3 shadow optimization
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?
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
I read that doom3 BFG uses the rage engine? And was released as a tribute to doom's 25th anniversary ?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.
Re: Doom3 shadow optimization
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.
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.
Productivity is a state of mind.
-
- Posts: 54
- Joined: Fri Dec 09, 2011 7:04 am
Re: Doom3 shadow optimization
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....
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
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 injectionr00k wrote:I read that doom3 BFG uses the rage engine? And was released as a tribute to doom's 25th anniversary ?
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
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) ?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....
-
- Posts: 54
- Joined: Fri Dec 09, 2011 7:04 am
Re: Doom3 shadow optimization
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...
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
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?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?
I tried messing with cvars for shadow mapping, but they don't seem to work.
How do you know what issues Doom 3's experimental rendering path had if it was never working in Doom 3 to begin with ?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...
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..
-
- Posts: 54
- Joined: Fri Dec 09, 2011 7:04 am
Re: Doom3 shadow optimization
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.
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
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.
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.
Productivity is a state of mind.
-
- Posts: 54
- Joined: Fri Dec 09, 2011 7:04 am
Re: Doom3 shadow optimization
Whoah, where's the like buttonrevelator 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.
-
- Posts: 54
- Joined: Fri Dec 09, 2011 7:04 am
Re: Doom3 shadow optimization
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/
https://bmgame.googlecode.com/svn/
-
- Posts: 54
- Joined: Fri Dec 09, 2011 7:04 am
Re: Doom3 shadow optimization
BTW. How does the OMP implementation compare to this patch by vector fabrics:
http://www.vectorfabrics.com/blog/item/ ... ame_engine
?
http://www.vectorfabrics.com/blog/item/ ... ame_engine
?