I'm about ready to pass out, I pulled a all nighter last night but I had a idea to actually look inside of the Doom 3 BFG renderprogs folder, and I saw it comes with some of the missing arb shaders. It contains Carmacks original megatexture.vfp as well as the shadow mapping shaders, the only thing its missing is the bloom stuff which in theory shouldn't be that hard to re-create.

My thinking is, would it be worth while in the end to fix this up? I played with it a bit after fixing a couple crashes I got it to almost load in game when it got to R_MakeCurrent calling wglReleaseTexImageARB, which returns ERROR_INVALID_OPERATION. I haven't used wgl puffers in a long time, so I won't try and tackle that disaster till probably tomarrow, but my thinking is fixing it up might be beneficial depending on how wells things work in the current code.

Just curious what everyone's thoughts are.

What about your idtech4cdk renderer? Wasn't the shadow mapping implementation already better?

Working with WGL pixelbuffers for shadow mapping is really a method from 2004 .. I think at least your initial approach with FBOs was better.
I tried to fix the exp renderer in march and my first impression was that it was damn slow.
There were too many context switches for shadow mapping and interaction rendering. I got like 20 fps.
After that I supplemented the exp backend with my XreaL GLSL interface and my approach to render shadowmaps and especially point light shadow cubes. I use FBOs and that way I get stable 70 - 90 fps on a Geforce GTX 275. I can recommend shadow mapping with Doom 3 because it scales very well with newer gfx cards. I get 120 fps on my new GTX 660 Ti and the Doom 3 scenes are usually a nightmare for shadow mapping. I think almost no game has so many point lights that cast shadows. We also made a few tests with other commercial engines and they weren't faster.

One way you can really improve speed is by implementing light pre pass deferred shading. Standard deferred shading is too fillrate limited because the gbuffer is too fat. It is a trade-off to render the scene twice for the light buffer applied to geometry but it really allows to have 300 moving lights at 200 fps on a 3 years old card. The original Doom 3 renderer was like 15 fps. The only downside is that deferred shading approaches are only a win for non-shadow casting lights. Wolfgang Engel also supplied some ideas for massive shadow map rendering but I never invested enough time to understand it.

Tr3B wrote:

What about your idtech4cdk renderer? Wasn't the shadow mapping implementation already better?

Working with WGL pixelbuffers for shadow mapping is really a method from 2004 .. I think at least your initial approach with FBOs was better.
I tried to fix the exp renderer in march and my first impression was that it was damn slow.
There were too many context switches for shadow mapping and interaction rendering. I got like 20 fps.
After that I supplemented the exp backend with my XreaL GLSL interface and my approach to render shadowmaps and especially point light shadow cubes. I use FBOs and that way I get stable 70 - 90 fps on a Geforce GTX 275. I can recommend shadow mapping with Doom 3 because it scales very well with newer gfx cards. I get 120 fps on my new GTX 660 Ti and the Doom 3 scenes are usually a nightmare for shadow mapping. I think almost no game has so many point lights that cast shadows. We also made a few tests with other commercial engines and they weren't faster.

One way you can really improve speed is by implementing light pre pass deferred shading. Standard deferred shading is too fillrate limited because the gbuffer is too fat. It is a trade-off to render the scene twice for the light buffer applied to geometry but it really allows to have 300 moving lights at 200 fps on a 3 years old card. The original Doom 3 renderer was like 15 fps. The only downside is that deferred shading approaches are only a win for non-shadow casting lights. Wolfgang Engel also supplied some ideas for massive shadow map rendering but I never invested enough time to understand it.

This is entirely seperate from anything related to idtech 4 cdk, and this would have been something I would have typed up in a tutorial. I'm thinking about a shadow mapping tutorial after the megatexture tuts, but as it is the first megtexture tutorial I put up was around 40 pages long and shadow mapping would be almost twice that size.

Just was looking to see if it was worthwhile or not I got that impression as well that was extremely slow, but if it was like a 10 page tutorial to fix it someone might have benefited from it, but I agree it's probably not worthwhile with the bfg going open source cause it looks more like they just fixed up the exp renderer.

Tr3B wrote:

What about your idtech4cdk renderer? Wasn't the shadow mapping implementation already better?

