Unity's Enlighten - baked lighting a big step backward from Beast.

I hope I'm not the only person on the forums who thinks the quality of Unity 5's baked lightmapping has taken a massive step backwards compared to Unity 3 & 4 which gave fantastic results working with Beast??

We're working on mobile and are totally reliant on the 'baked' solutions and not realtime lightmapping. The reality is that huge numbers of devices especially mobile cannot support realtime due to processing time & memory issues.

The difference between the visual richness & quality of the baked lighting pipelines is very apparent. I've worked with many lighting tools over the years but feel incredibly frustrated every time I try to light a scene in Unity 5. If I had two machines with identical assets in an environment scene - one machine with Unity 4(Beast) and the other with Unity 5(Enlighten), Unity 4 would give better quality results than Unity 5 and in a faster time.

Beast gave much greater control with the XML file which would expose very specific params to balance between quality and render times. Enlighten in Unity seems to enable only a handful of features for the artist to adjust and doesn't even include the ability to change the number of bounces? Why would this be disabled, I've never known that in other apps??

Currently I'm having to seriously consider a plan B for our lighting pipeline which would involve using a external program to bake the lightmaps(which is far from ideal and I really don't want to do this!).

Unity's Enlighten also doesn't allow us to create custom atlasing in the editor which benefited us hugely on Unity 4. This has already been mentioned in previous posts on the forums but seems to have been ignored by Unity.
Also on the subject of lightmap uv packing, I'm at a loss to figure out what algorithm is used to pack all the scene objects together when baking because I'm finding Unity generates unnecessary lightmaps even though there are very obvious gapping holes in the first lightmap tpage?

I've waited until now to write this email because I was really hoping Unity would unveil fixes & possible new features to help the artist get the most out of baked lightmapping for mobile devices. This doesn't seem to be the case. Unity is a great game engine and editor, I love using it but for the first time ever I don't enjoy lighting in this package which is a great shame!

 

You can still have the same time of lightmap as other versions... just set as baked - Mixed on the lights, if I am not wrong

 

If you tweak it long enough you can get it looking similar to Unity 4, but there are some things that just aren't as good.

Your Ambient Occlusion will disappear wherever there's direct light, so it won't look as good, fundamentally. It's also harder to do a blown-out light.

Both of these issues come because it does things more "realistically", which isn't always what we want. Some of the shadowing seems "simpler", too, but I'd have to test that more.

Compare this (Unity 4) to this (Unity 5). I could tweak more, but that will never fix the AO.

 

Our development team are very much in the same boat as you and are now so frustrated at the quality of both the light baking and the UV packing that we are having serious discussions about how we can produce both our bakes and UV's outside of Unity, we just do not know what else to do. Our goal is to produce amazing art, from our previous mobile titles using Unity 4 and beast we learnt that the best route to quality is through good UV's and stunning light maps. Both of which we are unable to achieve in Unity 5's current state.

We routinely got great results from Unity 4 and Beast with relative ease, the final bakes always had a great vibrant feel, smooth colour transitions and deep saturated colours - good fun all round. Unity 5 has yet to produce one light bake which we are happy with, with a very high percentage of bakes having blotchs, noise or random colours which only clearing the Cache has a chance of fixing. It's very time consuming and frustrating (our swear box has now overflowing)

The problem is, as soon as we start trying to move away from Enlighten, weather that is baking in Unity 4, some how trying to hack Beast into Unity 5 or even trying to Bake in Maya / Modo we start eating into our man hour budgets which we would rather be spending on making our game great.

Either we need to waste code time putting together a walk around to avoid Enlighten altogether in its current form, or we try to hack Unity apart to at least give us access to much more of the lighting settings which seem to have been hidden away giving us very little control - This of course wastes Code time and then Art time testing it out.

Or we go for an external solution like Maya which again is going to waste time as it will far more complex then simply putting in some scale values and hitting bake. We will need to waste art time doing look Dev and figuring out a work flow and I'm pretty sure code would again have to get involved as well to get the results working correctly in Unity.

I appreciate that you guys over at Unity are working your hardest to get improvements into the baking system but as developers we have schedule to meet and quality bar's that need to be reached for our games to be successful. With no road map and very little communication from Unity about what improvements are in the pipeline or when we should be expecting to see them it is making our lives very difficult. Ultimately it means we are having to look into what our Plan B is as discussed above.

