Lightmapping is much slower and looks worse.

Turning off Precomputed Realtime GI for the bake doesn't provide this for you?

 

Which build do you mean? Release Candidate 2?

 

even if you're on a mac, and you have terrain? Is that coming in RC2?

 

Ok I finally got round to testing lightmapping in RC2 and quality seems to be much worse. That's with the same settings as before.

In an attempt to improve quality I increased some of the quality settings, but the best results I've had so far are still much worse than before. To top it off, the bake time is now longer too. Here are some updated comparison screenshots...



As you can see, all the problems mentioned in the original post are still there (blotchy, multi-coloured artefacts and the grid pattern artefacts) and it took 32 minutes to complete, compared to 5 minutes with Beast. The contribution of the skylight (ambient light) seems to have changed too. The overall colour is much less blue now.

So my question to Unity is...
How do I get parity with Beast in terms of quality and speed?

 

Do you have compression enabled? Also how many indirect bounces are you using in your lightmap settings? You could also increase the bounce intensity on the Directional Sunlight.

Also if you have AO enabled in your lightmap settings, disable this, because it will darken your lightmap. Reserve AO for your textures. And what is the resolution of the terrain and how many rays are you firing?

 

Compression is enabled in both comparison shots. The Beast lightmaps look fine.

There is no 'Indirect Bounces' parameter. There is 'Indirect Intensity' or 'Bounce Boost', neither of which control the number of bounces.

The point of mentioning the reduced ambient light contribution was not to find a 'fix' but to question why it changed.

I want AO in my lightmaps. The Beast screenshots have AO and it looks good. In fact, AO is another thing that Enlighten doesn't do very well (look around the base of the cube in the third shot).

Terrain size is 280m by 380m (and is an imported fbx file, not Unity terrain).

I'm using 256 final gather rays, but I've tried 1024 with no visible improvement. This is with Default-HighResolution setting too.

 

Can you show a screenshot without compression enabled?

 

@Jde do you think you can share this asset so I can test it? You only get those splotches wih compression enabled... and in my case about disabling AO, I usually do that because I am using a shader that supports two UV channels and I store an AO map in UV2

 

What you're seeing around the base of that cube isn't entirely AO. It's a lightmapping issue with intersecting objects.

At the intersection, one texel is lit, then the next texel in complete shadow. The 'very-strong-AO-like' appearance is primarily the bilinear filtering between those two samples - especially on the terrain, which appears to have a lower lightmap resolution.

Not sure why this effect is reduced with Enlighten, but that's probably a good thing.

It does look like there's some actual AO on the cube face, though. And I'll agree, the Enlighten system doesn't seem to bake AO very well - I did a quick test in a simple scene - a few cubes on a plane - and the AO parameters seemed to have virtually no effect at all.

In my test scene, I'm not getting the blotchy look though - that looks like texture compression to me - are you in Android or iOS mode? - mobile texture compression is fairly terrible, and much more lossy than DXTC compression on PC.

 

+1 on the fact that AO baking seems very weak in 5 regardless of contrast or distance settings.

 

Hi guys. I thought I'd just tell you some experiences I've had while trying to update a game (Dungeon Crawlers HD) to Unity 5, in regard to lighting. Just to cement what's already been said.
I'm not trying to get new stuff to work just replicate the version of the game from 4.6.

1. AO doesn't work.
2. Nowhere to set light bounces.
3. No light bouncing for Spot and Point.
4. Spot and Point had the incorrect intensities, when the project was opened in Unity 5 (up to 16 in some cases when the limit should be 8).
5. Area lights have a range of about 1 unit so are effectively useless.

I've tested all of these in a fresh project with unity primitives as well.
I'm using Spot lights with a wide cone for the room blue fill light, instead of Area.
The attached image shows how close I've managed to get thus far, on a test level. Basically the dark corners that make it look solid and take the eye away from the polygons are missing. This is because of the lack of any bounce on the lights and AO I reckon.
Realtime GI will be great for the next project though (trying to add something positive).

 

Regarding texture compression, it's true that most of the blotchy, coloured artefacts appear when using compression (I'm on iOS platform so it's PVRTC) but that doesn't answer the question as to why it's so much worse than with Beast. The Beast lightmaps are compressed too (if you look closely at the shadow of the tree you can see the trademark green and purple compression artefacts). Maybe it's not Enlighten itself causing the artefacts, but there's something in the new lightmapping pipeline that causes them, or makes it more likely to happen at least.

So a more specific question for Unity is... Are the lightmaps now compressed or processed in a way that encourages these artefacts?

You're right that what the Beast shot shows is pixel blending from black to a lighter colour. That's only for the first pixel in front of the cube though. The area past that (the second, third and fourth pixels) is still affected by AO and displays a nice softened falloff.

I have to disagree with you there. That effect, while it might be undesirable in some cases, is predictable and 'correct' in terms of the concept of ambient occlusion. The fact that it's not present with Enlighten is a sign of something broken.

So, then, another question for Unity... Is AO broken?

 

How can 1 be too low? A value of 1 should be full AO and a value of 0 should be no AO. If it doesn't look right when using a value of 1 then AO is broken, not the slider.

 

If you look at those comparison shots, it's pretty clear that in beast, the AO is applied to the direct light as well as the indirect.

So for beast would have been something like:

ao = Pow(ao, aoExponent);
final = (direct * vDirScale * ao) + (vIndirScale * indirect * ao);

I understand that it's kinda "wrong" for AO to be applied to direct light, but then the entire idea of AO is a fudge anyway, and in many visual styles it can really help readability to have AO in the direct light portions. At the very least it makes sense to offer it as an option just to get parity with Beast.

As for the atrocious overall quality... What can I say, those comparison shots speak for themselves

 

Great. I am not too interested in PBR, none of my projects so far has focused on any kind of 'realistic' look.

 

That's cool. Ideally, I would like two sliders, one for the direct light AO, and one for overall AO, or something, so I can have like half AO in direct light and full in the shadows etc.

 

a "Direct light contribution" for baked AO, that could be usefull

 

Was that meant to be "we definitely have to fix that." or "we definitely have fixed that." ?

 

I believe that's iOS compression. I've tested it and got that rainbow effect with compressed lightmaps.

 

I'm on iOS platform. Good to know that it's a bug. I'll keep an eye out for the fix.

Now that the quality question is answered (if not yet resolved), what's the situation with the speed? Are we ever going to get parity with Beast in terms of speed?

I have a feeling the 'real' solution to this will be the PowerVR Raytracing implementation. It's hard to imagine Enlighten getting anywhere near the speed of Beast given where it is now and the fact that we're on a third release candidate.

 

I love seeing posts like this.

 

Well not yet resolved, the promise of a resolution, but that's still a good thing.

Maybe there are certain scene configurations that are less suited to Enlighten then, because the fastest I've been able to bake that test scene, using the lowest possible settings in RC3, is 12 minutes. Which is more than double the Beast time of 5 minutes. The settings to get to 12 minutes were...

Indirect Resolution - 0.001
Final Gather - Off
Default Parameters - Default-VeryLowResolution

If there's something I can do to improve the bake speed I'd love to know.