Working with WGL pixelbuffers for shadow mapping is really a method from 2004 .. I think at least your initial approach with FBOs was better.
I tried to fix the exp renderer in march and my first impression was that it was damn slow.
There were too many context switches for shadow mapping and interaction rendering. I got like 20 fps.
After that I supplemented the exp backend with my XreaL GLSL interface and my approach to render shadowmaps and especially point light shadow cubes. I use FBOs and that way I get stable 70 - 90 fps on a Geforce GTX 275. I can recommend shadow mapping with Doom 3 because it scales very well with newer gfx cards. I get 120 fps on my new GTX 660 Ti and the Doom 3 scenes are usually a nightmare for shadow mapping. I think almost no game has so many point lights that cast shadows. We also made a few tests with other commercial engines and they weren't faster.

One way you can really improve speed is by implementing light pre pass deferred shading. Standard deferred shading is too fillrate limited because the gbuffer is too fat. It is a trade-off to render the scene twice for the light buffer applied to geometry but it really allows to have 300 moving lights at 200 fps on a 3 years old card. The original Doom 3 renderer was like 15 fps. The only downside is that deferred shading approaches are only a win for non-shadow casting lights. Wolfgang Engel also supplied some ideas for massive shadow map rendering but I never invested enough time to understand it.

How does this compare to what is being done in BFG?

From what I can tell, it's still an immediate mode renderer but appears to have 3 shadow methods?

I can't say too much on the BFG renderer yet. It does not run in the main thread with com_smp 1 and it uses parallel jobs in the renderer frontend for adding lights and models.

It is a lot faster than the original Doom 3 in testmaps/test_lotsaimps.map. However my old renderer has the same speed with shadow mapping and without any multithreading.

Thanks.

Out of curiosity, are you still planning on uploading that old renderer to your Github profile?

It sounds like a better solution all around (including your last implication...) :mrgreen:

I'm going to upload everything except the tools sooner or later. However I'm in the process of merging a lot stuff into my Doom 3 branch.
The Doom 3 BFG edition is nice but I don't want to scrap my mobile plans with it. The BFG code clutters SSE intrinsics all over the place without a #else c++ fallback and there are almost no x86 based mobile chips.

Thanks again.

What hardware generation does your renderer require as a minimum?

Shader Model 3.0 ?

Do the mobile sets really support much beyond that for the mainstream market share?

I'm about ready to pass out, I pulled a all nighter last night but I had a idea to actually look inside of the Doom 3 BFG renderprogs folder, and I saw it comes with some of the missing arb shaders. It contains Carmacks original megatexture.vfp as well as the shadow mapping shaders, the only thing its missing is the bloom stuff which in theory shouldn't be that hard to re-create.

My thinking is, would it be worth while in the end to fix this up? I played with it a bit after fixing a couple crashes I got it to almost load in game when it got to R_MakeCurrent calling wglReleaseTexImageARB, which returns ERROR_INVALID_OPERATION. I haven't used wgl puffers in a long time, so I won't try and tackle that disaster till probably tomarrow, but my thinking is fixing it up might be beneficial depending on how wells things work in the current code.

Just curious what everyone's thoughts are.

What about your idtech4cdk renderer? Wasn't the shadow mapping implementation already better?

Working with WGL pixelbuffers for shadow mapping is really a method from 2004 .. I think at least your initial approach with FBOs was better.
I tried to fix the exp renderer in march and my first impression was that it was damn slow.
There were too many context switches for shadow mapping and interaction rendering. I got like 20 fps.
After that I supplemented the exp backend with my XreaL GLSL interface and my approach to render shadowmaps and especially point light shadow cubes. I use FBOs and that way I get stable 70 - 90 fps on a Geforce GTX 275. I can recommend shadow mapping with Doom 3 because it scales very well with newer gfx cards. I get 120 fps on my new GTX 660 Ti and the Doom 3 scenes are usually a nightmare for shadow mapping. I think almost no game has so many point lights that cast shadows. We also made a few tests with other commercial engines and they weren't faster.

One way you can really improve speed is by implementing light pre pass deferred shading. Standard deferred shading is too fillrate limited because the gbuffer is too fat. It is a trade-off to render the scene twice for the light buffer applied to geometry but it really allows to have 300 moving lights at 200 fps on a 3 years old card. The original Doom 3 renderer was like 15 fps. The only downside is that deferred shading approaches are only a win for non-shadow casting lights. Wolfgang Engel also supplied some ideas for massive shadow map rendering but I never invested enough time to understand it.

Tr3B wrote:

What about your idtech4cdk renderer? Wasn't the shadow mapping implementation already better?

Working with WGL pixelbuffers for shadow mapping is really a method from 2004 .. I think at least your initial approach with FBOs was better.
I tried to fix the exp renderer in march and my first impression was that it was damn slow.
There were too many context switches for shadow mapping and interaction rendering. I got like 20 fps.
After that I supplemented the exp backend with my XreaL GLSL interface and my approach to render shadowmaps and especially point light shadow cubes. I use FBOs and that way I get stable 70 - 90 fps on a Geforce GTX 275. I can recommend shadow mapping with Doom 3 because it scales very well with newer gfx cards. I get 120 fps on my new GTX 660 Ti and the Doom 3 scenes are usually a nightmare for shadow mapping. I think almost no game has so many point lights that cast shadows. We also made a few tests with other commercial engines and they weren't faster.

One way you can really improve speed is by implementing light pre pass deferred shading. Standard deferred shading is too fillrate limited because the gbuffer is too fat. It is a trade-off to render the scene twice for the light buffer applied to geometry but it really allows to have 300 moving lights at 200 fps on a 3 years old card. The original Doom 3 renderer was like 15 fps. The only downside is that deferred shading approaches are only a win for non-shadow casting lights. Wolfgang Engel also supplied some ideas for massive shadow map rendering but I never invested enough time to understand it.

This is entirely seperate from anything related to idtech 4 cdk, and this would have been something I would have typed up in a tutorial. I'm thinking about a shadow mapping tutorial after the megatexture tuts, but as it is the first megtexture tutorial I put up was around 40 pages long and shadow mapping would be almost twice that size.

Just was looking to see if it was worthwhile or not I got that impression as well that was extremely slow, but if it was like a 10 page tutorial to fix it someone might have benefited from it, but I agree it's probably not worthwhile with the bfg going open source cause it looks more like they just fixed up the exp renderer.

Tr3B wrote:

What about your idtech4cdk renderer? Wasn't the shadow mapping implementation already better?

Working with WGL pixelbuffers for shadow mapping is really a method from 2004 .. I think at least your initial approach with FBOs was better.
I tried to fix the exp renderer in march and my first impression was that it was damn slow.
There were too many context switches for shadow mapping and interaction rendering. I got like 20 fps.
After that I supplemented the exp backend with my XreaL GLSL interface and my approach to render shadowmaps and especially point light shadow cubes. I use FBOs and that way I get stable 70 - 90 fps on a Geforce GTX 275. I can recommend shadow mapping with Doom 3 because it scales very well with newer gfx cards. I get 120 fps on my new GTX 660 Ti and the Doom 3 scenes are usually a nightmare for shadow mapping. I think almost no game has so many point lights that cast shadows. We also made a few tests with other commercial engines and they weren't faster.

One way you can really improve speed is by implementing light pre pass deferred shading. Standard deferred shading is too fillrate limited because the gbuffer is too fat. It is a trade-off to render the scene twice for the light buffer applied to geometry but it really allows to have 300 moving lights at 200 fps on a 3 years old card. The original Doom 3 renderer was like 15 fps. The only downside is that deferred shading approaches are only a win for non-shadow casting lights. Wolfgang Engel also supplied some ideas for massive shadow map rendering but I never invested enough time to understand it.

How does this compare to what is being done in BFG?

From what I can tell, it's still an immediate mode renderer but appears to have 3 shadow methods?

I can't say too much on the BFG renderer yet. It does not run in the main thread with com_smp 1 and it uses parallel jobs in the renderer frontend for adding lights and models.

It is a lot faster than the original Doom 3 in testmaps/test_lotsaimps.map. However my old renderer has the same speed with shadow mapping and without any multithreading.

Thanks.

Out of curiosity, are you still planning on uploading that old renderer to your Github profile?

It sounds like a better solution all around (including your last implication...) :mrgreen:

I'm going to upload everything except the tools sooner or later. However I'm in the process of merging a lot stuff into my Doom 3 branch.
The Doom 3 BFG edition is nice but I don't want to scrap my mobile plans with it. The BFG code clutters SSE intrinsics all over the place without a #else c++ fallback and there are almost no x86 based mobile chips.

Thanks again.

What hardware generation does your renderer require as a minimum?

Shader Model 3.0 ?

Do the mobile sets really support much beyond that for the mainstream market share?