Bake static shadows, dont bake dynamic shadows

So is it possible to bake the result of the above ^ for static objects like tables and such?

I was thinking in a scene, it could be possible to take the result of the pcss shadowmap and only render it once to a texture or something and project it the same way its being projected with the shadow camera.

I wanted to know whether it was in the realm of possibilities.

Yes it’s possible by using an offscreen scene/canvas.
You render() your floor, a single time with an orthographic camera, then use the canvas as a texture.

You can even use more complex shenanigan since it’s a whole scene captured by a camera.
Like hiding the objects projecting the shadows (require various tricks and your case may need them), adding colors/textures, drawing fake shadows by directly using ctx.drawImage(), re-project your texture/shadows again using spotlights maps.

I posted some code for this (very primitive) method here:

1 Like

Maybe create scene_2 with only box and directionalLght_2.
Disable autoUpdating shadow at directionalLght_2.
Run once:


Then run main renderer.
directionalLght_2 must be add and to main scene. scene.add(directionalLght_2);
directionalLght intensity must be 0.5 and directionalLght_2 intensity must be 0.5
directionalLght shadow must be with autoupdating


it’s what this component does:

although it uses some tricks to create more realistic shadows.

source is here: drei/AccumulativeShadows.tsx at 0eed7f1e26e634ae320fe126222e8a3499d8697d · pmndrs/drei · GitHub

it was loosely based on this example three.js examples

1 Like

How would I be able to use the accumulative shadows without the react part? :sweat_smile:

1 Like

i posted the source. though i admit it’s a quite complex set up. but still a lot easier than trying to make the three example work imo. i struggled a whole week trying to pull it apart, and i still don’t understand all the potpack stuff, not to mention that the three thing doesn’t actually bake.

you’ll see yourself in that spot over and over again. use react and three because why not. all it does is allow you to make sharable interfaces, like accumulative shadows, hence there is a real eco system, far larger than anything in plain three. three alone can not have that because classes are inapt for sharing, reason why the shadowmap example is more like a whole application you need to untangle and re-purpose whereas outside of OOP you just write <AccumulativeShadows> and it’s done. but if that’s not an option, there’s only the drei source and the progressivemap source, nothing else exists to my knowledge.

1 Like

interesting idea, but would this not make shadows lighter than they should be

Maybe into shader multiply shadow color to 1.5

1 Like

You make a fine point. The only issue is really thinking about using a UI pattern to create a threejs game or experience.

Is it possible to just call in a non-react setup? I mean what if you want to create a dynamic scene where you are loading many models, i guess the scene hierarchy would have to be made up of

no, not really. it’s either this or trying to re-purpose the code for your game, just like the threejs example, going through it all line by line and making it your own.

1 Like

you can also use contact shadows in a similar way .

Instead of updating it in the animate loop like in the example, you can update it another function (call it ~60 times to get proper blur)

does not look as good as the react-shadows but it’s blur quality is nice & once it’s computed there’s no extra performance penalty


Thanks for the suggestions.

I think contact shadow would be a nice effect to have combined with accumulative shadows / progressive lightmaps.

I will probably try the progressive threejs only example and then go for the accumulative react component and try to build a react-three app.