[GZDoom] Shadowmaps - how resource hungry are they?
Re: [GZDoom] Shadowmaps - how resource hungry are they?
Out of curiosity, how does GTA 5 afford to render hundreds (thousands?) of shadow casting lights? Especially at night, the amount of shadow-casting lights in the city is just crazy, yet still very good framerate (55 - 60 FPS for me)
Re: [GZDoom] Shadowmaps - how resource hungry are they?
Lightmaps.
The terrain is rarely calculated in modern games - only moving objects are. The cost is, of course, that rarely do moving objects, themselves, cast lights.
The terrain is rarely calculated in modern games - only moving objects are. The cost is, of course, that rarely do moving objects, themselves, cast lights.
Re: [GZDoom] Shadowmaps - how resource hungry are they?
According to this article GTA V doesn't render hundreds of shadow casting lights. It is rendering shadows from one primary light source, the sun, which it uses cascading shadowmaps to do. For that it uses 4 shadow maps totally. Only other things it seems to do is a light-shaft map (once again against the sun only) and SSAO shadows.
All the lights from the cars are not casting any shadows. At least not according to the above article. However, keep in mind that any surface pointing away from the light source will not be lit (just like the attenuated lights in gzdoom).
Do you have any screenshots showing shadow-casting lights in the night? (pics or it didn't happen )
All the lights from the cars are not casting any shadows. At least not according to the above article. However, keep in mind that any surface pointing away from the light source will not be lit (just like the attenuated lights in gzdoom).
Do you have any screenshots showing shadow-casting lights in the night? (pics or it didn't happen )
- Kappes Buur
-
- Posts: 4122
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: [GZDoom] Shadowmaps - how resource hungry are they?
Got itGraf Zahl wrote:No tool, you have to issue 'stat gpu' at the console to get the timing.
Video card: NVIDIA GeForce GTX 660
Map: Waterlab
- Chris
- Posts: 2942
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: [GZDoom] Shadowmaps - how resource hungry are they?
Not about GTA5, but there's some interesting things going on in Doom 2016:dpJudas wrote:Do you have any screenshots showing shadow-casting lights in the night? (pics or it didn't happen )
Shadow Map Atlas
For each light casting a shadow, a unique depth map is generated and saved into one tile of a giant 8k x 8k texture atlas. However not every single depth map is calculated at every frame: DOOM heavily re-uses the result of the previous frame and regenerates only the depth maps which need to be updated.
When a light is static and casts shadows only on static objects it makes sense to simply keep its depth map as-is instead of doing unnecessary re-calculation. If some enemy is moving under the light though, the depth map must be generated again.
Depth map sizes can vary depending on the light distance from the camera, also re-generated depth maps don’t necessarily stay inside the same tile within the atlas.
DOOM has specific optimizations like caching the static portion of a depth map, computing then only the dynamic meshes projection and compositing the results.
Re: [GZDoom] Shadowmaps - how resource hungry are they?
Well, that's a different game and thus a different discussion.
What that description is leaving out is how many maps Doom 2016 is willing to update per frame (Nash said hundreds, maybe thousands). The thing about the 1D shadowmaps is that they are trying to retroactively apply shadows to ALL dynamic lights in existing maps and mods. When you fire that plasma gun every single bullet has a dynamic light casting shadows, and those are moving and thus can't cache anything at all. This is a very different game than if you have a brand new engine where you can simply tell the modders to "don't do that" when it comes to things. As a result, you can be pretty sure that whatever lights Doom 2016 has they're placed in such a way that if there is a limitation to their system you won't see it.
In any case, any kind of true shadowmap generation involves getting GZDoom to render to a 2D depth map. If someone wants to implement that they are more than welcome, but there is about 0% of the current 1D shadowmap code that can reused for such a thing. Pointing out it can theoretically be done serves little purpose unless you have someone volunteering for doing it.
What that description is leaving out is how many maps Doom 2016 is willing to update per frame (Nash said hundreds, maybe thousands). The thing about the 1D shadowmaps is that they are trying to retroactively apply shadows to ALL dynamic lights in existing maps and mods. When you fire that plasma gun every single bullet has a dynamic light casting shadows, and those are moving and thus can't cache anything at all. This is a very different game than if you have a brand new engine where you can simply tell the modders to "don't do that" when it comes to things. As a result, you can be pretty sure that whatever lights Doom 2016 has they're placed in such a way that if there is a limitation to their system you won't see it.
In any case, any kind of true shadowmap generation involves getting GZDoom to render to a 2D depth map. If someone wants to implement that they are more than welcome, but there is about 0% of the current 1D shadowmap code that can reused for such a thing. Pointing out it can theoretically be done serves little purpose unless you have someone volunteering for doing it.
Re: [GZDoom] Shadowmaps - how resource hungry are they?
Enjay map:
CPU INFO: http://cpuboss.com/cpu/Intel-Core-i7-3635QM
EdIT: I did a quick test on my raycast demo wad and it looks like the shadowmap is leaking light by doors?
Code: Select all
GPU: AMD HD8870m
Architecture GCN
Pipelines 640 - unified
Core Speed *775 MHz
Memory Speed *4500 MHz
Memory Bus Width128 Bit
Memory Type GDDR5
Max. Amount of Memory 2048 MB
Shared Memory no
DirectX DirectX 11.1, Shader 5.1 (Works fine with directx 12 and also vulkan)
Transistors 1500 Million
technology 28 nm
Features OpenCL 1.2
Notebook Size large
Date of Announcement 18.12.2012
EdIT: I did a quick test on my raycast demo wad and it looks like the shadowmap is leaking light by doors?
Spoiler:
Re: [GZDoom] Shadowmaps - how resource hungry are they?
About GTA 5: Ah, I see that only cars that my player enters in have headlights that cast shadows; no other cars' headlights cast shadows. And even then, the shadow setting in the options must be set to High for car shadows to appear.
About the "hundreds" of shadow casting lights: this is still true though. They are all over the city. Lights from shops, street lights, etc. They all overlap each other and you can see multiple shadows being cast when the lights overlap. A thousand is probably exaggerating but there's still a lot of lights.
I'm guessing Rachael is right about them being lightmaps, because those lights don't move.
About the "hundreds" of shadow casting lights: this is still true though. They are all over the city. Lights from shops, street lights, etc. They all overlap each other and you can see multiple shadows being cast when the lights overlap. A thousand is probably exaggerating but there's still a lot of lights.
I'm guessing Rachael is right about them being lightmaps, because those lights don't move.
Re: [GZDoom] Shadowmaps - how resource hungry are they?
On the Waterlab I seem to be dipping to 60FPS, I'm running 1080Ti's - seem one or two cards enabled does not matter (not strange)
I tried this on the 3.1.0 version though. I also tried the new git: gzdoom-g3.2pre-399-g04be9fe.7z since I read about the new stat gpu and stat shadowmaps and wanted to try them - I do find however that small bars that blocks light (cast shadow) in 3.1.0 does not always do so in 3.2pre-399 - is there any new parameters to play with? or is it generally being changed a bit?
I can provide screenshots showing the difference if wanted.
I tried this on the 3.1.0 version though. I also tried the new git: gzdoom-g3.2pre-399-g04be9fe.7z since I read about the new stat gpu and stat shadowmaps and wanted to try them - I do find however that small bars that blocks light (cast shadow) in 3.1.0 does not always do so in 3.2pre-399 - is there any new parameters to play with? or is it generally being changed a bit?
I can provide screenshots showing the difference if wanted.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [GZDoom] Shadowmaps - how resource hungry are they?
Keep in mind that the shadowmap feature is strictly 2D, so any two-sided wall of any kind won't cast a shadow.
Waterlabs is the ultimate test case for benchmarking this because it has so many lights. Wat shadowmap size are you using to get 60 fps? On my GF 550ti I need to set it to 128 to even work, and then only get < 30 fps.
Waterlabs is the ultimate test case for benchmarking this because it has so many lights. Wat shadowmap size are you using to get 60 fps? On my GF 550ti I need to set it to 128 to even work, and then only get < 30 fps.
Re: [GZDoom] Shadowmaps - how resource hungry are they?
There are two changes: the default shadow map resolution changed from 1024 to 128, and the shadowmap acne/aliasing tolerance was increased to make the lower resolution work. I've been wanting to add a slider in the menus for adjusting the resolution, but never got around to it. On newer cards the resolution has a very low impact (virtually all the FPS drop is due to the shadowmap sampling in main.fp), while on older cards this pass seems to be a lot more heavy.camaxide wrote: I do find however that small bars that blocks light (cast shadow) in 3.1.0 does not always do so in 3.2pre-399 - is there any new parameters to play with? or is it generally being changed a bit?
Generally speaking, the high FPS drop with the shadowmap lights are due to the PCF filtered shadowmap sampling I'm doing in main.fp. I have no doubt the current implementation could be improved there, but all my attempts so far have failed. Waterlab is probably the map with the worst impact because almost every fragment there is covered by at least 4 lights which puts extra pressure on the critical PCF code in main.fp.
Re: [GZDoom] Shadowmaps - how resource hungry are they?
Ah, Graf, I didn't know I can set shadowmap size. I've had it default as I didn't know I could change it.
Then if default is changed from 1024 to 128 that's likely why on some of my maps the shadowmap is "broken" on smaller details with 128, but not with the old 1024.
is there a command to change the shadowmap acne/alias? and if so what is the old and new settings for it?
I tested now Graf, and I had tested the map on the old version, so it was running 60fps with shadowmap size 1024
I ran it again now with the new pre version and get 67 fps with 128, and 62 fps with 1024 - though I run the map with nomonsters, but unless they have loads of lights also on them I doubt it changes anything?
Btw: Can moving lights also cast shadows? or are they "baked"? I've never seen a fireball or plasmashot cast a shadow
I also tried the set the shadowmap size higher than 1024, but that breaks it again like on 128 on some areas - is 1024 a max?
Then if default is changed from 1024 to 128 that's likely why on some of my maps the shadowmap is "broken" on smaller details with 128, but not with the old 1024.
is there a command to change the shadowmap acne/alias? and if so what is the old and new settings for it?
I tested now Graf, and I had tested the map on the old version, so it was running 60fps with shadowmap size 1024
I ran it again now with the new pre version and get 67 fps with 128, and 62 fps with 1024 - though I run the map with nomonsters, but unless they have loads of lights also on them I doubt it changes anything?
Btw: Can moving lights also cast shadows? or are they "baked"? I've never seen a fireball or plasmashot cast a shadow
I also tried the set the shadowmap size higher than 1024, but that breaks it again like on 128 on some areas - is 1024 a max?
Re: [GZDoom] Shadowmaps - how resource hungry are they?
I'm also running with Bloom, SSAO, reflections (if any) on - but the 550ti is a bit older than the 1080ti - so no wonder it's a big difference - though it'd be nice to make a small table of card vs performance - as I sit with the 1080ti's in both my rigs I can only really guess what other cards might perform like - and it'd be important to ensure my mod will run on most systems, and not just mine before I release it.. Luckily there are loads of settings now that can be turned on/off ingame to improve performance, without the need to change the maps
Re: [GZDoom] Shadowmaps - how resource hungry are they?
The lights are not baked. The fireballs and plasma shots casts shadows, but due to their small radius and high speed it is hard to spot in most cases.
Re: [GZDoom] Shadowmaps - how resource hungry are they?
I managed to improve the shadowmap light performance quite a bit by doing an early-out check for the lights. This helps a lot because a lot of lights are added for each (sub)sector drawn, but only a few of them actually cover each individual fragment.
This fact is particular visible if the lights produce specular reflections for the surfaces:
Now that's a lot of lights!
This fact is particular visible if the lights produce specular reflections for the surfaces:
Now that's a lot of lights!