Lightmapping is much slower and looks worse.

Like others, I've been experiencing some problems with the new Enlighten lightmapping system so I decided to do a like-for-like comparison with Beast.

The results show that (in my test scene at least) the new Enlighten system is five times slower than Beast and results in a lower quality lightmap.

As you can see in the images below, the Enlighten lightmap has blotchy, multi-coloured artefacts (most noticeable in the second and third image). It also seems to show some strange square, grid like artefacts (third image, shadowed side of the cube).





The scene is about 280m by 380m in size. All meshes (including terrain) are built externally and imported as fbx. I used beta 5 for the Beast bake and beta 17 for the Enlighten bake (Beast is no longer available in beta 17). It's also worth noting that the Enlighten bake is set to VeryLowResolution because HighResolution bakes crash Unity for me (bug 658437).

So my questions are...
Are the things I'm seeing bugs or expected behaviour?
Can we expect parity with Beast, in terms of both speed and quality, in the final version?
If not, will Beast still be available as an option?

Thanks

 

Color artifacts looks like from DXT-compression and can be removed in one click i guess - in lightmapping settings (in "Baked GI" section) disable checkbox "Compressed".

 

I'm set to iOS platform so it's actually PVRTC compression, and both sets of lightmaps are compressed in the same way, so it's not that (or at least not just that).

 

I think if you have Realtime GI enabled for the bake then Enlighten is not just calculating the static light maps as per Beast but also calculating the lighting 'constants' that can be used for Realtime GI. Disabling Realtime GI will make your bake go faster.

 

I have Realtime GI disabled in the Lighting window so it's not that either. Unless there's something else I need to do to turn it off?

 

i have a similar problem. the quality is worse than with beast



besides the bad quality on the wall there are white areas on the transparent polygons.

 

looks like compression, what are your settings? do you have "Compressed" checked under Baked Lightmaps? what platform are you targeting?

 

at the moment its for no special platform.. standalone windows..
the lightmaps are 2048 with a baked resolution of 60. defaul high resolution. all lightmaps true color.

 

Can you post your enlighten settings? I am an avid user of Beast and I can tell you right now that your baked resolution is probably too low and your altas size is too low for all of that terrain.

 

Turn up your baked resolution. 60 is too low. Also, you need some more indirect bounces. Once Unity 5 officially releases, I will plan on doing a tutorial on enlighten

 

I also find the baked light maps below standard. People talk about settings but the default settings should at least look better then realtime lights and shadows.

This is what my terrain looks like. Horrible banding (bug filed):

 

The Unity 5 lightmaps look really really bad with compression on for me, worse than I remeber U4 lightmaps with compression looked like. But disabling the compression made them look pretty nice. I use them in this little, simple scene:
http://www.animechtechnologies.com/kinnarpsdemo/
Very clean lightmaps imo.

 

I usually disable the compression for lightmapping... lighting is one thing you should never skimp on...

 

There is no "correct" baked resolution for lightmaps. If the environment you're baking is the size of a shoebox then 60 might be too low, but if the environment is the size of a city then 60 is insanely high (you'll end up with a bazillion lightmaps).

Also, disabling compression is not really a solution. I've been using compressed lightmaps for years with no problem. The Beast lightmaps in the original post are compressed and they look fine.

But all that is beside the point. The images in the original post are a like-for-like comparison, so if I change those settings just for Enlighten it would not be a fair test.

Currently, like-for-like, Enlighten takes much longer to bake and the results look worse than Beast (I've not tried beta 18 yet but I'll be doing that next week at some point).

 

I usually use compression once I get a look I like... in my case, the game will be moving so fast no one is going to notice. I am also testing Enlighten using a Cornell Box to get the maximum look from the lighting with compression OFF and it looks fantastic. When in Production, I keep the GI to realtime to get the look I am aim for... and then I bake down when I like what I see.

I am looking at my shot, and yes I see the compression artefacts, but that is a tradeoff you will have to deal with if you have a lot of objects. At most, you will be waiting for about 30 minutes for a decent sized level to build clean lightmaps without compression, but the size of the lightmaps will balloon out of control...

Here are some comparison shots:

Uncompressed (notice the size). I am not worried about the file size since I am just testing out the lightmaps. Also in this shot, there are no lights present.

Compressed:
Same number of lightmaps, smaller file size. (YAY!) I would rather have a bunch of lightmaps compressed and not take up build times than lightmaps that are super sized and increase the size of my build.

 

Thanks Neptune, but I think this is getting a bit off topic.

Could someone from Unity comment on whether the disparity in speed and quality between Beast and Enlighten is a known issue?

Thanks

 

Unity is looking for case studies where you can demonstrate it, via bug report so if you can make a repro clearly demonstrating it, they should have more to work with.

 

I can't comment on the speed of light mapping, because it has never completed for me. the Longest I've waited though on a small terrain is 48 hours.

 

48hrs... was it one whole terrain or split into pieces?

 

I've submitted three bugs related to lightmapping that have all included those comparison scenes (658437, 657569 and 657558) but none of them specifically mention the speed and quality problem so I'll submit one for that too in the next couple of days.

 

More indirect bounces with enlighten? Does Enlighten have bounces control?

 

Yes... in the lighting panel, under "General GI", there are two sliders called Indirect Intensity, which controls how strong the indirect lighting is on the initial bake, and bounce boost which serves as a multiplier. It is best to leave continuous baking checked if you want to tweak these settings. It is a lot like beast... but easier.

 

I believe those settings are more like the old Bounce Boost and Bounce Intensity that Beast had. Beast on top of that had a number of Bounces control (0 to 4), which is what I thought you were referring to with your original post. Enlighten I believe is missing similar functionality.

 