It would be very useful for Unity to let us know what the plan is going forward and when we should expect to see improvements.

 

Hi @KEngelstoft, do you know if Unity will be adding back support for custom lightmap altases? Unity 4 had a LightmapEditorSettings.lockAtlas, which has now been deprecated. This allowed us to create very tightly packed lightmap rects using a bespoke algorithm where artists could set a target lightmap size, and we iteratively scaled lightmap rects until they fitted in the texture with minimum wastage.

 

@Stardog - yeah the AO not visible in direct light divides people for sure(especially with stylised visuals). John Hable gave an awesome presentation for Uncharted 2 about AO which is definitely worth reading (pg148>) - http://www.slideshare.net/ozlael/hable-john-uncharted2-hdr-lighting

Hi @KEngelstoft , I have tried tweaking the settings in many ways either to get smoother results or find ways to improve the bake times but its been such a struggle and it can also give inconsistent light bakes when we need scenes baked in quick succession if alot of changes are made. This is particularly apparent during a deadline and twice now this has happened to us and really letting us down, whereas in Unity 4 it worked everytime and looked consistent in quality.

Beasts XML provided such great control between the quality of shadows, indirect, ao and the ability to add an IBL with a set rotation plus it drastically reduced render times compared to the default settings in the lightmap editor.

I think we would all benefit if Unity could expose all these hidden settings for Baking lightmaps within Enlighten as this could help in some way for us to improve the baking quality in our scenes. A friend told me Enlighten has a ton of parameters available to tweak and he was puzzled why Unity won't turn these on? This also includes vertex light bakes. Again this is something that is used all the time in mobile development(and was used alot on Gen3 consoles such as Uncharted 2 for example).

Thanks for the heads up about the atlas improvements in 5.2 beta, it will help alot although ideally we should be able to just force Unity to render everything into a specific sized lightmap such as a 2k texture and not overspill into an additonal lightmap texture. This could save so much time as normally we have to spend hours and hours tweaking tiny numbers for the object light scales and rendering each change until it all fits into one tpage. Sounds bonkers doesn't it?!

 

Making lock atlas work needs to shift some responsibility to you. Lightmap index, scale and offset are not serialized on a renderer anymore. So if you just manually set those properties in the scene they will be gone as soon as you reload.
You'd need to set the lightmap index, scale and offset from a script and kick off the bake with a lock atlas flag. Then after the bake those values would just be stored in the lightmap data asset / GI cache, so there would be no need for you to set them again. Does that sound good?

 

To be honest Beast.xml file was mostly useful to switch from final gather to a path tracer and to set the IBL.
I would be curious to hear of any other parameters that you actually found useful there.

With Enlighten we allow you to turn on final gather directly in the Lighting window (as the default is to upscale the realtime GI result) and the IBL is automatically picked up from the Environment Lighting settings.

Most of the parameters that make sense for you to tweak have been exposed in the LightmapParameters.
There's of course many more parameters in Enlighten, but they don't make sense in the functionality that we're actually exposing.

Baking lighting into vertex color is completely separate. It won't just happen by us exposing some magic parameter. It's an actual feature that complicates the system and it better be worth it. So far there hasn't been that much interest in having it: http://feedback.unity3d.com/suggestions/graphics-beast-vertex-baking

Back in the 3.0 alpha (yes, 3.0) the atlasing actually expected a budget and packed things to fit within it. It turned out that people didn't actually care about the budget. What was important instead was that they could set the resolution in texels per world unit and have the objects respect that.

Why do you care that much if it fits in one lightmap?

 

Hi @Kuba, thanks for your reply. Yep, that sounds fine. I presume you're talking about how it could work in the future, and I can't do it that way right now?

 

Hi @Kuba,

Coming from a console background, and now working on mobile we're using all the memory we possibly can, at least on our minimum memory sized machines. It's alway been the case we set a texture size that's allowed for the lightmap and the artists make the best possible use of it. If they had more space it could look better, but that's always the way.

It's been really hard for them to achieve this with Unity both due to the way scene edits or object lightmap scales cause a spill onto a second texture, and due to the fact they don't know this has happened until after the full bake. Even being able to see the packing results without having to do the actual light bake would be super useful.

Thanks,

Jools

 

I'd like to echo what @Mahoney014 and @StevieWonder have said. I don't think I can put it any better than they have already so I'll keep this short.

I work with both Beast and Enlighten. Beast is always a pleasure to work with and produces predictable, consistent, high quality results. Enlighten is very slow, produces lower quality results, is unpredictable (random blotches/noise), and has less features (no lock atlas, no control over number of bounces, no bake selected, etc).

I look forward to when lightmap baking in Unity 5 is as good as it was years ago in Unity 4.

 

Please tell me where can I find this script?

 

Hi @Kuba
yep here's a few - the Number of Bounces - I'd really like to hear from you guys why this is missing from Unity's Enlighten? Please can this be put back in???
Ability to set the max number of threads? Really handy when I need to reserve a couple back whilst doing stuff in the background. Unity 5 seems to max them out!
giTransparencyDepth - handy when dealing with lots of alpha.
maxShadowRays - nice to have separate control for the number of shadow rays.
iblTurnDome - we change the light direction all the time so its handy to be able to use this for skydome image files. In most cases I never use the procedural skies.
Some of the in depth controls are surprisingly very useful for certain cases.

The vertex baking is just a given for mobile development imo. As I mentioned in a earlier post in the same thread, Naughty Dog used this for the GI in Uncharted 2, its just so damn handy as an alternative to pixels bakes for AO and GI.

Memory/disk space and draw calls. Its imperative in mobile development that we minimise the number of draw calls especially for slower devices and we don't have the luxury to use multiple lightmaps in a given scene. Plus it saves time when rendering the light bakes. Many times during a deadline we found that a new object added to a scene makes the light bake spill into multiple lightmaps which can be very frustrating.

 

Is it possible to just put Beast back into Unity for mobile developers who are unable to use any real time lighting - I get the impression that enlighten was designed as a real time lighting solution, this is all well and good if your developing for PC, PS4 or Xbone but what mobile and tablet developers? I think we have been forgotten about in favor of next gen tech

 

I asked this back in the beta phase and the answer I got was a straight no.

My guess is that Autodesk's about-to-be-released Stingray engine, which supports Beast, has complicated things.

 

One angle to consider would be using dynamic GI as intended but realtime shadows or at least baking shadow maps. This can be a very consistent memory usage (even update from time to time ie enter a new area) and offer brilliant visuals with realtime iteration. Overall a lot less ram used.

If you really want the baked workflow to be consistent and controllable, something like VRay will blow beast out of the water.

Both options require considerable effort on the developer's part though :/

 

I was using only uncompressed lightmaps and it was important to fit everything in one 1024 map. Especially for mobile, the ram usage/draw call increase that multiple lightmaps would create is not something I wanted.

I have lost countless hours putting the lowest settings I can, and slowly rising the texel resolution until it fit one 1k map as much as possible, but not more. I even did a feature request to have it automate that process. It's super weird to hear that this was the original behaviour (which is very superior in my eyes) and was changed during alpha.

Why weren't both methods available?

 

Has anyone successfully used UVs and Lightmaps baked and unwrapped outside of Unity 5? Is it technically possible? Can anyone help with the maintaining of the lightmap info on play or on build? It is lost currently for us.

 

@Mahoney014 "Unity's Enlighten - baked lighting a big step backward from Beast."

Well.. maybe, but Unity pre computed real time GI is a BIG step forward

 

Well... maybe, but the loss of dual lightmapping is a BIG step backward. Especially since @Jde mentioned, mobile developers still need to use Baked (and would like to blend with realtime). And questions seem to go unanswered in this respect, here and potential workarounds here and no word on anything here and a foreshadowing here and some confusion about mixed mode here. However after scouring the forums I've found this post in with Engelstoft replied they would eventually add an approximation for long distance shadows--hopefully this will function like 4.x did and blend smoothly with the close, realtime shadows. But as someone who wants the most optimization from my game, dual lightmaps are a must. Not to mention the pixel light limitations (which could be solved by Baking and blending with Realtime) So some word as to what exactly is happening in this regard would be nice...

