Download

Creating static shadow-maps at runtime. Possible?

… use an SSD.
Never had any issue loading anything on that game.
And the optimization on it was great for eu4.
Nearly consistent 60FPS at 4k on a 1080TI, you cannot possibly complain…

This was on Xbox. Gaming on PC is totally different! Even Cyberpunk was totally playable.

Anyway, computing shadow maps manually for two minutes when starting a level ON A PC would turn off approximately most players.
You could do a better job, perhaps, but using the GPU to render shadow maps and then flatten them to the terrain.
But then, why not just use (cascaded) shadow maps, and call it good? I tend to turn on Force No Precomputed Lighting in my world settings, and run all dynamic, and the build times are much nicer! And all shadows Just Work (tm.)

We all do. But… that’s not the same.
You can’t always do that.
And you should not unless you need to for other reasons- open world, daytime cycle, etc.

For instance, 2m loading on a mobile app to get an always seamless level gameplay is not a bad trade off… even on a switch it could really be worth the time waiting to get a realistic light effect.

Remember the skyrim days where we probably all burned at least one gfx with mods? I know I did… looked like a different game in the end though. Was almost enjoyable despite the lackluster story…

Have you made money from a mobile game that way?
What I’ve learned is that mobile players may have a total of 3 minutes for a game session – waiting for the bus, or sitting on the loo, or whatever.
Spending 2 minutes to load a game? It will absolutely not sell according to all data I have and have seen from others.
Whatever data you have would be very welcome!

No data, but its a common tactic to provide revenue by having the player watch an ad or something.
Sure, 2m is lenglengthy. But 30sec is a constant in the world of ads.
If you could get the bake to only take that long (near impossible on a mobile) you’d be able to provide a “natural” way to make revenue.

Mind you, there’s nothing natural about it. You are charging them to load a game level, which is kinda preposterous, but I have seen and played stuff made this way

Much of the above conversation is a bit of the mark of what i wanted to achieve. What I wanted, was shadow depth maps that dont update every frame, but more like every minute. I Haven’t figured a good way to do this though.

You can disable per-frame capture and only capture the scene every minute. You can also save the captures out to disk (which can be useful for a big map): Export Render Target, Import File as Texture 2D.

But for each dynamic object (e.g. the character), you will need to render the shadow map for them separately per frame. I think the engine already handles per-object shadow maps for stationary lights (Shadow Casting, bCastInsetShadow, Dynamic Scene Shadows), but not sure if it’ll work in your case; you need to look into it to see.

1 Like

Just use normal dynamic shadows. Why make things harder for no reason?

I am “making things harder” because I am trying to improve performance, so my game can run on lower end hardware. Having things cast shadows causes those things to use an extra draw-call because they are being rendered into shadow depths every frame. If we stop rendering them every frame, we will save alot of draw-calls.

Thanks, the per object shadow map thing could potentially be useful.
I already have a scene capture setup to capture scene depth at the appropriate times. My issue is setting up unreal to use those shadow depths properly.
Creating static shadow-maps at runtime. Possible? - #11 by somawheels this post shows where i am at. My shadows dont look the same as unreal’s, they have bias issues, and the blur method i am using too expensive for my liking.

You can look through the UE4 papers & presentations to see if they have implementation details in there.
Also, I don’t think you need to 100% match unreal’s shadows: most/all of the shadows are going to be coming from your method, so there won’t be many unreal shadows to cause discrepancies.

Dynamic lights do not have an extra draw call for static and stationary objects, only movable. You literally just made a dynamic light, except slower in every way due to going through blueprint and scenecapture.

Edit: Corrected myself after testing with draw calls

Like I said several times, that’s not the way to make performance any “better” either.

With RTs and captures you have some chance of achieving something close to a shadow bake without having to shadow bake.

With a material you don’t. You may as well rely on DFAO shadows.
It’s cheaper if you build properly for it.

More tris on screen = less performance. Always.

This whole conversation is ridiculous, literally all the time and effort put into this could be put into actual game optimization that any title should be doing when using UE4, and would gain far more performance than this would for it.

It might be a neat exercise for understanding how shadows are generated, but that’s the only utility this is going to provide.

All of the objects are moveable because they’re procedurally generated at runtime:


What he’s trying to do put simply (which he already has working):

  • Disable shadow casting on all lights (i.e. disable shadow rendering)
  • Capture scene depth (single channel, no color) only once per minute
  • Sample that texture in the directional light’s material function to test whether to darken a pixel (i.e. in shadow)

This is more performant than rendering dynamic shadows each frame. If only one capture happens for the entire duration of the game, the system would only be reading a texture in the material function and nothing else.

Shadows also render the scene, so this is true for shadows as well; plus, shadows have to render offscreen objects, as well, which means shadows render more triangles than the screen. For this reason, not rendering shadows is more performant than rendering shadows (hence why disabling shadows is an option).


He’s already built the system, so it’s not like he hasn’t tested it. His only problem now is fixing the bias issues.

@somawheels Have you considered modifying the engine itself to only render shadowmaps when you request it to? This way, you can have ue4 shadows, but only update them when you need to.

1 Like

You should be spawning them in as stationary, in that case. Problem solved.

Edit: New forum was being stupid and duplicated my post when i tried to edit it. Ignore post above.

Already tried that: you can’t. Set Mobility is the only mobility node, and it is only is callable in the construction script and only works on static mesh actors. And even if it did work, where is the static shadowmap going to come from when the object was created at runtime?

HOWEVER: Rama’s Blueprint Library does have a set mobility node, and it works. But it suffers from the problem above: where does the static shadowmap come from? Plus, when you change a component to static or stationary, it can no longer move (& causes warnings), so in order to move an object, you need to set it to movable first.


Once again, the main topic has already solved, so that’s not the problem anymore. It’s the biasing on the shadows; he needs them to match unreal’s shadowmaps.

Stationary objects, not light. DO NOT USE STATIONARY LIGHT IN A FULLY DYNAMIC ENVIRONMENT.

Bits360, I found this interesting, so i tested it. It was not true for me. My stationary objects still use an extra drawcall when they have shadow casting turned on.

Yeah, they are lit like Movable Actors (from Actor Mobility | Unreal Engine Documentation):

  • For Static Mesh Actors, this means that they can be changed but not moved. They do not contribute to pre-calculated lightmaps using Lightmass and are lit like Movable Actors when lit by a Static or Stationary Light. However, when lit by a Movable Light, they will use a Cached Shadow Map to reuse for the next frame when the light is not moving, which can improve performance for projects using dynamic lighting.