Baked lightmaps in procedural game

Hello everyone!
I’m currently working on a project where the level is procedurally generated. (See image).

Each of the objects in rooms are disposed by hand, then each room is stored as asset through scriptable objects (allow the use of “prefabs in prefabs”), which store reference and transform values of each prop.

At runtime, only the current room we’re in and the possible adjacent ones are loaded, thus allowing for a better memory management. But here’s come the lighting problem. Indeed, we’d want each room to have it’s own lighting, and were considering our options.

1. Baking lightmaps : Baking lightmaps for prefabs and objects, knowing that there’s no saved instance of objects but only reference to the original prefab, seems doable after some research ( but would induce a quite heavy workload.

***2. Instantiating dynamic lights *** for the current room only : We could have our dynamic lights lighten not only the dynamic gameObjects in each room at runtime, but also all the static props and objects that would not move, resulting in fastest development process, but heavier on performance.

How would we know which way to go? How terrible are dynamic lighting and which are the limits on average computer? As we’re looking to save time, it seems tedious to code and test both options so we’d love some insights for more experienced users.

Many thanks! <3!

I am interested in your question as I am developing a fully-procedurally-generated game.

Any developments?

What we did basically was baking each prefab individually and messing around with the API to switch lightmaps at runtime. Since then I believe lots of users encountered this problem and some even made fixes available online. I haven’t looked at this but it seems to do just exactly what we wanted at the time :

Hope this will help you :slight_smile: