I'm not a big fan of this:

# request a shadow update only for the next frame
sun.requestShadowUpdate = True

Such a "request" is not a property of the object in the literal (not-computer-science) sense of things. It would be better to create a method for this.

Can you give us an example blend file? Some more information on how much this improves performance, and which other game engines that use this feature would be nice.

Looks quite good IMHO. A few comments though:

Just some small clarifications in the documentation; see the inline notes.

There is one more thing, though, and that's visible in your example blend file F197082. It seems that not updating the shadow causes the robot's shadow to be cast on the robot itself. This looks really strange, and I don't know whether this is something people would actually want to use. You also didn't give any examples of games or game engines where this feature is used (see comment D1372#27735).

Of course I see the benefit that not updating something may lead to better performance. However, I'm not that eager to add new features when we don't know the performance gain, do see a downside to the feature (the strange self-shadowing), and don't know how many people are actually waiting for this feature.

Hello! From what I've read (and understood) on the subject, it seems that unreal engine 4 has this option for example: https://docs.unrealengine.com/latest/INT/Engine/Rendering/LightingAndShadows/LightMobility/StaticLights/index.html
https://answers.unrealengine.com/questions/97291/static-and-dynamic-shadows.html

Another option I've seen is to make shadow dynamic within a certain distance... Personnaly, I think that's a nice feature which can be usefull to have good shadows on foliages that costs not much performances, or in a room with static objects, and to avoid baking shadows on each object you want to generate shadow...

Just my noob advice, but I've not think about it during hours and I don't know what inconvenient it can produce.

My reasoning is not the same as Sybren's one. I think the more control you have on lights, objects..., the better it is (unless it's hard to maintain or it can generate bugs in the future). I think there's no need to ask for users opinion on this subject (but many forums on the net are related to static shadows) because it doesn't take something away from users, it simply gives users more control in the game engine.

But I can change my opinion since I've not much think about that :)

Have all a great day/night!

In D1372#30026, @Ulysse Martin (youle) wrote:

Hello! From what I've read (and understood) on the subject, it seems that unreal engine 4 has this option for example:

Nice. That's also even one step further, and also makes the light itself completely static. UE4 bakes light maps etc. much more (or at least more automatically) than we do in the BGE, so there it makes more sense to optimize static stuff. Maybe we should think about easy light map baking etc. for a future incarnation of the BGE too ;-)

Another option I've seen is to make shadow dynamic within a certain distance... Personnaly, I think that's a nice feature which can be usefull to have good shadows on foliages that costs not much performances, or in a room with static objects, and to avoid baking shadows on each object you want to generate shadow...

I agree! That would make things much easier to tweak too, as now this distance comparison (if you want that functionality) needs to be done in Python, and for every frame and every lamp.

I'm a scientist too, so I like numbers and comparisons. It would be great to see an example scene with "this scene only renders at X FPS with dynamic shadows, but when we enable static shadows it runs at Y FPS".

My reasoning is not the same as Sybren's one. I think the more control you have on lights, objects..., the better it is (unless it's hard to maintain or it can generate bugs in the future). I think there's no need to ask for users opinion on this subject (but many forums on the net are related to static shadows) because it doesn't take something away from users, it simply gives users more control in the game engine.

Yeah, I'm a bit more pessimistic about new features. When they are actually needed: great, we should add them. However, it's all to easy to add new features because they seem like a good idea, and not because someone is actually needing them. This then leads to (at least at that moment) more or less useless code that does add to the complexity, and thus makes it easier to create bugs, harder to refactor things, etc. But as I said, I'm kinda pessimistic in that respect ;-)