The issue isn't really quality - you can max that out, the issue is same quality with ballpark similar rendering times, and maybe enlighten is at the limit there and other ideas such as compute shaders can help calculate the enlighten workload for the precalc phase.

 

Indirect Intensity and Bounce Intensity are the same.

And @hippocoder is right about possibly Enlighten reaching its limit when it comes to the trade off for rendering time... it is a caveat that we will have to deal with unless you cleverly place your geo

 

Well the main thing is your times are related to your lightmap parameters setting, so you probably just should set everything to super low, then tentatively raise it where it's needed. Things like Beast, classic lightmappers will always be faster than enlighten because they don't actually need to be anything except a fast raytracer. Enlighten has to do a lot more to prepare for realtime GI.

 

The problem is, that it prepares a lot for realtime GI even if what you want is a static baked lightmap. I understand that the realtime stuff is much more complicated (and frankly, when I manage to get good results, it looks amazing), but if we view it as a static lightmapping only solution, it's inferior to Beast, at least right now.

 

I agree. I wasn't defending, but observing.

 

I don't like the fact that no one from the unity team has said anything about this yet.

 

I hope to do an in depth tutorial on this when it is out of beta. I've noticed that the baked light maps come out darker then when I set it to real time... :/ Kinda weird to me. I need to investigate that. To counter this, I end up baking GI brighter to combat this. I hope this is fixed, because it is weird... I would love if they added a mixed mode for emissions. So I can have realtime for my skinned meshes and static for everything else.

 

Do you use a lot of luminous geometry? I think those look a lot different between baked and realtime.

 

Kuba said in another thread:

No timeframe, but they are aware that we care about things like that.

 

I intend to, especially when I want the lighting in my game to be as natural as humanly possible. Cornell boxes using luminous polygons, it is a nice way to fake area lights.

I am not too fond of the point lights in Unity atm (lack of physically accurate falloff and the ugly shadows) but this is coming along. I've already submitted my Cornell box scene to Unity to look at it. I will use point lights ONLY where needed.

And yes, I do want final gather in the final build because it will match the real time luminous geometry (which I will use frequently) bakes, which also work VERY well with reflection probes.

 

I found the culprit... I have AO turned all the way up to one, and that is darkening my lightmaps... I usually don't use AO for GI and use it per material. If you completely disable AO on the lightmap, the realtime and baked emission will look the same

 

Ok I've submitted a bug with the comparison scenes (659512).

I suspect you're right, the problem here is really just speed. If I could render at HighQuality then the lightmaps might look ok. I can't though because the bake time would be prohibitively long and it currently crashes for me after about an hour anyway (658437).

It's good to see Unity are working on implementing final gather but it's not clear from that comment that it's a solution to the speed problem. If it completely removes the need for the precompute stage (with realtime GI off) then I'm sure it will be.

 

Please help
I get +999 errors all of them says

kSuccess == m_Result
Integrate failed on Light Transport job.

What can I do to solve that?
I can't bake my lightmap

 

Up

 

I had that too (although not in the last beta).

I don't know what I did to make it go away.

It generally happened with projects I upgraded from 4.x though.

 

Thanks!

Final gather still needs some intermediate GI data to gather from, but that can be at much lower resolution than what you'd need now. So precompute will still be necessary, but can be much quicker.

That said, PowerVR Ray Tracing is the solution to getting baked lightmaps quickly and also getting previews for realtime GI when the precompute is running. Once 5.0 is shipped, some of us will get back to working on that full steam.

 

Please make sure that you're using the latest beta and if it still reproduces -- please submit a bug report with a repro project.

 

The weird discoloration is not expected, especially that you're not using compression. Please submit a bug report that shows the issue.

 

Please submit a repro project.

 

This discoloration is not expected, we'll take a look in the bug you submitted.

We didn't change the way non-directional lightmaps are encoded, but were playing around with the color space in which data is stored in the lightmap, so that it can work when the color space is changed at runtime (e.g. falls back from linear to gamma on old hardware). I suspect some of those changes could affect it as I doubt this is in the floating point data that we get from Enlighten.

The grid pattern is visible in the shot above, we'll take a look.

 

I did (case 658208) - and received a response that it was a known duplicate bug.

 

Good morning. From the tests I have been doing with Enlighten (I feel like I've mastered it), here is what I've found:

-- a baked resolution of 128 is reasonable for a small room like a cornell box with compression enabled. Realtime set to 8 is good for luminous objects.

-- for final bakes, I usually crank the baked res up to 1024 (with FG once it's added, with an atlas size of 2048. Depends on the scene, may need to be methodically split to save uv space.)

-- Reflection Probes need an exposure and a compression toggle in the options. Exposure is good for hotspots such as sunlight.

--HDR probes need to be in Truecolor!! I had to set this after a capture.

Will indirect point light shadows be enabled in the final version?

 

Thanks for the update Kuba.

I'm already at VeryLowResolution so would final gather mean I could set that even lower?

Also, if this is not ready by the next beta release is it possible to reinstate legacy mode (Beast) until it's fixed?

 

Yes, those are just presets, you can make your own that suit your scene.
Remember that there is no such thing as a universally correct resolution. It depends on the scale of the scene, the required amount of detail in the result and the amount of time you're willing to wait for it.

No, sorry, Beast will not be brought back.

 

I'm liking the new delay Enlighten has. And the lightmap parameters are good too. Could I have them for sections of my level? such as one part of a room. This would be a good way to to avoid running out of space in the atlas.

Will FG be in the next build? And monte Carlo.

 

Not sure what you mean here.

They can be assigned on a per object basis. Go to the Lighting window, Object tab and change Advanced Parameters to whatever you please.

Definitely not in the next one, but next-next is not unlikely.