Why I think Lightmass is completely out of Date

Hi there,

I really want to start a discussion about the way lighting is build in unreal. While we indeed have seen impressive examples. It´s very hard to get there. There are cases where lightmass simply is unable to produce clean or correct results. Some lighting behaviours are simply not to achive. For example clean mesh lightning. While all these concerns in theory may or may not be overcome with massive tweaking and faking the last and most problematic issue remains. Speed. Especially the way Network rendering is handled. I will now compare Lightmass as best as I can with Vray without comparing apples with oranges. So please read to the end before you tell me that. I choose Vray simply because that´s the renderer I know best. It should be similar for other modern renders like Octane, Corona and all the others.

  1. The render allgorithm.
    Lightmass as far as I can tell relies on Photon Mapping as secondary GI and final Gathering as Primary GI. Exactly as Mental Ray does. Basically the reason why no one really uses Mental Ray anymore. More modern renderer like Vray rely on more advanced methods for the secondary GI like Lightcaching wich is a modern way of photon mapping that is way faster much more accurate, less memory intensive and supports also indirect skylight by default. Photon Mapping the traditional style is together with radiosity the oldest and the worst allgorithm to produce indirect lighting. Also as primary GI much better allgorithms exist. Brute Force various path tracing allgorithms for example that produce absolute sharp and crisp shadows compared to Lightmass. Now one might argument that in Unreal we need to calculate a whole scene and not just an image wich is what the modern allgorithms are made for. Well, wrong. I can bake out light and shadow maps in Vray using these methods without a problem. Baking Lightmaps in Vray compared to unreal shouldn´t be to much of a difference. You have an unlit scene, you bake out lightmaps and compose them over your shader. Unreal might need to handle them later in another way or other format but that shouldn´t matter for the way light is casted to these maps in the first place. I will later in this post show some example.

  2. Some experiments.
    Most problems and lightleaks seem to happen in the photon mapping stage of lighting calculations. I switched off final gathering in the config to see how far I can crank up the photon mapping itself. Attached are two pictures. 01_UE4_PM_only.jpg without and 02_UE4_PM_and_FG.jpg with FG. This seems to be the absolute maximum quality I can get out of the photon mapping. The size of the photons seems to be controled by the parameter IndirectIrradiancePhotonDensity wich has no effect anymore above a value of roughly 2000 and by the way crashes my machine in a scene with lots of lights. As you can see in the final gather image (red circle) there is still a lightleak at the wall. This is caused by the photon mapping asthis lightleak is also visible in the photon mapping only picture. The next minor problem are dark streaks at the edges where a wall meets the ceiling for example (blue circles). They get worse as higher the quality is. There seems to be no way around this. This is highest quality I could get for an indirect lighting around a corner after tweaking the config by trial and error for hours. With standard Lightmass setting through the editor it´s even worse as you can see in the other next two pictures I attached. This is result of lighting level scale 0.1 and quality 10. See 03_UE4_PM_only_EditorSettings.jpg and 04_UE4_PM_and_FG_EditorSettings.jpg
    I attached another image wich is a lightmap rendered with Vray for comparision. 05_Vray_Lightmap.jpg I´ll talk about the speed later.

  3. Mesh Lights
    I tried using Mesh Lights in UE. I simply couldn´t get to a point where I would even get a half decent lighting quality. Blotches everywhere. The last settings I tried had brutal render times and the result was still miserable.See 06_Mesh Lighting.jpg . Just compare this to the baked Vray Lightmap wich also contains the same mesh light. It´s basically perfect. For simple Mesh Lights I tried the source radius and length parameters. Well those lights work OK if one doesn´t has a more complex shape. Yet they are not perfect. They still somehow behave like a point light. the shadows for example are wrong compared to a real mesh light.

Last but not least the biggest issue. Speed !
Let´s say all of the issues I listed above can be overcome by tweaking and maybe having a better understanding of the config parameters. Or maybe the GI quality in your case is good enough and you don´t want Mesh Lights anyway. The biggest problem for me still is the way Lightmaps are calculated in UE4. One per Process. This makes things extremly slow. The majority of render power is wasted because of this. Most of the Archviz people and probabely most of the game studios have a small or medium size Renderfarm in the office. The utilisation in UE4 is more than worse simply because every map is rendered using one virtual core instead of all computers using bucket rendering to calculate one map at a time, one after the other. You could do exactly this in Vray and you have 100% of available power used all the time. In UE all computers start. Most drop out after a few seconds and in the end you have a handfull of cores that render forever. So let´s talk about times. The UE example I attached wich uses the editor settings only, took 1400sek to finish. On all possible computers, well basically only on one because of the named issuesit took 23 Minutes and the result is still not perfect. I´m not event talking about the atomic blotches with the mesh light. In Vray rendering out a single lightmap at the same size with the same amount of computers took 40 seconds. That´s less than 5 Minutes for all 7 objects in an absolute perfect quality even with Mesh Lights. Not because the Lightmass allgorithms are slow by default simply because the way it renders, only utilizes a fracture of the available power.