ex: How this planned approximation might work? What Enlighten 3 will bring to the table? Solutions for large scenes that don't include cranking up realtime values? Pixel light solutions? Why Baked objects don't cast shadows on Realtime and vice versa?

 

@SomeGuy22 , I didn't say Enlighten is perfect. I am experiencing a LOT of problems myself. Some of problems seems to be reported as bugs and will be fixed in 5.2 and some seems to be fixed in 5.3 with Enlighten 3.02. But I am OK with Enlighten because of pre-computed real time GI, and I think is a huge step forward, and must be keeped and improved.

I also don't agree with dual lightmaps as you said are a must. As everything go forward, I think that dual lightmaps system is old.

 

Of course! Realtime GI is great! I'm just saying what needs to improved is support. Mobile devs are out of luck because they can't go all realtime, and realtime+baked mixing is not an option currently.

I suppose the system is "outdated" in the sense that it doesn't have as much detail or realism as realtime GI with Enlighten, yes. But the simple fact that I cannot have Baked objects interact with Realtime objects is a game breaker. I could be saving so much performance and have tons of lights if we had dual lightmaps. This post and downwards has plenty of people asking for "mixed lighting" which they mean to be blending to realtime at close range and lightmaps at far range. And looking at the roadmap nothing is listed as anything close to that feature. If they make a new, updated version of dual lightmapping, I'd be happy. In fact, I'd be elated because it means I can actually release my game without shadow fades and only 1 pixel light .-.

And I don't understand the point of baking when this still occurs.

 

Not for mobile developers. Not for several more years at least.

Also, many mobile developers have large projects where a lot of time has been spent on lighting setups that look good with Beast.

If you import those into Unity 5 and just try to rebake, results are rather different... and a lot of work would be required to get the appearance back to where it was in 4.6.

