I am working on a game with procedural contents create at runtime to create caves.
I am using Dungen to generate my level at runtime. For people who don’t know how Dungen works,
the cave is composed of rooms and corridors which are prefabs. In my case, I have a second procedural
step that create different props for each room at runtime.
Starting from this, I cannot use lightmapping techniques, or any bake solution. I can’t bake the lighting of a room and merge it at runtime either since each room is different. I need to rely on realtime setup only. I usually put a lot of lights in each rooms, but the result isn’t great (cannot use light bounds etc).
How do you light your cave scene in your project ? Do you know any method to light an environment like this ?
If you have any technical papers on the subject don’t hesitate to send it to me.
I was thinking of using a dynamic SDF representation of the scene and use it to light my scene but I don’t know how efficient this can be.
I don’t have much experience with this, but one thing for sure is that SSAO is great to create occlusion that really gives a sense of the space in procedural levels.
They (The Elder Scrolls Blades) had exactly same problems (connected rooms from prefabs) and solved them.
They are using lightmaps with prefabs and blending lightmaps on rooms connections.
And they are using custom light probes generated from Unity light probes.
There are some more optimizations (visibility culling etc). Worth watching.
I watched this video too
But my problem is since the content inside a prefab is not static, I have nothing to pre-bake. The props of a rooms are only know at runtime. In TES, the content of a prefab seems to be static.
That what I used. But the result is not great. I want to know if any of you use special techniques to deal with lighting in procedural context. I was thinking of using unlit shaders and fake everything too. But I would like to move my project to the HDRP pipeline, and rely on the realtime lighting system if possible.
I maybe have overestimate you, so let me detail. Use render texture and custom render texture.
If you store world normal, world position and albedo in a texture, you can pass the light parameter (color, position direction) and resolve it yourself in that texture as if it’s a Gbuffer. Not only you would have light, but that light can be “baked” or “cached” such as you can accumulate lighting on it at each pass. That allow you to use more expensive diffuse light as you don’t need to update it each frame for static element. And you can use all the lightmap trick, like: store non overlapping different light intensity on a single channel, modulate them after with color and intensity only with a global tint, perfect for dungeon with a lot of candle and torch)
That texture solution can (mostly) be a RUNTIME lightmap (if you have module, you can pre unwrap, if the mesh has been compose dynamically, you can unwrap it manually at generation time).
Another solution is simply a 3D texture (native or slice atlas). You pass the light parameter and let each cell resolve itself (store direction and attenuated color by distance and shadow) then use that data sampled back by objects where each fragment just query a single cell. You will have problem with light bleeding if you don’t do a custom shadow pass (store depth from light point of view, compare to each fragment while resolving).
But mostly you really just need a custom shadow only. And accumulating with a runtime lightmap would help a lot to have complexity.
I understood a different thing in your first comment. But your explanation helps me a lot to understand what you mean, thank you. I will try to implement your ideas.
You mrntioned the rooms are prefabs while the props are placed procedurally. How about baking the light on the rooms and lit the props via light probes, treating them as dynamic objects?
By default, light probes are scene objects (data saved in the scene) and cannot be moved. I would have to create a custom probes system (like Bethesda did)
And if I baked the rooms without the props on it, the lighting will be wrong (shadows for example.
By searching more info about the ideas of @neoshaman I found info about voxel global illumination and screen space global illumination. The last one is used in Path of Exile. This could do the job without having to bake anything.
I don’t expect to have something ultra realistic. I will try to implement the most naive solution. If I got good results even with some limitations it would be enough. The only thing I want it something good enough for my game.
But I keep in mind the potential complexity.
I don’t mean in the realism, I mean in the complexity to result. I did propose a voxel solution in part of my expansion on the lightmap lighting. Going GI might be overkill.
Anyway these improvement are cumulative, a flood fill voxel light (compute light at every point of the grid then sample by all objects per fragment) is the first step to GI anyway, once that’s done you will have to raymarch. Screen space GI is ultra expensive though.
But if you want a starting point look at SEGI.
There is a thread on unity, and I posted a detailed breakdown of the shader code SEGI (Fully Dynamic Global Illumination) page-44#post-3827629
There is many post after this one that continue the break down.
