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.
Now in Beta! Get 1:1 live lessons on any Unity topic or help troubleshooting your project – Connect with an expert on Unity Live Help
Discussion in 'Global Illumination' started by Kuba, Feb 2, 2017.
Thank you for the updates, much appreciated.
Hi, I suspect you are getting a lot of invalid lightmap texels because the terrain lightmap texels are seeing many backfaces from the trees. There are a few things we can try to isolate the issue:
- What is the backface tolerance value set for the lightmap parameters for the terrain? What happens if you use a higher tolerance value?
- Have a look at the texel validity scene visualization mode? is the area with the wrong shadowing marked as invalid during baking?
- Does using double sided GI for the tree foliage make a difference?
- Can you please provide a screendump of the generated shadow mask texture?
(you mean lower, right?)
Looks like a biasing issued when using realtime direct lighting. Have you tried tweaking the bias on the directional light?
Would be interesting to know if this is in the lightmap or the realtime direct. You should be able to determine that by using the baked lightmap visualization in the scene view.
We have an issue with a serial stage that depends on the lightmap size, we have optimized this significantly in 18.3 and we are backporting this fix to earlier versions ATM.
We know about this and have a fix in 18.3 that we are going to backport to earlier versions asap. Once that happens you should be back to ~100% CPU utilization.
We have recently been looking into the packing step. We are adding spatially coherent packing and also an ability to force a group of objects into a single atlas. We will look into your request too while we are doing this. It makes sense to be able to do your own packing and maintain that for baking.
could someone give (or make) some practical example of how to use configurable falloff in the Progressive Lightmapper.
In order for the custom light falloff to work, you would first need to create a script named ExtractFalloff which contains the following code:
public class ExtractFalloff : MonoBehaviour
public void OnEnable()
Lightmapping.RequestLightsDelegate testDel = (Light requests, Unity.Collections.NativeArray<LightDataGI> lightsOutput) =>
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.falloff = FalloffType.InverseSquared;
lightsOutput[i] = ld;
The code example above already has Inverse Squared falloff set by default. You can choose between InverseSquared, InverseSquaredNoRangeAttenuation, Legacy, and Linear. If you want to use a different light falloff method, simply change the following line:
ld.falloff = FalloffType.InverseSquared;
Once that is done, simply attach the script to the light of your choice. Keep in mind that only baked lights are supported at the moment.
If you happen to not see any changes in your light falloff after modifying the script, try to disable and enable the light and rebake the scene.
We have also put a small example project which contains a single light, with the custom falloff script already attached to it. Keep in mind that you would need to open it in Unity 2018.2 in order for it to work. You can download the project via this link.
If you need more information, please refer to this manual page on custom light falloff in Unity - https://docs.unity3d.com/Manual/ProgressiveLightmapper-CustomFallOff.html
ld.falloff = FalloffType.InverseSquared;
since it is lightmap process it should be available in the default renderer
Where to apply script? On camera or point light ?
Thanks Kristijonas for your detailed answer
Did you read Kristijonas post above?
I don't know if this changed in 2018.2, but I found that to be on the safe side, I usually end up loading another scene and then reloading the scene I want to make sure the change in falloff actually happens.
Many thanks to you and Jesper for answering everyone's questions! (Here's my original post: https://forum.unity.com/threads/progressive-lightmapper.454362/page-13#post-3473156 )
So it turns out that my project had no " LightmapParameters" object in the project. Should that be generated automatically at some point? So I created one and left the settings at defaults, the tried lightmapping my game scene again. Attached are some views. You can see that the lightmap does not correspond to where the actual (realtime) shadows are cast on the terrain. These are tree-creator trees, and Double Sided GI is dimmed/inactive on those materials.
Hi There Unity,
I just encountered an issue using Progressive lightmapping with an Alpha clipped material using LWRP:
On the top-right you can see the realtime shadow, on the bottom-left the baked version of the same plane. I'm using LWRP and double sided GI.
Doing the same thing and not using LWRP works just fine:
I've reported this as a bug (Case 1061688), and am curious if this was already on your radar.
(edit: Using the latest official unity 2018.2)
Hi Dave! Unity always have a scene wide lightmap parameters assigned in the Lighting window. See this page for details https://docs.unity3d.com/Manual/class-LightmapParameters.html
Creating a new parameters asset will have default values and assigning it to your object without modifying the values will not change anything. You have to modify the values in the parameters asset you assigned to your object.
From your screenshots I can tell that you are getting a lot of invalid lightmap texels on the terrain. This is because the lightmap texels on the terrain are seeing a lot of backfacing triangles from the trees.
- Try setting a higher backface tolerance value on the lightmap parameters for the terrain
I can only find Backface Tolerance value on the LightmapParameters object that I created in the project -- it's set to 0.9 there, which is almost maximum value. Is there somewhere else to set it for the terrain specifically? If so, sorry, I can't find it and would appreciate a tip....
Just tested the progressive lightmapper in 2018.2.02f, everything is fine, just that the light mapper started to not save and I can't get it to save the baked light maps again. I can see the textures in the global maps tab, but I can't get it to save them to the scene folder.
Could you advise on a workaround or a fix on my side?
The saving works sometimes and sometimes doesn't. Is there any settings that I configure to ensure saving (some buffer size or smth like that?)
In the manual https://docs.unity3d.com/Manual/class-LightmapParameters.html have a look at the `Assigning Lightmap Parameters Assets` section about assigning to GameObjects.
Is mixed mode lighting broken in 2018.1.3f1? I'm using the Progressive lightmapper and when I bake a light out and then return that light to Mixed Mode it doesn't light my real time object anymore.
2018.2 released but no gpu baking system.
It should come at some point in the 2018.3 cycle !
I must be doing something wrong now. I bake my lighting and the directional light in the scene still affects the track surface, but it should be only lit by a lightmap after baking. I've tried Subtractive, I've tried Shadowmask and all of the different options. My track is set to "Static", it's got Lightmap UVs generated for the mesh. My light is set to "Mixed" so it should bake the track lighting and dynamically light the vehicle. No clue why it isn't working. It does bake lighting to the track when the light is set to "Baked" but when I switch it back to "Mixed" it doesn't light my vehicle anymore.
Is something broken with Mixed Mode lighting?
I try to use Light Probes to bake "real time" lighting, but it kills all nice specular shine on my vehicle and it looks awfully flat, so light probes don't' seem to be solving this either.
EDIT - Okay I did find a nifty workaround that appears to be working. Use two lights. One is a real-time light and the other is a baked light. They are both set to use culling layers, so the real-time light only affects my vehicle and the baked light only affects the environment. Once I'm done baking I disable the baked light, so the only light being used in my scene is the real-time that only illuminates my vehicle. It appears to be working, but feels like a hack or workaround.
If this isn't already possible, it would great to able to bake gi during runtime for user made levels.
I've seen a reference to this on one of the blogs.
"The Real-time Ray Tracing with GPU Progressive Lightmapper is expected to be released later this year. To learn more about Radeon Rays visit GPUOpen.com and subscribe to AMD Developer News to stay up to date."
What is the status of GPU support. Today with 2018.2 I've finally managed to bake an outdoor 600x600m city scene. Took a while so I would like to lut the 1080 to work instead of my older cpu.
This is the baked urban map. It is the available Naniwa -Ku map by zenring plus a lot of extra stuff by me, I should not have added small objects to lightmap as It is done trough proves, but I'm still getting familiar with teh system. I had to doubl ethe intensity of directional because initially it was too low lit, may be this could have been tweaked with exposure on the filter stack.
7h is not the end of the world but does not let much marging for increasing quality without leaving me without my working tool.
At 0.5 resolution it takes about the half despite the docs say its 4 times more texels. I wonder if leaving 0.5 resolution and puting 4 times more indirect rays would be better.
I'm having issues with road markings that are a plane with texture with alpha.
They get black.
RENDERER FOR THE FAILING ROADMARKINGS MESH
If I switch to cutout from fade they look fine in the range where lightmap is not active but go black when they enter the lightmap distance.
This may not be an issue but I set lightmap size 4096 and sometimes it makes 1024 other times 2048 I guess it is that it can take up to 4096 lightmap tiles and if it does not need all of em it just uses smaller size. If not, there may be a bug.
Of course, GPU!! powered bakes. I need that extra time to increase quality of the bakes without dying in the wait.
Bake selected button! kmon, I do have to rebake the whole thing just for new additions.
Is it possible to bake proves only? because if not it should.
Bake Just AO option.
For an start baking AO mayy be fine, this shot is just AO from the stack fx.
It may hav eoverlapping uv as warning message says. dunno, that meshwas creater in editor with a tool that mergest different meshes. Now I should find a way to create uv2 for theese.... I don´t recall having theese issues in Beast.
I'm baking this scene, first time it works with PLM, still too slow for the resolution that is outputing. GPU now, please, I honestly can´t get to understand why they whent CPU path.
settings are the ones from above post
Would it be possible to replace enlighten in realtime GI with Progressive Lightmapper ?
Okay, the problem was indeed the backface tolerance.....but it took awhile to figure out because I thought "use a higher tolerance value" meant to increase the General GI: Backface Tolerance slider value. But that just made things worse, so I finally tried reducing it (to 0.12) and now the tree shadows are baked quite nicely! So I'm not sure why "higher tolerance value" = smaller value on the Backface Tolerance slider, but apparently it does. Problem finally solved, thanks.
Is cookie baking supported yet?
The problem is right there in the screenshot: your m rays/second. It seems Unity still has not fixed it or backported it as promised. CPU utilization is near nothing. It's like driving a Ferrari in 1st gear only.
My post: https://forum.unity.com/threads/progressive-lightmapper.454362/page-13#post-3486636
The reply was: https://forum.unity.com/threads/progressive-lightmapper.454362/page-14#post-3557556
This is the issue that's holding back the lightmapper. The current CPU progressive preview lightmapper was lightning fast in 5.6. Either Unity accidentally created a bug, or purposefully slowed it down to build hype for the GPU lightmapper and are slow to provide a fix for such a critical feature for the past, well, 2 years. If you can, try 5.6 and see.
I bet the GPU lightmapper will only be in the paid versions.
Would it be possible to have the lightmapper use UV2 from an AdditionalVertexStream assigned to mesh renderers? I tried setting custom UV2 additionalVertexStream mesh in the Lightmapping.started event but the progressive lightmapper likely resets them.
If set prior (& visible as being set), when lightmapping begins it clears away the additional vertex streams.
Also related, controlling the raster position via the Meta Pass vertex shader doesn't change anything in progressive (haven't checked enlighten). The vertex positions can be all set to 0 and the scene will bake without issue. (using LWRP to test as it doesn't use the Unity cginc files)
Basically I'm looking at ways to supply some custom per-chart packing prior to baking, the main requirement is without modifying the original meshes. So either through StructuredBuffers & modifying the raster position in Meta pass, or AdditionalVertexStreams. (The custom per-chart transforms would then be supplied via structured buffer / compute buffer at runtime as part of the render pipeline)
The alternative right now is baking the lightmaps like usual and then repacking the baked result into the new texture and modifying the scene lightmap data which isn't too bad, but would be nice if eventually we could customize things with the lightmapper a bit more.
Try a higher pushoff value for the decals https://docs.unity3d.com/Manual/class-LightmapParameters.html. In large scenes 32 bit floating point precision will not be enough so you have to make sure the object is moved a bit from the raytracers point of view.
We are working on it, stay tuned
No, not yet.
The meta pass can only generate albedo and emission, the position is not modifiable in that pass.
Passing UV2 in an AdditionalVertexStream is not implemented, but it could be done. Please file a bug report with your test scene and we will take a look at your use case.
The proper way for exposing custom packing would be for Unity to provide an API for atlassing/packing, instead of you having to modify positions. We worked on it during a hackweek but there is more work to be done there. It is in the backlog but no promises on when it will be ready.
It is strange that you experiencing this issue - there is no reason why mixed lights would not work in your particular case (static lightmapped race track + dynamic vehicles). I have just tested a similar scenario in 2018.1.3f1 using shadowmask + a mixed directional light and everything was working as intended: a dynamic object (sphere) was lit by a realtime light casting a realtime shadow, and the environment was receiving a realtime direct light along with indirect contribution baked into the lightmap. Please see the image below:
Could you please try baking your lightmap again using mixed lights? If you'd still happen to run into issues, perhaps you could upload a small repro project so that we could investigate the issue on our end? Thanks.
just today i did at least 5 attempts to lightmap a scene. It is not that big of a scene and i wait more than an hour every time on lower settings. Every time i am getting these weird issues where there are white spots like in the images below !
Wonder what could cause this ? If i open the exr lightmap in image editor i am not able to paint on that area, it is like missing information.
Lightmapping is really slow and tedious process because of these issues ( happening 90 % of the time ) and furthermore, the Progressive Lightmapper makes the whole compute unresponsive even on middle scenes. Any option to lower threads priority should be added because a PC becomes unusable while PLM is running.
Enlighten does not affect PC performance that much while working though but it's kinda slow baker !
THIS IS A LONG TIME EXISTING ISSUE NOW:
What could cause this and how to avoid it !
Currently using 2017.2.3 p1
I used to have the same issue, but it hasn't appeared in a while.
Is PLM still in preview for that Unity version? If so, you should upgrade to 2017 LTS if possible.
I think technically it's not missing information(in photoshop) it's infinity white/black, which photoshop can't handle. A bug nonetheless. There was some way to fix it in photoshop but I can't recall.
A temporary 'fix' might be setting the lightmap parameter 'Backface Tolerance' to 0 across the scene. It might also have something to do with lights intersecting geometry, or just geometry intersecting geometry.
Yep it is !
Upgrade it's not an option when you are creating a package for the store and want to support lowest possible version !
Most of the time appears on different objects actually and i feel that it happens in a scene where the load on the CPU becomes too big, it doe's not make sense but i think it happens mostly when PC resources are low - however not sure about that !
I'll check this out again soon and get back to you. It's not entirely my use case though. I don't want the environment affected by any real time lights whatsoever. It's a mobile project so all lighting, shadows and GI needs to be entirely baked to texture maps. The only object affected by the real time light should be the kart itself.
In this case, using culling masks (baked light for the environment + realtime/mixed light for the karts) would be the best solution. Looking back at your previous posts, seems like you've already discovered this solution yourself.
Another possible solution would be writing a custom shader with fake specular, although not sure how feasible would that be in your case.
Please Don´t forget to give us a „Bake selected“ button.
Finally we can share the GPU lightmapper preview: https://forum.unity.com/threads/gpu-lightmapper-preview.561103/. Please keep all GPU lightmapper discussion in that thread and lets keep this one about the CPU lightmapper. Thanks!
Has the bake caching broken in 2018.2.8? I change the filtering settings and it rebakes it all. Also what happened to the shaded wireframe mode in scene view?
Cant help thinking it would be good to have more control of bake atlas's, such as being able to specify what geo goes into what map.