Official Progressive CPU Lightmapper

The feature has landed in 2019.2. Look out for

Contribute Global Illumination

checkbox and the

Receive Global Illumination

dropdown (Lightmaps / Light Probes) in the Mesh Renderer's options.

 

Just checked out the 2019.2 alpha and awesome to see it working. I assume it isn't going to be supported with Enlighten (doesn't currently work at least) so might be worth giving a notice to users if Enlighten is selected. Spent a couple of minutes trying to figure out why ambient light wasn't baking into the probes correctly until I realised I hadn't switched to Progressive.

Super quick and dirty test with a grid of probes and a single 8*4*8 LPPV.

 

@Adam-Bailey actually it's meant to work when baking with Enlighten as well and the internal automated tests show that it does. Would be great to get a bug report with your project, even though I don't expect big differences between that and our tests... there is at least one.

 

Just reported it with the title Light not baking into light probes using Enlighten in 2019.2.0a4. I narrowed down the issue to occurring when Realtime GI is ticked in the Lighting panel.



I'm keen to find some time to test this out in a large environment, having emissive surfaces working without any lightmaps is fantastic.

 

This is interesting

 

Yeah, checked that. In the example project submitted there are other light types as well.

 

How to use OptiX denoiser? the denoiser option are greyed out.

 

I got this error message but lightmapper started anyway. What does it mean ? //2019.1b7

 

Link to Jepser's scheduled GDC Talk about the integration of Intel Open Image Denoiser in Unity 2019.x
https://schedule.gdconf.com/session...lightmaps-presented-by-unity-and-intel/865250
Just wish that non Nvidia owners will have a GPU based solution one day. Intel's solution looks good enough for now.

 

No need, really. From testing it seems Open Image Denoise is either on par or better than Optix.

 

Hey so I'm having an issue with light probes, for quite a while actually.

It has to do with how I lit my scenes very indirectly and I really like using small emissive meshes. This leads to sometimes the lightprobes missing the light source and it makes them have inconsistent results.

So for example, here is a very exaggerated example of this issue:

It's exaggerated because I went out of my way to maximise the inconsistence in order to showcase the issue.

Here is another more "normal" example:


I can usually work around these, by editing the positions of the probes that look way out of place and slightly moving them, so I can roll the dice on their sampling again and cause them hopefully miss less stuff. The workaround works, but combined with how I can't really just bake the light probes by themselves it makes it kinda slow and painful to fix things.

I actually did a bug report for this, it's case 1135553 , but I'm not sure if it's a bug or a feature request for "improved sampling light probe sampling".

I'm guessing this is a side effect of the way the light probes do the sampling, which was probably tailored more for speed?

As I said, I'm not pushing for this to be a bug, it could be a feature request (and in that case, it's one I'm actively requesting, for whatever's that worth ).

 

Is it possible to just make global light probes? So, engine would create a grid of light probes across all of prefabs so that user don't have to place them on exact spots.

I suggested this some time ago as feedback.

 

https://assetstore.unity.com/packages/tools/utilities/autoprobe-105295
It helps

Would be nice if its build in

 

I was think like in UE4 but for LP. They could be generated in all space and based on distance to prefabs.

 

Can OID potentially be used for realtime raytracing or its too slow for it?

 

Hi, same problem here using just downloaded 2019.1.0f2, mine is:

[PathTracer] AddGeometry job with hash: f1bf86363eb5f32bc3afcce7b85c6719 failed with exit code 1.

The problem is this error shows over and over again while "Preparing bake...", I mean same hash is shown thousands of times, so the preparing never ends...

 

I came across this issue today and now I'm wondering if there is any progress or ETA on this?

 

I've been getting this same message in 2019.1.9f1...I'm on a Mac and get it for both GPU and CPU...Where would we check our vertex channels? I'm using Blender 2.79b and tried exporting just a plain cube but still get this message. I have "Generate Lightmap UVs" checked.

EDIT: I am using LWRP as well.

 

Can't use progressive light mode in unity 2019.1.10f when use the GPU the program simply crash and with the CPU I get the following error for all object in the scene

This project was working correctly in 2019.1.9f

[PathTracer] Failed to add geometry; mesh is missing required attribute. Please make sure mesh contains positions, normals and texcoord0.

[PathTracer] AddGeometry job with hash: f8e3c13a656530e92e61ee50e5ea77a2 failed with exit code 1.

 

Any ideas? 2019.2.4

 

No, everything is by default and builtin. Important note: this happens if there is a cutout or transparent object near the light source (point or spot).

 

2019.2.4f1

 

Our scene seems to have contracted some awful disease, blotches of 'miscalculated dots' appear in higher number as we crank up the number of samples. So far we have noted:

- It only seems to happen in this one room/area
- Increasing the pushoff helps from 0.001 to 0.01 helps but further increases have no effect.
- Increasing the samples of any type increases the count of these blotches.
- Increasing the denoising doesn't fully cover up the blotches (even to highest values)

 

How can I avoid this problems when a object have before the back of other object?

 

