A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Global Illumination' started by Kuba, Feb 2, 2017.
haha, of course..Im still stuck in 'enlighten' bake mode
Nice one, thx
Little heads up:
New demo teaser making good use of Progressive Lightmapper and the new 18.1 custom bake feature.
That grass(!!!) This is outstanding work, truly breathtaking. Please can we get a breakdown of this project from someone, at least the artists names?
I'm guessing it's from the internal team led by Veselin Efremov, right? It looks like it. (please don't give spinoffs to Oats this time )
Some more detail here: https://unity3d.com/book-of-the-dead
The breakdown will be made public at GDC in March so a little wait.
Yeah. Although, some of it was scanned in-house and delit with the Unity delighting tool from the Labs team.
@Jesper-Mortensen It looks fantastic. What was PLM eventually used for, baked shadows? It's just I see the light update so I assume it's a mixed mode lighting. How long did a typical PLM resolve in?
I really can not imagine a Lightmapping to be used in such scenario !
Was it actually !?
I guess it is only custom shaders and post processing may be !?
P.S. or it is not a real time at all !?
P.S. sorry, i missed the post where is says it shows a good use of the Progressive Lightmapper - so Congrats - it's looking so realistic !!!
But is this actually a real time footage or it is pre-baked into a video !?
I'm ignorant as to what this is
I really doubt this is a real time or the actual 3D area is too wide ! I wonder as well how is this achieved and what the "custom bake feature" is !
I'm guessing it's this (from the beta release notes)
(I have no idea how to use it though)
Right yeah, I think I'll be having a scoop of that on my plate.
You nailed it. It lets you precompute sky occlusion values in a dense grid that can be used to occlude realtime sky lighting for the trees and foliage. The direct lighting is computed in realtime and bounced lighting is baked down.
I would like to share my concerns about the Progressive Lightmapper's shadowmasks, too. Something is going wrong somewhere in the baking process, and it's breaking things like soft shadows and the baked shadow radius setting.
Here's a comparison between Enlighten and Progressive, both using default settings:
I hope a fix can be provided soon. I understand it's a preview feature and work still needs to be done on it, but the Progressive Lightmapper is already far superior to Enlighten's baking solution, and this shadowmask problem is the final barrier to overcome before we can use it in our projects.
EDIT: Whoops! I tested the project in 2018.1 beta2 and Progressive Lightmapper shadowmakss work flawlessly! Thank you for your hard work. I hope this can be backported to Unity 2017.3 soon.
We fixed some of this stuff when we added lightmodes in 2017.3. Can you try and spin up your level in 2017.3 and see if the same happens? If it does we could use a small reproduceable.
Yes, this is something I've been working on recently in 2018.2+ the emission and albedo texture resolution will be decoupled from the lightmap resolution and it will be possible to have low or no lightmap on the emitter and still a high res emission texture.
I also means that if you have loads of instances using the same material it can share the texture, saving memory while baking.
We are working on fixing in 2017.3 too. @Kuba is looking into it.
I'm not sure why but I dont get this error anymore.
Sorry, not really helping here but I'm glad the error is gone
Thank you for reporting this. I have been able to reproduce this issue. As you point out it seem to only happen with very low resolutions. I will examine it further and (hopefully) come up with a fix for it.
My pleasure I love the progressive lightmapper so far, so the quicker issues get solved, the better Are you also addressing the bugged seams in the new unwrapper version (some seams are created on smooth areas with low angles)?
We are using 2017.3.0p2 and Progressive Lightmapper with shadowmasks.
We baked light and got that shadowmask.
Where can these strange red lines in shadowmask of terrains come from?
any ETA??? since the last time you said that 5.6.5 has been released and 5.6.5p1 too but none of these versions support Mixed Lighting Mode with PLM
Could be invalid texels maybe, can you check the texel validity scene view visualization?
so how's the GPU support coming along?
Hi, a quick question, is it possible to play around with the sky occlusion experimental API !
If it eventually available in v2018.1 b5 !?
i think @robert was planning to create a sample repo for that one
May be i I will find solution here. I want use mixed lighting - precomputed GI and Progressive lightmapper.
If i bake only precomputed GI, my dynamic objects recived color from light probes:
But if i bake precomputed GI with PLM i have bug: after first play - light probes gives color, after next - only grayscale.
This is first enter to play mode:
And second enter to play mode without rebake or any changes:
Screen with very low resolution for reduced time bake, but with high value - nothing changes.
I am reproduced this in 5.6, 2017.2, 2017.3.
Why after second and other play, indirect color from lightprobes disapears?
It is only using PLM, with Enlighten all ok.
Unity 2017.3.1 Mixed Lighting, Progressive Lightmapper with Lighting Mode Shadowmask still ugly, not accurate and jagged.
Is it possible to edit the shadowmask file outside Unity and reuse it ?
any news of that sky occlusion repo?
you can open the image in photoshop or gimp and resave. (in photoshop you need to use 'layer mask > from transparency) for the image to show up.
So can someone confirm the jagged shadows are still an issue? Also the filtering seems pretty bad, as you can see in the images, it basically wipes out the shadow lines..it feels like the lowest setting of 1, isnt small enough for lower resolution bakes.
The first image shows the nasty jagged lines without any filtering, and the second with lowest filter setting. ( i can get a nicer result passing a non filtered image through photoshop)
Also i have noticed that as the progressive map iterates, you can see the shadow line appearing, but it disappears in the second pass, as though the samples are being deleted due to some hidden noise threshold or something. (see next images)
This is unity 2017.3.0p4, win 10 on a real beefy xeon machine.
I've been working with the Progressive Lightmapper, but I've noticed something in the 2018.1.0b4 beta that I can't quite figure out. Unlike in previous versions of Unity, when I bake my lightmaps using the PLM, I get an additional piece of information in the "debug" area related to "Memory Usage":
(scroll down to the bottom of the pic)
How am I to interpret this? Is the lightmap data taking up 2.0MB or 210 MB? Or is it only taking up that amount of memory when it's calculating the lightmaps? What are some strategies for reducing this, or should I even concern myself with it? Is this related to this issue?
thanks for your guidance on this~!
Is the issue of "Progressive lightmapper supports a maximum of 10000 instances" is fixed in new beta?
Yes it was lifted in 2018.1 (open beta is available).
I know you already got your response but just for ambient awareness, I'll also state it here. Memory usage part displays the amount of RAM used by Progressive Lightmapper and the section where it says 2.0 MB is the size of your lightmaps. So by looking at memory usage, you can estimate how much memory you need for baking your scene. This is useful because the amount of memory used in Task Manager is usually incorrect and misleads the usage of Unity while baking. Our developers injected custom memory labels to correctly track the usage of lightmapper.
Have you tried creating a custom lightmap parameter and using supersampling? (Anti aliasing parameter) If not, maybe you can try increasing that value and see if it helps.
Also I must admit - you're using really low values. Direct samples of 1, indirect samples of 50 and lightmap resolution of 10? I don't know the scale units of your objects but with default Unity primitives, those settings would only render a draft quality. I recommend using at least 16 direct samples, 64 indirect samples and maybe a resolution of 20-24 to achieve a decent quality with your shadows.
Hey @Vagabond and @hippocoder
As Jesper said, details will be shared during GDC, but until then I can spoil some settings they used.
They have one mixed directional light in the scene and they're using `Baked Indirect` mode. So only indirect illumination is baked into lightmaps and light probes. Direct lighting is realtime, that's why they can rotate the sun and can still pull it off. They can afford that since they've an open environment so bounce lighting is not a vital part of their lighting setup.
If I'm not wrong (could still be PCF), they used moment shadow maps that Robert shared in one of his tweets before: https://twitter.com/robertcupisz/status/831968917778227203 And this shadow type is already available in 2018.1 HDRenderPipeline but it's not exposed to users in a artist friendly way yet. It'll be though, before the final release. 2018.1 is still in beta cycle.
And yeah, as you know occlusion probes also play a crucial role for their setup. By default, trees painted on terrain only use single light probe for being lit. This renders a flat shading on tree asset. Occlusion probes that come with custom bake allows more granularity. We should show how that can be used indeed, and I think we'll do that very soon so stay tuned.
Can you share the reproducible project with us please? I'd like to investigate this one a bit more to help you. You can either report it through BugReporter and share the case ID here or send a DM to me with the project.
It would actually be nice to get a solid reproducible project for this issue. We also see it here and there but can't reliably reproduce and the behaviour doesn't seem consistent.
To answer your question, you can safely ignore these errors as long as it doesn't affect your baking process
Hi thanks, will stay tuned for this... !
However may i suggest something which will be very useful in PLM. Can we have some control over threads used by PLM or priority etc. because it is somehow hard to navigate through scene when it bakes ( when doing a lot of test baking you decide to copy or move some objects while PLM is working ). if we can have at least one thread available in for editor it would be great because it gets unresponsive very often !
This is just an idea and you may have a better idea on how to free up some resources for flying around or do some edit while baking !
Well going forward we think focusing our resources on GPU Lightmapper makes more sense. When baking is done on GPU, CPU will be free/available to do everything you mentioned. Nevertheless, point taken. Thanks for your input
Sure GPU lightmapper is the most anticipated thing here. However some users will have to rely on the CPU baker because of the current hardware they use being not high end - like in my case !
Thanks again !
Hi, thanks for reply. Yeah the scene is pretty huge, basically the ground is around 220units big...and I'm constricted to a 4k map so for my scene anymore than 10 and it wont fit....I've just been told that the issue is a bug in this Unity 2017.3, however Unity 2018.1.0b8 has had a fix or improvement. I am increasing the samples to around 200 for final bake, however I dont know if im expected to push it higher for such a large surface, as the render times get silly if i do.
Also the direct samples is only needed if you are using soft shadows and baked shadow angle, apparently..i dont know if thats in the docs, but would be good if it was.
I'm playing with the experimental api stuff in beta 9 and I'm trying to see what I can do. I'm enjoying the amount of control. But.
Is .innerConeAngle supposed to work? (on spots, obviously)
I'm successfully setting up the delegate and I'm able to change around other stuff (the normal cone, switching falloff types, setting a different indirect color, etc), but innerConeAngle changes absolutely nothing it seems.
Inner cone angle only exists for Enlighten, that's not used by Progressive Lightmapper so it won't work. And for ambient awareness, let's also share an example code with others Following code demonstrates how you can change direct and indirect lighting color, intensity value and falloff for baked lights via API.
public class ExtractFalloff : MonoBehaviour
public void OnEnable()
Lightmapping.RequestLightsDelegate testDel = (Light requests, Unity.Collections.NativeArray<LightDataGI> lightsOutput) =>
UnityEngine.Color aColor = new Vector4(1F, 0, 0, 1);
float aFloat = 3.0f;
DirectionalLight dLight = new DirectionalLight();
PointLight point = new PointLight();
SpotLight spot = new SpotLight();
RectangleLight rect = new RectangleLight();
LightDataGI ld = new LightDataGI();
for (int i = 0; i < requests.Length; i++)
Light l = requests[i];
case UnityEngine.LightType.Directional: LightmapperUtils.Extract(l, ref dLight); ld.Init(ref dLight); break;
case UnityEngine.LightType.Point: LightmapperUtils.Extract(l, ref point); ld.Init(ref point); break;
case UnityEngine.LightType.Spot: LightmapperUtils.Extract(l, ref spot); ld.Init(ref spot); break;
case UnityEngine.LightType.Area: LightmapperUtils.Extract(l, ref rect); ld.Init(ref rect); break;
default: ld.InitNoBake(l.GetInstanceID()); break;
ld.color = ld.indirectColor = UnityEngine.Experimental.GlobalIllumination.LinearColor.Convert(aColor, aFloat);
ld.falloff = FalloffType.InverseSquared;
lightsOutput[i] = ld;
So I'm having this issue with no idea on how to fix it properly.
Baking my lighting with the Progressive Lightmapper produces these weird dark squares. The strange part is, the more that the lightmapper does it's thing, the more the "artifacts" become visible:
These are the settings used for this bake (with one mixed directional light):
Increasing the resolution to something like 100 makes the squares smaller, but does not eliminate them. Same thing with samples, bumping them up to 60 direct / 1000 indirect / 4 bounces doesn't help.
During the bake, the dark parts sometimes disappear and reappear, but they are always present in the end. The ground is a custom circular mesh about 30 units across (the area visible in the screenshots is around 7-10 units).
The resolution also seems fine:
Switching to Enlighten however, makes the artifacts go away.
Can someone provide a technical explanation for why the curvature of normal maps is destroyed for baked lighting but not realtime lighting?
Start a new bake and switch the scene view to the Texel Validity view. Is it full of red? If it is, create new lightmap parameters, and switch the backface tolerance value to 0 and see if that fixes things.