In general I see the problems in the old rendering methods that are used and in the way distributed rendering is handled. It´s probabely nothing that can and will change in the near future as it´s not just tweaking a little here and there. It may sound a bit harsh but the only solutions I can image is. Rewrite Lightmass from scratch :slight_smile: . Include a third party renderer. The most reasonable and viable solution would be to open the lightmap format so that one can bring in lightmaps rendered in a third party application. Means that a lightmap can be matched to an object, wich is not the case at the moment. And that you can convert an external lightmap to the “non human readable” format that UE4 uses. I mean after all it´s just energy and color placed on a pixel. So this somehow must be possible.
I hope I didn´t offend anyone. But this is biggest problem we are running into when making projects for our customers. Very often we´re just sitting there trying to repair things that lighmass messes up.

cheers

I agree, the way Lightmass works is outdated and many of the issues could be fixed with a new renderer.

I believe this is what Otoy want to solve with their plugin for ue4 that they’ve announced a long time ago. I hope we’ll see it before unreal engine 7!

But there must be a reason why we still have that photon method, no? I’ve heard it’s even worse in Unity!

I wonder if I will live to see UE7…

Real-time G.I may be mainstream before we see the otoy’s plugin tho! That’s pretty realistic.

We All need new path tracing algorithm for LightMass…EPIC

You don’t need anything. Actually all you need is only this : V-Ray App SDK – V-Ray App SDK for Developers | Chaos
The power of VRay in Unreal. Can you even imagine that ?!

We would still need carefully unwrapped lightmaps and all though. It would not be a magical solution. I’d prefer they spend all their energies on real-time G.I hehe!

****, octane coming with unity in 2017.

starts at 1:18:15

and lightmap baking supported with octanre render’s brute force renderer.

https://twitter.com/OTOY/status/793582855104270336

Looks like it’s mostly just for preview and pre-rendering a VR spherical image, which can be useful

In my opinion we´re still very far away from a usable realtime path tracing. If you take the largest SLI Rig available you´ll still need several seconds to get a clean result. And those rendertimes I have so far only seen for outdoor scenes, wich are much easier to calculate than an indoor scenario. But to make it usable we would need to get clean results at least 30 times per seconds. Our current hardware is not even close to deliver such speed at the moment. If you take a look at Otoys demo from2014, where they use two Titan cards it still very noisy and that is an outdoor scene. So you´ll only get a clean image when you are standing still for some seconds. the quality while moving is still not acceptable.Brigade 3.0 preview - Real-time path tracing - YouTube demo from 2015 wich is mostly clean uses their cloud service wich are several thousend GPUs. They didn´t state how much actually were used.Brigade Update from OTOY's Presentation at NVIDIA GTC 2015 - YouTube
All those other Realtime GI solutions like VXGI look nice simply but don´t have the quality, specifically the fine GI details, compared to a baked GI. An hybrid GI could be a great solution where the indirect skylight is baked and the sun uses realtime GI. the best realtime GI solution I have seen so far is imperfect shadow mapping. This impressive demo is from 2008 and I really wonder why no one implemented this into an engine.Imperfect Shadow Maps - YouTube I believe if you want those real fine details that you know from non realtime rendering, GI baking will be the standard for many years. So it does make sense to invest time to polish this feature.

2 new tweets :

f1cfed03e87ef8c4b07418dddd6f3d3441675f03.jpeg

*Hayssam is a otoy dev by the way…

It’s not real time path tracing and guess what it’s still awesome. Progressive light map baking. That means we get the same quality G.I as vray/octane/corona, fast fastttttt preview of the final look of the G.I and probably a hell of a lot more precise and faster than lightmass.

Solution has to be open code based so EPIC can use code without those crappy NDA restrictions and then merge to release code. Still i really hope realtime GI will come soon. No need for Unral 7, Unreal 4 can still use 4 like Unreal Engine 4.70.0

If they can make it a plugin for UE4 then it will be easy to install and use. If they can make it bake lighting then that’s even better. I think people would be OK with increased rendering times if they can get better results.

If they opened up the way UE4 works with Lightmass as an API rather than having them so tightly coupled, it may encourage third party devs to create alternative renderers, but right now there’s no straight forward way to swap out implementations.

Lightmass is completely out of Date, too many wrongs… you cannot preview.

not progress render… light leak. you cannot preview

Now Epic should get Chaosgroup on board to implement Vray into the Unreal Engine !

not vray, corona please!

Epic should use Octane of Cebas Final Render (waaaaay faster) for the backing solution

I actually think that both modes is must have even in far future, static baked and realtime gi. Currently baking should be optimized even more so memory requirements are not so big with max quality. For Epic: perhaps you can get some idea from this too? Source/Render/Cycles/Standalone - Blender Developer Wiki