And is Unity 5 really lacking the ability to bake lightprobes on their own, without doing a full rebake? (couldn't see the option last time I looked) That alone seems like a showstopper for us, as we bake our probes with a slightly different lighting setup to the lightmaps.

 

Even on non mobile targeted projects, lightmap baking in Unity 5 is hard to fully recommend for the moment.

As nice as realtime GI is (very), if you don't want to use it (for performance or artistic reasons), it can take a lot of time to get your lightmaps right.

Our experience with it so far, from 5.0 to 5.2.0f2 beta, does not give predictable enough results.
When setup properly, it's mostly good but sometimes it just breaks because you added some object that it didn't like for some unpredictable reason. Finding what works and what does not can be extremely time consuming.

Moreover, dynamic shadows have been broken for months in forward rendering mode, which is kind of ridiculous now.
Seriously, fix that.
Please

On the complain side, I can only confirm it's really slow.
I might be wrong but I always feel likes it's computing stuff that is only useful for realtime GI even if we're clearly not using it.

Finally, I maybe lack knowledge in the area but to me it's a pain to configure or understand how to.
I feel like the documentation is lacking on what parameter does what.
Some parameters seem to be shared between baked and realtime but are clearly separated in the editor UI.

Anyway, I hope this improves in the next months.

 

I have to agree what has been said here. Enlighten has been completely unusable for me since Unity 5 was released. My projects with Unity 5 are bound to real time lighting because I can't get Enlighten to do anything useful in reasonable time. It feels like all my time goes with calculating lightmaps, instead of developing game.The larger meshes you have, the more likely Enlighten will stall, and not finishing. This really problematic for ground planes and such. Not even splitting them into smaller parts really help, at least for me.
Another problem I have is the poor co-operation of baked objects and real time objects (as described here: http://forum.unity3d.com/threads/unity-5-dynamic-and-baked-static-shadows-broken.325729)
I wish there was an option to use Beast.

 

Unfortunately, they've said Beast is not returning. (At least not in the near future) Which is a shame. I took Beast for granted back in 4.x! One dev has briefly said something about planning for a way to make simplified/baked shadows for long distance but nothing in the roadmap says anything close to that. So I'd expect this lack of dynamic and static interactions to be around for a long time

 

This is the same setup, i have no control over the shadows and the bake time in the 5.0 build are much longer, i want to use unity 5.0 features but the light system of 4.6 :/

 

Am I the only one with completely broken lightmaps with the latest 5.1.3 ?

It's like it works on the first lightmap texture and then just goes bonkers, textures are filled with nonsense.

We rendered similiar scenes on different computers and one that was on 5.1.2 got no problem but two other machines with 5.1.3 got that problem.

That's the kind of thing I was referring to when I mentioned unpredictable results.

 

@HarryCodder with out any screenshots, uv maps, uv charts, is really hard to say anything about your problem.

 

To be honest, I was just wondering if anyone had similar problem with the latest version.
I ran some other tests today to be sure but the results are not out yet (those baking take so long).

Edit : Well after two nights of lightmap baking in 5.1.2, my lightmaps are still broken. So the problem does not come from 5.1.3. There must be an object in our scenes that was added and does not play well with the lightmap system. I've yet to test the same test in the 5.2...

 

I was really hoping for some feedback from the unity dev's on this one. They must have some idea of what they can do to fix the issues and give us a rough estimate on when we can expect to see it.

 

Does that mean we'll get the ability to blend realtime to baked shadows based on the "shadow distance" parameter in the quality settings? Or will it just overlap both realtime and baked shadows?

 

Hi everyone


Using Unity Personal 5.1.2. Trying to bake ligthmaps for a scene with a huge set. Weird banding on the mesh terrain ( not unity terrain ) is visible. Tried creating unity lightmap UVs ( Generate Lightmap UVs ) a number of times. Also tried exporting the mesh using Maya automatic mapping in a second UV set. Still the bake is never good. Tried increasing the Scale in Lightmap of the particular mesh terrain too..But that too didnt help. Any help would be greatly appreciated..

 

That road or train way, is huge, you have to split it in small pieces.

 

@Teo : Thanks!! The UVs that are visible in the windows are those of the terrain mesh and not the trainway. Tried splitting the terrain into smaller pieces ( 5 to be exact ), but still have the same issue. Do i need to split them further??

 

Enlighten has some great features. The Precomputed Realtime GI is great, but I concur with everyone on the thread, it is slower, less predictable than Beast. What I am sorely missing is a simple AO Bake. I simply want to bake my AO and have control of how intense the occlusion is and have it take into account all lighting. I know the goal is to make the lighting behave more "realistically", however, a lot of projects are actually designed to look very different from a VFX photo-real image.

 

Our company making mobile 3d shooters, and also join this topic to confirm Beast > Enlighten. So sad Unity decide to change Beast

 

I have been in a crossroad for ages. Unity 5 has really nice GI right out of the box but as a practical solution it has received very bad reviews, many of them regarding bugs, quality and unrealistic computer requirements.

I was told that Beast lighting was not able to work in Unity 5 because of the PBR workflow yet I got the standard shader working in Unity 4.

At the end of the day the two things that make a game look good are AO(U4) and GI(U5)....if only their was some way....to mix them together....I mean Unity 4 had its own issues where you couldn't use normal maps but Unity 5 baking is completely unusable.

My favorite method is to bake a high quality light in beast and then compress it and reduce its res to something around 256 - 1024....the results are dramatic with the lightmap being anywhere from 100 - 1mb with very low loss of quality!

Sadly my only option is the impractical and limited approach of external baking....

Ah well, don't worry, if Unity doesn't change, we customers will go somewhere else. That's how it is in the real world.

Also about the support ending, if you guys go through with it, why should we pay for it?
What are the plans for Unity 4 as it stands?

I know the key to this lies in the Occlusion slot....if you guys could allow an easy way to export the lightmaps in Unity 4 to Unity 5 and just get them to work as a texture in the Occlusion without breaking UV or something else that would be great! Then just leave the pre-comp GI at 2 res and your set! (The amount of draw calls saved from Shadow casting is HUGE)

 

Hi Silver,

I just was forced to switch to Unity 5 for a short contract and all I can tell you is the same scene which is baking as I write this looks well... how to put in nicely... Unity 4 works 5 not so much. If I could stay on Unity 4 I would, I might even try to get the team to switch engines for the next game its really that bad.

Been building games for 26 years and I have never witnessed a step back in an engine I liked until I started using the new lighting on Unity 5. I came here to find out how this happened while I wait for it to process the light maps.

This thing has been sitting at 7/11 Light Transport | 20 jobs for about 2 hours today after I left for the night yesterday it was stuck again at 7/11 Light Transport | 20 Jobs for over 11 hours.

Its like walking field filled with landmines, I don't know what obj or light is going to kill me...

I know I have some asset that is breaking but have no idea which, I started turning everything off to see if it will cycle so i can narrow it down.

ah FUBAR that is the word I was looking for earlier, god speed to you son!

-V

ADD+ Well after turning every object off in the level and reducing it down 1 dir light the terrain finished lighting. Now I guess I turn one on at a time until I break it, or go for broke and turn on the lights first and see if it works. Hmmm... love thinking about this under the pressure of a deadline.

ADD+ More progress, terrain + all my mixed lights and 2 dir fill/sun. Sort of looks pretty, now I guess going to try one object at a time until it breaks, scary how fragile it is, I have no trust of this system.

 

Hi there Vexar, the solution to your problem connects to this forum post, the issue has been postponed because it appears the its such a problem for Unity that it would require a complete refactoring on their part in order to fix it.

http://issuetracker.unity3d.com/issues/stuck-at-clustering-jobs-when-baking-lightmaps
If setting it in the importer causes issues, scale the whole scene down.
The issue of the stuck lighting is related to scaling, especially on large objects. In Enlighten the larger your scene in physical units the worse it gets, this is made even worse because Unities units and measurements are messed up, as seen by buggy and inaccurate snapping and very long units (0.22582186 etc).

Simply scale your whole scene down until its all .1 the size it was and try again, it should bake much faster, you can also try 0.01 although I wouldn't recommend it. Let me know what happens.

If it were upto me I would replace the GI with Beast. The new stingray engine from Autodesk is using Beast.

 

Couple tricks to avoid the BAKE OF DOOM:

As you add objects to your scene make sure they are under the atlas size before you copy it all over.

Use the Largest Atlas size you can, I am using 4096.

In some cases I am manually reducing the light map generation down to .00125 of its size to keep it under the danger zone this is for larger objects.

You can see which objects are going to blow through the atlas giving you the BAKE OF DOOM which will never finish by selecting the object in the lighting inspector window and seeing it an Altas warning shows up, manually reduce the size until the message goes away.

Hope this helps someone! I am using 5.2.2 at this moment. After this project I am going back to the latest version of 4 I have until this lighting issue is resolved.

 

Since its been a month and no members or Unity tech guys have answered my post it leaves me with no other place except on other peoples threads to ask my question.

Can you bake individual lightmaps in unity 5 so we dont need to keep baking out the whole entire scene every time we add something new or make alterations to one object?

I thought it was as easy as selecting the object and then clicking the build button under Lighting tab any advice would be greatly appreciated?

 

Hi there, so far I do not think this ability exists or has ever, It is a no brainer I agree but if a simple google cannot find the feature then it probably doesn't exist. I would +1 for this feature though if they decide to implement it.

 

No you can't. Selective baking is a bad feature anyway, if you change stuff in the scene the lighting changes. Light bounces around, so you have to rebuild the whole solution.

I really dislike that they ruined the tight packing in Unity to include that feature in 4.x

 

You can put an object in the scene and it would only change the lighting in the area it was placed, if you have a large level it certainly wouldn't have an effect that far as the only purpose one would need to re-render the entire scene is if you have one sky light and then rotate that because it affects the entire scene so I would disagree with it being a bad feature, it would be a godsend if implemented correctly saving so much time. In the gaming world the purpose of light baking is to remove the dynamic element from objects that do not move thus making light bouncing unnecessary. It will also still work with dynamic lights and you can see this by baking a lightmap from beast and then once it is baked shine a dynamic light on it, the result is it will still behave dynamically and hide some of the AO while a light is shining on it.

If the feature is not implemented then even if you move 1 object only a meter away one will have to re-bake the entire scene even if no changes are found on any of the other objects which is currently how it has been in both Unity 4 and 5.

I may write a paper on this in the future but it seems pointless if I or no one else will program it in especially if it is contrary to the norm.

 

Thanks for the response back AcidArrow and SilverStorm. Now Im

Thanks SilverStorm