I have need change the backface tolerance to 0.3 in a custom lightmap parameters. I see excesive the default value in medium, 0.9 and with the problems that I see in simple scenes.

 

Lot's of great info on the Progressive Lightmapper in the Unity Docs, but there's a blind spot about Indirect Resolution that I could use some clarification on.

On the intro page here: https://docs.unity3d.com/Manual/CPUProgressiveLightmapper.html,
the Indirect Resolution setting is named and given a recommended value for environment light vs indoor light.

Yet, on the "Getting Started" page here: https://docs.unity3d.com/Manual/Lightmapping.html,
the same Progressive inspector window shows this value grayed out as either irrelevant to Progressive lightmapper, or inoperable due to some other project setting.

So, should I be able to set my indirect texel resolution in Progressive mode? My current project has this option grayed out and I would like to see what changing this value does to the final result (if it's actually relevant). I'm currently using 2019.2.2f1.

Thanks for your help!

 

Yes, I mean changing the filtering options in the Lightmapping Settings doesn't remove the blotches. The different filters only change how the blotches are handled.

Here is a partial lightmap using a different filter that shows the blotches when using the A-Trous filter instead of Gaussian. The blotches show up in the exact same pattern on the wall as the previous post:


Curiously, no 'pure-black blotches' show up with no filtering:

 

You need more indirect rays, and if you are using 2019, try the AI denoise stuff.

 

It seems Progressive Lightmapper can not deal with LodGroup s
see this post https://forum.unity.com/threads/lig...-it-lasts-a-lot-of-hours.628783/#post-5032238

Is this intentionally or it is a BUG?

 

Yes, it is happening with every filter/denoiser combination available.


Update: The issue was a couple baked area lights.

I copied the scene over and started removing items like suggested. Of course I got all the way down to only a handful of items until there were just lights and the offending objects. Finally turning off the two baked area lights atop the walls fixed the issue immediately. Returning to the original scene and turning off just those two lights fixed it there as well.

Partial light bake after the two baked area lights are disabled:



I can't imagine this happens with every baked area light, but perhaps this issue arose due to the area lights intersecting geometry?

 

In which way should I use progresive lightmapper with light probes new feature in 2019.2?

 

I think there is something wrong with the RGBM decoding

Setting Lightmap Encoding to medium, is appreciably lighter than all other encodings.




I tried this:

Code (csharp):

1. #ifdef SWITCHDECODE
2. c.rgb *= DecodeLightmap(UNITY_SAMPLE_TEX2D(unity_Lightmap, i.uv[1])).rgb;
3. #else
4. float4 lm = UNITY_SAMPLE_TEX2D(unity_Lightmap, i.uv[1]);
5. c.rgb *= (4.59 * lm.a) * lm.rgb;
6. #endif

These should look the same, but they don't. My hacked one looks correct, while the Unity macro DecodeLightmap is brighter.

To make them look the same (wrong, but the same), I should change 4.59 to 5.0. Which means for some reason decodeInstructions.x is being set to 5.0 instead of 4.59.

I do not know how decideInstructions in being set, but I can only conclude that it's this:

// These constants must be kept in sync with RGBMRanges.h
#define LIGHTMAP_RGBM_SCALE 5.0

So, is it in sync with RGBMRanges.h ? Why is it set to 5.0 instead of pow(2.0, 2.2) = 4.59 ?

I was wrong about what the solution is, but the general point still stands.

Bug reported, Case 1207489.

 

Can Progressive Lightmapper be utilized for creating static global illumination ? A global illumination effect which is fixed in space.

 

So QA replied with this:

So I tried a completely different machine, a mac mini, and it's the same thing.

The effort that a bug report needs, narrowing things down, creating a minimal repro, screenshots, fighting QA, is approaching the same time it would take me to maybe actually fix the issue if I had source access, or, to the naysayers that say source access is not important: time I could actually be doing something productive.

Spending so much time, just to roll the dice of to maybe see issue fixed in a year or two...

It's not worth it.

For this specific issue, if anyone else cares, you can pick up the slack. If it's only me that cares, no other Unity user, nor Unity employee, then it might as well stay not fixed.

I'm done with bug reporting this or any bug for that matter.

 

Hey @AcidArrow, sorry to hear about your bug reporting experience. ;(

Our QA does their best to try to reproduce the bug in various environments, on different Unity versions (to e.g. prove whether something is a regression), etc. It might sometimes happen that we ask you for more information too hastily. Please don't take that as us throwing the issue back over the fence. It's just a way to gather more information that we are currently missing.

I understand that it might feel like we're putting the burden of gathering more info on you. That's not the intention. It's just one way for us to learn more about about the issue. It's perfectly fine to answer "I don't have more data.".

Within the team we have frequent conversations between QA and devs about bugs that can't be reproduced to brainstorm on possible ways of approaching the issue. Also, it's of course not strictly needed for us to reproduce the issue to be able to fix it, but that makes it much faster. That's why it's the first thing that we try.

I really appreciate the amount of work you've put into reporting bugs and hope that we didn't lose you forever.

Cheers,
Kuba