Baking lightmaps or lightmap based GI is fine; but there are situations where there is no possible way to use precomputed data for lighting. Games which generate a level at runtime needs to use dynamic lighting. As far as I know neither UE nor Unity allows access to runtime baking.
Best thing you can do is create the level then combine the static meshes to a single mesh create an atlas send data to external renderer bake and re-import the level, and apply the lightmap. (Which on complex meshes with high poly count can take couple of hours depending on the client computer, not to mention its stupid).
So some game types have different needs and require different methods. Personally I would love to use a fast robust lightmap system which works with generic static meshes, but its not possible at the moment.
By the way I read somewhere they change the directional light rotation at runtime with pre-baked lightmap library. Since the time of the day and the sun position/rotation is pre-determined you can create a bake library and call the right lightmap associated with the light setup.Its not dynamic but can be switched when user enters/exits zones.
That’s not the kind of baked lighting I’m talking about.
Care to elaborate. Can you explain the difference in baked lighting. I’m looking at that archviz video and I’m 99% certain I could recreate that scene in cycles with the exception of the reflections in the glass vase. Not sure if that is baked?
Not so much technical info there, unfortunately. All he says is it is “very dynamic”, which is of course required for the level editing capabilities. I wouldn’t be surprised if they used some baked lighting or at least AO maps in the campaign levels, though.
Cycles baking isn’t integrated into the BGE pipeline, at all. If you just use the regular “rendered” bake, it will bake everything, including textures and glossy reflections into a single image, which is incorrect. There is no “lightmap” mode. For that, you want only the diffuse lighting, which doesn’t exist as a single render pass. Most game engines also have some way to separate out shadows (to blend with realtime shadow maps) and to add directionality, so that bumpmaps work without direct light. The (glossy) reflections are not part of the lightmaps, in UE4 those are a mix of environment maps and screen-space reflections.
I guess if you mixed together some of the available render passes and made some shaders that correctly do all the blending, you could achieve basic lightmapping. The environment maps you could also render with Cycles or the Game Engine. The other stuff I don’t think you could do without modifying Cycles.
Fast SSAO is nothing new nowadays, so I am failing to see why do you need pre-bakes solutions at all. Combining current real-time rendering techniques you can get same look and quality as lightmaps, and it will still preform well, and it will be fully dynamic. Not to mention you don’t have to worry about inconsistency in lighting static/dynamic objects and would be able to iterate in real-time.
As for baking lightmaps vs baking stuff in Cycles or any other 3D app baking - 3D app doesn’t produce 3D representation of lightmaps. In other words, Cycles only bakes shadows and stuff to the textures. If you texture your “level” with bakes images and remove lighting, and then add an object to the scene, the object will be black. In games if will be lit according to 3D lightgrid data.
In other words, there are 2 components to lightmaps in games - image baking and static 3D lightgrid baking. That was around since Quake 1, just greatly improved nowadays.
If you can get the “same quality” with realtime solutions, then why are so many games and engines still using and supporting lightmaps? Maybe because you can’t, especially on consoles. Whether you can get the same “look” or whether it is “worth it” is subjective, I would disagree here. SSAO cannot replace large-scale occlusions and like all screen-space techniques it has many issues.
If you texture your “level” with bakes images and remove lighting, and then add an object to the scene, the object will be black. In games if will be lit according to 3D lightgrid data.
You don’t remove the lights, they’re still there to light the dynamic objects. To also capture the indirect lighting from the environment, you’d usually use SH-probes. That way, the objects don’t stick out so much. That’s another thing the BGE won’t do for you, but I guess you could sample environment maps instead.
Obviously you underestimate what’s involved into developing robust all real-time rendering engine for video games. It requires a brilliant minds which are hard to find. That’s why only so many engines do that. Consoles aren’t limited by computation power. They were limited by the fillrate. Not the case anymore. Although now console are limited by the amount of RAM/VRAM.
We are talking about lightmaps. Here is a good explanation: http://omnicide.razorwind.ru/wiki/index.php/Lightgrid of classic lightmap’s lightgrid. Lights are removed in preprocessing stage. Dynamic lights are spawned when level is loaded. Dynamic lights are moving lights. Static light no longer needed with 3D lightgrid. So dynamic objects are light by the static lightgrid. That’s where performance comes with such approach - you need no lights at all to have lit scene for static and dynamic objects.
I do not know how lightmass and beast work, but gotta be something similar.
Thanks for explaining, but when I check the cycles baking options it separates out emission, specularity, shadows to name but a few. I didn’t know about light nodes. Am I missing something? I’m using blender 2.72?
cryengine 1 was the reason i found blender in 2004
Best Game Engine, like blender best 3D suite.
i heard, that the us army use the engine for realtime simulations.
Nice theory, however I refuse to believe that all the geniuses are sitting in the studios that only do full-realtime. CryEngine techniques are well-known and some are used by other developers as well (LPV, MLAA). There’s no magic to it. Even disregarding GI, stuff like large-scale AO is something that doesn’t have a good and cheap realtime solution. It simply doesn’t exist, neither in CryEngine nor anywhere else. (EPIC is experimenting with SDF representations, but it is pretty expensive. CryTek is looking into SVOs, but hasn’t shipped that, either).
Consoles aren’t limited by computation power. They were limited by the fillrate. Not the case anymore. Although now console are limited by the amount of RAM/VRAM.
This is complete bullshit. I don’t where you get that idea. Maybe you should watch some talks on what developers have to do to squeeze all their eye-candy into 33 or even 16ms.
We are talking about lightmaps. Here is a good explanation: http://omnicide.razorwind.ru/wiki/index.php/Lightgrid of classic lightmap’s lightgrid. Lights are removed in preprocessing stage. Dynamic lights are spawned when level is loaded. Dynamic lights are moving lights. Static light no longer needed with 3D lightgrid. So dynamic objects are light by the static lightgrid. That’s where performance comes with such approach - you need no lights at all to have lit scene for static and dynamic objects.
This is documentation on a game that is over 15 years old. I recommend you look into the documentation for UE, Unity, Source…
I do not know how lightmass and beast work, but gotta be something similar.
That’s right, you don’t actually know what you’re talking about. You just speculate about how things must be, but then you write it down as if it was fact.
As I said, you could mix some of these to get some non-directional diffuse lighting. Bake Diffuse Indirect, then add Diffuse Direct on top of that. In your shader, use that as the the “diffuse” term in place of the actual lights.
@BeerBaron: You can believe whatever you want to believe. The fact is that nothing n real-time rendering is easy, when it comes to performance. So obviously there is a shortage of GPU rendering genious programmers. All techniques that are openly available are generic and optimized implementation into any engine is not trivial.
Current gen consoles are basically PCs. Crysis 3 runs on consoles and it’s all real-time rendering, no lightmaps.
Neither unity nor ue4 documentation doesn’t go into details explaining how their lighmaps work.
Please point me to technical description in the documentation you linked how lightmaps work ! It’s not there. It’s just general description of the tech. Not how it works.
In all modern engine, it looks to me like lightmaps are basically baked lighting and nothing else. Ambient is done with IBL and that what lights dynamic models and static scene is excluded from lighting. Maybe back in the days they didn’t have the hardware capacity to do it that way and thus they had to store scene lighting info in 3D light grid.
I don’t know the details for baked data in Unity 5 because I haven’t used it. There are many documentation pages that help you to get an idea how it works. For details you can use the actual shader code.