Hello!
Programmer here…
I have a tile-based editor similar to ‘stunts’ that lets the user define a 3D scene in a grid.
Each tile contains some static, stationary object.
Ideally I’d like to bake the lights and shadows at run-time when the user hits ‘save’.
Is there a way to do this at run-time? if so where is this covered in the documentation?
Blueprint or C++ is fine.
Thank you
Hi Dan,
Lighting cannot be baked at run-time. Lightmass baking can take some time depending on the complexity of the scene. It’s intended to have the lighting baked before you play the game since the light is being baked down to a lightmap texture. Dynamic and stationary lighting would be the options to use in this type of situation.
Tim
My mistake, I should have explained that it is obvious this task takes time. I have 20+ years experience as a game programmer, but I can see how this could be a short-cut answer for beginners.
Simply, that’s not an answer to the question I asked.
I want the performance benefits as well as the visual quality of baking lights and shadows.
Let’s assume I know and my users know that the baking process is going to take time.
An extreme solution would be making a desktop automation task that farms the process off to the Unreal Editor running on a dedicated virtual machine server. Ideally however, I’d rather have that task running on the user’s machine.
Is there nothing I can do short of a hacky automation? Perhaps there are some resources in the Unreal Engine source code I might find helpful?
He answered your question correctly, in a built game you can’t bake lighting, it doesn’t contain any of the lightmass code that is used for that or any way to access it.
Any solution would require some work on your part, you could make a unique file format that you could send to a server that could automatically rebuild the level in the editor and then build lighting and then send the built result back. But as far as having it run on the user’s system, that might not be possible, I don’t think you’d even be allowed to try and reuse code from the editor within your game to be able to do it. And the only other option is for the user to buy a UE4 subscription to get access to the editor.
The alternative is to use LPV or some other fully dynamic GI solution. This would be a much better option to develop going forward than a gametime lightmass bake, which can take hours. Part of the problem with running lightmass is that every aspect of a level that touches the sun must be baked at the same time as long as it exists within the same world. Otherwise, the lighting would not be accurate. For a small game this might not be much of a problem, but for a larger game, this definitely would be. Depending on the size and complexity, lightmass can take between half a minute to a few hours to bake, assuming you have a decent i7 CPU and about 8 GB of RAM.
If your game is mostly an outdoor environment that relies on sunlight and a few other dynamic lights, then LPV with skylights are totally a viable option. Otherwise, you’ll just have to wait for Unreal 5 to re-implement SVOGI. I don’t think UE4 will get a perfect dynamic GI system that works well with pointlights, spotlights, and emissive materials.
Just do what 99% of the games that have dynamic levels do: sun-light real-time shadows (use a dynamic directional light and configure the cascade shadows to your liking) + real-time skylight + SSAO. Maybe add some pre-made occlusion maps to some objects so they have look nicer when not lit by sunlight.
Guys? So negative so soon. If baking wasn’t possible at runtime, then how is the editor doing it?
Lightmass is something that’s only within the editor, not the game. It would be possible to build it into the game but that would be very complicated and might not actually be allowed due to how it would use the editor code.
Hi, Tim,
I’m sure the scenario OP meant to pose was a game that comes with the ability for users to create custom levels or scenes. I’ve run into situations where I wanted to build a game that came with an editor but for performance reasons (in VR projects especially) lightmapping is the only viable lighting solution.
Assuming a developer did the work necessary to modify the UE4 source code to call lightmass to lightmap a level much like the editor does, do you know if we’d be allowed to ship that?
Thanks
Hi. Google just brought me to this topic…
What if I want to procedurally generate random levels from “parts” at runtime? How would I deal with lighting then? And would performance suffer just because “baking” is disabled without the editor?
Is it not intended to support procedural level creation?.. Why? Isn’t that a must these days?
In that scenario dynamic or stationary (dynamic would be the best option for purely procedural generation) lighting would be the best option.
Procedural being generated at runtime? In that case, pretty sure it isn’t. Lightmass (and any form of baked lighting) is intended to be pre-computed, to have the hard work done ahead of time and the results being shipped with the game as light maps that can just be applied to geometry to allow for high quality static lighting with no cost. If you have a scene which doesn’t change at all during runtime (a multiplayer map that doesn’t change or a map which the player really only plays in for a short amount of time) and you want high quality lighting, Lightmass and baked lighting is the best option if you really want the highest quality for the best performance and don’t need dynamic lighting. If you absolutely need dynamic lighting, say you have a dynamic day/night cycle complete with dynamic shadows, dynamic GI, etc, then dynamic lighting is the best option and in this case baked lighting plainly won’t work: only geometry that existed during baking would be lit (unless far as I know the light is stationary, then it’s sort of half-half, far as I know).
It’s pretty much this: baked lighting is very high quality and great accuracy at the cost of being static, it cannot change during runtime and the work is done ahead of time and packaged as lightmaps for the final game, dynamic lighting is a mid-quality option that has fairly decent accuracy, pretty good scalability (if you need to, you can sacrifice quality and accuracy for performance) that is dynamic and supports both dynamic geometry receiving lighting and dynamic lights lighting up the environment at the cost of being more expensive. If you have things generated during runtime, dynamic lighting is the way to go, Lightmass is not designed for runtime procedural generation.
It is definitely not a “must”, because most games don’t do that properly these day.
Calculating lighting is computationally expensive process that can take hours on powerful machine (depending on what kind of level you have). So it won’t make much sense at runtime.
In addition to that, epic license forbids inclusion of editor tools into your code. You’re free to come up with your own method of calculating lightmaps at runtime, though.
If you need dynamically constructed levels, you’ll probably want to use dynamic lights for them. Given that engine is fairly fast, in many cases you should be able to get away with that.
Ok thanks for answering. I will have to see what performance I will get and maybe adjust level sizes or use streaming or something. It’s not a work in progress yet as I’m still busy with other things, but it’s good to know about this ahead of time.
… I still think good support of procedural/dynamic generation of environments is very important for a game engine, maybe not for AAA titles, but for innovative games.
Hi again. Since both of you recommended dynamic lighting (and since I still haven’t actually worked with lighting yet…), I was wondering if there isn’t any optimization for static geometry, even though it was generated at runtime.
I mean, the idea is to randomly generate a building-complex, for example. When it’s done, the geometry is (more or less) immovable. The same goes for most of the light sources: lamps and such that may be turned on or off, but generally don’t move. My idea of a dynamic light is that it updates lighting on surrounding surfaces every frame, which would be a waste in this scenario. Is there a way to optimize here? Or do dynamic lights only cost performance when they are actually moving (or something is moving inside their radius)?
Dynamic lights are rendered to screenspace. They don’t have any intermediate storage where it could “optimize”/store things. So for every frame all dynamic lights that are seen by camera are rendered. Light cost scale by it’s size by pixels.
And there is nothing in between? Only light-maps baked in the editor and dynamic lights? No other way to deal with runtime-created static geometry/lights?
Apparently Halo 5 uses static lightmaps for their forge mode which is a really interesting concept indeed as the result is pretty good and barely takes time to render.
Source, scroll down to the lighting paragraph.
https://www.halowaypoint.com/en-us/community/blog-posts/building-the-biggest-forge-yet
still not possible ? its really needed
I come from the future, dynamic lighting is still the best option so far.