If your procedural levels are graphically simple and have little dynamic elements (e.g. reflections) you could bake the lighting information in your 3D application and apply the texture in runtime to the wall/floor/other static object. Since you only need a BW+A texture and not RGB+A to fake shadows the file size should be no problem. In your procedural level your light sources would only need to render shadows from dynamic objects. The different sections would have to be isolated, otherwise it’ll be obvious that the shadows are fake. Depending on your project and target hardware this technique could be a real gamechanger or have no impact worth mentioning.
Important note: I never tried to do that as the idea only occured to me when I was already working on something else. If you try it, please report back.
What a pity. The more I can customize (Grouping) the better. It surely will be welcomed when objects have perfectly aligned lightmaps, especially by modular level designers.
And have every merged actor a Lightmap Size of > 4096x4096 to have decent quality lightmaps?
Yes, from what I know eight 128x128 textures are the same thing as one 1024x1024 texture for example so texture size shouldn’t matter. I’m not sure that’s how it works out in practice though, which is why I asked, I want to know if anyone has used Actor Merge on modular assets (after designing a piece of a level) to create a single lightmap and seen if it’s viable or not for making sure modular assets don’t end up with lighting seams.
It was just a thought but I haven’t tested it myself.
Also depends on the Size of your actor. The more Merged Actors you have - take a whole room for example - the greater the lightmap needs to be.
€dit: Another point against runtime baking:
It would require Lightmass to be exposed to the players, which is a potential threat.
People can customize the Lightmaps when they catch the resulting lightmaps from Lightmass etc. etc.
It wouldn’t be hard to implement and if someone doesn’t want to use it they don’t have to, but it would be nice to have the option to have the option to fix issues like that if you want
Believe me, if I was a bit more fluent in C++, I would start rewriting lightmass right away.
Best would be if lightmass was an “independent” external executable, then it could be written in almost any language…
I would be interested on including lightmap building for a custom level editor for my game. Portal 2 has a level editor and guess what it says when you save the level you created, building lightning. So it does not have to be a main feature of your game, you can provide a lot of prebuilt levels and then give the option to the player to extend their experience creating a custom level editor. I miss all those games with their own level editor and get exited when I see one that has it.
Portal doesn’t do lighting like UE4 does, it’s impractical to put something in there to build lighting in the way that it does right now, you don’t want users waiting for hours for lighting.
Of course a Portal-sized chamber would not take hours to compile lighting… currently I’m also building a small level editor, and all my components have to movable with dynamic lighting even in-game.
If you have a scene with very low complexity and wish to do realistic real time lighting. Is this possible?. I have a scene where lighting can be spawned in and out. very basic geo and I’d like for the AO to be updated on the fly. Delays don’t matter for what I’m trying to achieve. Is this possible?
