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.
Check task manager during bake about RAM usage .System crash was related to memory in my tests
Thanks will check it out. I will have to load that up before I start the bake. Once it gets baking, the task manager will no longer open. Can't even move the mouse.
I use a powerful server machine with 16 cores and 56GB RAM to bake Progressive Lightmapper but it always crashes due to out of memory.
You should check your task manager to make sure about memory limitation during bake.
It's depend on scene scale and object counts
@aliyeredon2 Check my second pic. It's more than 50GB RAM!
So your problem is wrong settings.
Send me screenshot from your scene if it possible.
Also always use 1024 as lightmap size
1.Needs 2x or 3x more memory
2.we don't need too high resolution for all objects. Also bake time will be increased 2-3x and will be multiplied into Sample counts (i'm not sure)
It's only useful when you want to bake with ultra high resolution lightmap with a titan pc in a long time .
But in 1024 you can use Spot lights to simulate high quality indirect shadows and reduce noise quickly. Bake in 30 min instead of 30 hours without noticeable difference in quality
You can simply increase floor lightmap scale instead of whole scene resolution
Maybe this was my issue as well. I bumped up the texture to 2048x2048 in hopes I would bake less maps.
@LeGiangAnh - Oh my freaking god. That's a beast machine with 16 cores and 56GB RAM. If this is occurring for you, it will most definitely occur for me. So can anyone chime in on optimal Progressive Lightmapper settings to prevent memory errors? Maybe good charting settings. I still haven't figured out how to move certain UV shells onto charts to pack them better (other than doing it myself in 3ds Max). Maybe a screenshot of some good settings that will not cause out of memory crashes?
Always use a low resolution in lighting window.for example 3-10. Then increase lightmap scale for important objects. for example use 1 for terrain.
That's for Enlighten. As you can see in my setting (super strong PC), I use only 4 for Light Map Resolution) and reduce much the default setting of Progressive Lightmapper)
Only resolution needs Memory. Others will just increase bake time and reduce noise.
So your problem should be high density objects or large terrain or lots of trees .if you switching to 1024 lightmap size, you can bake with half of the memory usage
I don't see how a 2048 map requires more memory than 4x1024 maps.
I don't think the lightmap size value is very important. Leaving it to 1024 or 2048 is just fine for most cases.
If you're running out of ram, lower the resolution by a lot.
The last pick, has 4096 picked, but below it says 14x1024 maps.
And the occupied texels jumps from 8.2 to 13.2m it's in no way a fair comparison.
Yes. That was a beginner level comparison when we want to use 2048 lightmap size
Randomly playing around with stuff. Mixture of PLM Baked, some(?) Realtime and SSR, supersampling, etc.
How about the file size. It seems that increasing the resolution will increase the size of the lightmaps?
I'm not sure if there was a mention but since 2017.1 light cookies have been supported in progressive lightmapper when a light is in Mixed mode.
my example -https://youtu.be/V789z_wBZzw
I'm having an issue with the progressive lightmapper in 5.6.2, including the latest patch 5.6.2p4.
It seems that when I have a lot of baked lights in the scene, the lightmapper just ignores a high bunch of them at random. Sometimes ignores some lights, and sometimes ignore some other lights. In the attached screenshot, all lights are supposed to be enabled. I have not tried Enlighten because it just takes forever even with one light, that's why I'm using Progressive in the first place.
Is it a known bug or something?
Enlighten in lowest quality is a lot faster than PLM :
First you need to bake using very-low settings to see result and then you can increase resolution
My bake time was 20-30 min using PLM but is now 3-4 min using Enlighten on same scene. We needs PLM to see lighting feedback before finish and better indirect lights or shadows
Also don't forget that Enlighten is much faster after first baking, because its baking algorithm is same as its realtime GI and only re bake it on the texture
Hi! Thanks for your answer.
I've tried with the very low resolution as you said, and in my case it was slower than with PLM, but it was still an acceptable time. And all the lights work correctly.
So I can confirm that ignoring random lights only happens with Progressive lightmapper, so at least this serves as a bug report.
I guess I'll use PLM for quick testing and Enlighten for the final render given the circumstances.
Light skipping is a knows issue
Oh, I see, thanks! Hopefully it gets solved soon.
I'm testing indoor stuff and had a lot of emmisive lights in one room being skipped, turns out I'd let unity create the UV layout for lightmapping on that mesh and it was completely throwing the PLM, Enlighten baked the scene fine with all faces accounted for and mapped, but a lot slower.
Creating my own second UV layout fixed the issue with PLM, only takes a few mins to create a lightmap UV layout so might be worth a try if using Unity generated maps.
I sadly didn't think to save the "broken" mesh before adding new UV's, but was no overlaps, all quads, fair padding, no doubles.
Although I suggested enabling `Generate Lightmap UVs` option, it won't magically solve all the problems. Padding between UV charts (islands) need to be at least 2 full texels apart. Otherwise you'll continue to see light bleeding. You can use Object Maps tab under the Lighting window and select baked intensity to see the layout of your UV. You can also use baked lightmap visualization mode.
@jennifern has a talk about baking lightmaps in Unity here, you can refer to that video to learn more about essential lightmapping concepts:
Previously, I also replied here about this issue: https://forum.unity3d.com/threads/strange-bake-artifact-5-5-3.467559/#post-3071791
We're aware about memory issues and the team is working hard on addressing that. But until then, I'd suggest using low resolution values as you already realized. I'd personally consider Lightmap Resolution in Lighting tab as a global setting and adjust `Scale In Lightmap` parameter in Mesh Renderer component as a local value to adjust the resolution for small objects (as @aliyeredon2 already said - thanks!). Also, it's worth noting that you should ideally use light probes for illuminating small objects (e.g. plants) with light probes instead of marking all your objects lightmap static. Right now, you can also end up with more lightmap counts compared to Enlighten because of order of instances but very soon atlas packing of lightmaps will also be optimized.
One more tip is to use Anti-aliasing samples in custom lightmap parameters for supersampling, which can reduce aliasing on the lightmap of objects that are obvious (attaching an image to show where it's located)
We've the issuetracker for this bug here: https://issuetracker.unity3d.com/issues/progressive-lightmapper-ignoring-lights-in-a-larger-scene
Thanks everyone for your input and feedback, we highly appreciate it
Really? Awesome. What kind of optimizations are coming?
Progressive lightmapper can unnecessarily split charts into different lightmaps at the moment, thus generating more lightmaps than it is supposed to. That's related to instance ordering and less lightmaps will be generated once this issue is addressed so it will be on par with Enlighten.
That's, a bit underwhelming, especially since I find the packing that happens under Enlighten to be rather poor as well.
I was hoping for the packing algorithm to use tight packing (instead of bounding box, as it does now) and also to be able to rotate UVs by 90 degrees to make them fit better. And maybe improvements to the placement in general (maybe make it iterate between a few and choose the best one?).
As it is right now, I find it really hard to make a lightmap have more than 0.6m occupied texels per 1024 map, which is lower than I'd like.
So PLM is till not usable outside of bake indirect?
My game is mostly outside, and from the manual it says dont bother with PLM due to lack of shadows.
I imported a scene from 5.5 that had 176K tris, into 2017.1 and it now has 476K tris, and when I use PLM the tris go up to over a million. There has been absolutely no changes to the scene, or camera position. Why is that?
Try lower quality settings from Edit->project->Quality.
If the tri count is reduced after this, so your problem is from dynamic lights with shadows
I will try that, but the only dynamic light in the scene is the directional light which is set on mixed, with just about all the meshes set on lightmap static.
And this issue affected all my scenes
Can you check if the issue still persists when you bake the lights? I think the issue you're encountering is related to the state of lights and as far as I understand you're switching between backends (i.e. Enlighten and PLM). If this is the case, then some baked lights can still fall back to realtime because they're not "baked" yet, as in lightmaps are not generated. Thus, the triangle count can increase, which is expected. But it would be nice to check it and share your result with us.
It seems there is an issue with direct samples. Baked lights are noisy, no matter the amount of direct rays but not if I start the bake with prioritize view. It's happening in 2017.1p1 and p2. Didn't check other versions.
It's case 936693
Thank you for raising this issue but currently, this is by design. You've probably noticed it already, but regardless of `prioritize view` option, the end result is the same. Now, the main reason why it looks different when you first start is due to "texel" prioritization on lightmaps. Basically, when `Prioritize View` option is enabled, no rays are shot beyond the camera frustrum, therefore baking process gets faster as a small portion of lightmap is being processed. So essentially, all the lightmaps go through the same process but when "Prioritize View" is enabled, it gets faster for the area that camera frustrum covers. Convergence and compositions steps render the same result though. I hope this answers your question.
No it doesn't. It answers a different question, I didn't even make a question.
The problem is that the end result is not the same.
(which I thought was clear if you read the bug report)
Well, now that is strange because I initially didn't run into this issue (I thought you were referring to initial stage of baking when you said "starting with prioritize view") and this is what I first got with and without "Prioritize View":
Later, I managed to reproduce the bug but I don't think it's related to View Prioritization. Presumably, it's related to supersampling. I'm continuing to narrow it down but can you perhaps assign a custom lightmap parameter and set anti-aliasing samples to 1 and see if that gives a consistent output?
You need to move the scene view a bit right after you clear and start bake with Prioritize View on, since prioritize view sometimes doesn't kick in if you don't move scene view a bit.
Setting anti-aliasing to 1 fixes it (it makes both "methods" clean), but then I have no antialiasing
For every other anti-aliasing setting : starting with prioritize view makes it clean, otherwise it looks like not enough direct samples.
Maybe under certain circumstances, prioritize view ignores the antialiasing setting and makes it default to 1?
That's because of editor updates most likely. Instead of moving the camera, hovering the mouse over the screen should also re-paint, it simply needs to be poked
No doubt that it's a bug, I was only trying to narrow it down. Thanks for the help.
Minor correction, AA = 2 looks clean as well. So it seems to start from AA >= 4.
Yes, that parameter is related to G-Buffer and it could sometimes be ignoring it.
Values ranging from 1 to 3 are actually the same 3 rounds to 4 but 2 doesn't round to 1. We should probably fix that as well.
the increased tris started the moment I updated to 2017.1, and baked with enlighten, all scenes seemed to have between 2-3 times more tris. I did not try PLM until later, and that when the tris jumped to crazy town.
I am having the level designer checking to see if something changed that should not have, during the update.
Hey, I have some weird spots on my Objects while mapping with the progressive Lightmapper and they appear to be emissive or very bright. Any Idea why?:
Here is the same scene angele with enlighten:
Okay, seems to happen only with higher resolutions ...
By higher resolution, do you mean setting lightmap size to 4096? And do you have the same behaviour when you manually generate the lighting?
Any updates about this one? Is the issue still persisting for you? If so, would be nice to get a reproducible project. Thanks
its what I hoped. when we updated to 2017.1, the LOD in quality settings defaulted to 2 instead of 1 like we had it.
So I put it back to 1 and the tris decreased to the normal level
by higher resolution I mean the Lightmap resolution. I think the odd behaviour started over 50 texels per unit. What do you mean by manually generating Lighting? Directly baking the the affected object maps on the object map tap in lighting?