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.
I'm not at liberty to share this information just now. Will let you know very soon.
Can't wait to hear about it and all the great improvements you & the team have been bringing to the renderer.
Unreal's distance field based dynamic lighting could be very useful in Unity.
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.
Contribute Global Illumination
Receive Global Illumination
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.
Hey! Make sure that Ambient Mode is set to Baked, as opposed to Realtime when you toggle Realtime Global Illumination on.
Also, regarding emissive materials; since Unity 2019.1, we have exposed Global Illumination: None parameter in the material UI. See the screenshot below:
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
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.
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.
Hi! Thank you for reporting this! The probe sampling does have a problem where sample counts are not respected.
That's right. There are slight differences as they were trained against different data, but overall they are comparable in quality. The Optix one appears to produce slightly blurrier/smoother results; that may be good or bad depending on your assets.
The presentation is here: https://drive.google.com/file/d/1evcgkYLhEpGGNhCPLQgnWY6njrRNERoX/view
Can OID potentially be used for realtime raytracing or its too slow for it?
It would very awesome with a single pass AI denoising in realtime! Currently however, AI denoising is nowhere near fast enough for realtime so it is only for offline uses. Denoising for realtime raytracing is very much intertwined with the individual techniques themselves which is one of the main problems of the current generation of RTRT algorithms. In our preview RTRT build we use a per effect joint bilateral gaussian filtering with a temporal buffer. This is an area of active research.
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...
This very cryptic message means that some vertex channels might be missing. Do you have the following channels in the failing geometry? Vertex, Normal, TexCoord0, TexCoord1?
I came across this issue today and now I'm wondering if there is any progress or ETA on this?
Hi Peter, unfortunately the spatially coherent packing has been put on hold due to other issues taking priority. We still want to add it, but I cannot say when or if it will happen. I also responded to your specific question in your own post.
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.
Select the mesh in the project view, then you can see the channels in the inspector in the bottom of the 3d mesh preview.
Any ideas? 2019.2.4
Are you using non uniform scaling on the cube?
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).
Hi, I have reproduced this and created case 1183940. Which version of Unity are you using?
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)
Does it happen without the AI denoiser enabled? Or by denoising do you mean _filtering_?
How can I avoid this problems when a object have before the back of other object?
Hm, I am not sure what it is that you are seeing. It looks a bit like lightmap dilation (at least in the first photo), but that really shouldn't happen there (since the wall is not covered up). A few things to try:
Verify that you have indeed updated the lighting after you last moved static geometry. This is just to make sure that the lighting is up to date. I write this because the first image looks like you baked and then moved static geometry (without rebaking).
Try viewing your scene with the "Texel Validity" debug visualization. For more information about Texel Validity check out the section of that name on this page. If you see something unexpected in this visualization, you may post a screenshot of what you see, and maybe I/we help you based on this.
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.
As you may know, Unity integrates a library called Enlighten which can be used for various lighting calculations. The "Indirect Resolution" specifies the "coarseness" at which Enlighten performs its lighting calculations. Note that this is not necessarily the same as the resolution of a resulting lightmap.
Enlighten is active when
You use Realtime GI (see checkbox in Lighting window), or
You use Enlighten as the Lightmapping backend (as opposed to Progressive CPU/GPU).
So if you are using the progressive lightmapper and realtime GI is disabled, then indeed "Indirect Resolution" is not relevant for you. This would explain why it is greyed out.
Please also be aware that Enlighten is being deprecated and won't be part of Unity in the future (which also mean that "Indirect Resolution" will go away).
That is peculiar indeed. To be sure I understood you correctly: does the dark spots appear only when you enable filtering? This would suggest that it is the filtering process that somehow causes this.
Does it happen with all kinds of filtering (Gaussian, Atrous, AI) or only some of them?
To properly debug this it would be helpful for us to a have a minimal scene that exhibits this issue. If you use "Help > Report a Bug" in the top menu, you can attach a copy of your current scene. You may be able to create a minimal scene by iteratively removing objects from your current scene (while making sure the issue is still there). As a potential side bonus, such a iterative process may give you more insight into why this is happening.
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:
c.rgb *= DecodeLightmap(UNITY_SAMPLE_TEX2D(unity_Lightmap, i.uv)).rgb;
float4 lm = UNITY_SAMPLE_TEX2D(unity_Lightmap, i.uv);
c.rgb *= (4.59 * lm.a) * lm.rgb;
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.