APV Very dark compared to lightmaps

[leaden vine]

As far as I know SkinnedMeshRenderers are lit by APVs. Well, for some reason the Probes of the APV are very dark here compared to the lightmaps of the environment around my character. Any ideas why that could be? I use the standard HDRP Lit shader.

APV render settings

[leaden vine]

any ideas?

[lone quiver]

Show scene window debug view for baked lightmaps + with Highlight Back-Facing Geometry enabled, lightmap UV overlap, APV visualizer in the Rendering Debugger, what your reflection probes are like and what type of light there actually is in the scene
The baked lightmaps you have look very bizarre likewise, there's a warm glow concentrated at corners seemingly originating from nowhere

Should show your light baking settings in full also

I've got a few guesses but they are pretty far fetched, so it's likely there's more than one problem at once
Kinda looks like there might be an attempt to use Realtime GI together with APVs, or if the world geometry is inverted but marked as double sided, or if they have missing or leaking lightmap UVs, or any combination thereof

[leaden vine]

• I think you're talking about Indirect Diffuse Lighting in the Rendering Debugger? I can't find a "Highlight Back-Facing Geometry" option though.
• I have 3 reflection probes in this room with the same settings (first image) (except for volume of course)
• In this image there is only the active Sun light (Directional light) that indirectly lits the room through large windows from the back of the camera's perspective here.
• My guess for that glow is basically light leaks, there is a cellar right beneath this room that is lit in this yellow/orange-ish tone
• Light Baking settings in the second image

[lone quiver]

For debugging 1. lightmaps 2. APVs

Reflection probes have a preview in the scene as well as inspector of what they've actually captured

Is the directional light baked, mixed or realtime?

At least there isn't Realtime GI on top of the baked lightmaps and APVs, but I would choose either baked lightmaps or APVs to get working first because they're separate systems

[leaden vine]

• Lightmap debug view

• APV Debug view
  They look way too dark compared to the lightmaps IMO

[lone quiver]

This is the lightmap UV overlap view which explains some of the light leaking but not all
Show the "baked lightmap" view also

[lone quiver]

They are definitely darker than they should but to verify whether they are dark or totally black slide up the Exposure Compensation in probe visualization to see if any color variance at all appears

This is likely all white because the exposure is too high instead slide this down in the Lighting Visualization until color variance starts appear

The back facing geometry is a bit of an issue but also not big enough to explain all the weirdness

Also sliding this down would be helpful to get a less overexposed view of what's there in the probes

[leaden vine]

This is with a exposure compensation of 5, does that help?

[lone quiver]

Yes

[leaden vine]

The reflection probes

and the lightmap debug view with adjusted exposure

[lone quiver]

That's useful

[lone quiver]

Can I additionally get a contributors/receivers view from this angle

[leaden vine]

Oh, I forgot: The Directional Light is Mixed.

[lone quiver]

What about the light from the candelabras?

[leaden vine]

I bake 2 sets of lighting. One for day and one for night. They are disabled in the day bake (when you see the bulbs glowing that's just because I haven't implemented turning off emission yet)

[lone quiver]

That's probably the core of the problem
Lighting Scenarios are an APV feature only, so the same lighting settings asset can't contain more than one set of baked lightmaps to accompany the APV lighting scenarios

[leaden vine]

I've written my own solution that bakes 2 sets of lightmaps and sets the active one according to the in game time. Similarly, it sets the active APV scenario. And also the active set of reflection probes.

[lone quiver]

So, the darkness of the APVs is expected, the lightmaps remaining bright is not

[leaden vine]

Huh? It's the other way around. The room looks roughly properly lit I think for day time and being lit only indirectly

THis is the view from the opposite side

[lone quiver]

One way or the other

In either case it seems to be a problem of how you do the swapping

Because you'll be swapping everything, it seems like a better idea to have to lighting settings assets containing the whole bake rather than messing with lighting scenarios or sky occlusion

Because you are using baked lightmaps, you're basically locked out of using lighting scenarios or sky occlusion anyway without a visual mismatch

The benefit of those two is to change lighting smoothly, which baked lightmaps don't support

This is still an issue with the lightmaps
It looks like indirect lighting that remains when a mixed light component has been removed/disabled

[leaden vine]

I don't think the 2 have anything to do with each other? I use them to lit separate things. The lightmaps only lit static geometry, the APV only dynamic, such as SkinnedMeshRenderers

[leaden vine]

If that was the case, why would the APV not contain the same indirect light from the chandeliers?

[lone quiver]

They don't have anything to "do" with each other, but you don't want them to mismatch obviously

[leaden vine]

Yeah but why would they mismatch

it's the same scene with the same settings for both lightmaps and APV

[lone quiver]

As far as I can tell because you're swapping one but not the other, however you are doing it

[leaden vine]

I'm swapping both. The chandeliers are also very bright so I don't think they are baked in the lightmaps here

I'll show you a night bake in a second

[lone quiver]

Doesn't look like they're getting swapped correctly
Sky occlusion could be another cause for issues

Where lightmapped objects are receiving bright light from outside, APVs are showing more darkness
That seems to line up spatially where we expect APVs to store the sky occlusion

[leaden vine]

See how brightly the chandeliers lit the environment around them when active

[lone quiver]

APVs here are getting faint warm light from somewhere
It could be from the chandeliers but again to me it looks more like baked indirect light from a mixed light component that's no longer there

Another cause for concern is that the carpets are showing up as pure black in reflection probes, and in some of the other images
That suggests their shader might have a NaN propagation issue which could cause any number of lighting artifacts around the scene

[leaden vine]

But in that case that would be a Unity bug? Because I can rebake the APVs right now with those lights disabled and they still look the same

[lone quiver]

So there are light components there? Or emissives, or both?
The light has to come from somewhere

[leaden vine]

The APV at night, it doesn't look all that similar to this I think

Probes further away are more lit than in the day image

[leaden vine]

Only the chandeliers, but they are turned off currently (day image)

[lone quiver]

Probes near the lamps are suspiciously dark, and probes near the carpet are suspiciously bright, relatively speaking
Not that different result from the exposure adjust probes during the day

[lone quiver]

Can you be specific what kind of lights they are

[lone quiver]

Is there also emissive material?

[leaden vine]

The lights sit right beneath the chandeliers so that makes sense

[leaden vine]

yep, the bulbs have emission

[lone quiver]

Should show how close they are
Distance to geometry matters a lot for raycasting

[leaden vine]

Here is with the chandelier light enabled

[lone quiver]

It's not too close, but the illumination from it matches exactly with the rogue indirect light we see around the stairs and pillars

How exactly does your "solution" bake the two separate lightmaps?

[leaden vine]

Well, you know there's are lights all around this room that are active during the day bake 😄 But that would be extreme leaking?? Second image is "inside" the floor of the room we're talking about. So you can see light from the cellar below

[leaden vine]

I set the suns rotation, disable all lights that should be off during the day and then bake.
I copy the result to a new folder, set the suns rotation, enable all light that should be on during the night and then bake. Copy the result to a new folder as well

[lone quiver]

At those probe exposures and likely even with right exposures it looks very inconclusive what light they're getting and from where

[leaden vine]

Well than let's try it this way: You mentioned sky occlusion could be an issue. How would I solve that? What exactly would be the issue here?

Here's another reason why I don't think it's the light of the disabled chandeliers. The first image shows the chandelier furthest from the windows, the second the chandelier closest to the windows. All chandelier lights are off

[lone quiver]

I think there's too many problems overlapping here to point to any exact one
Focus on getting each part working individually first

1. Baked lightmaps look mostly okay, but the phantom indirect light should be solved. You say the mixed lights were disabled for the bake but evidence shows otherwise. Clearing the baked data before rebaking can help. The void carpets should also be fixed, but fully removed first when troubleshooting other issues.
2. Get your APVs working without involving baked lightmaps at all first. You can swap your level geometry to receive GI to probes instead of lightmaps and in theory the environment should get the same lighting as with lightmaps. Don't bother with sky occlusion or lighting scenarios as they are not helpful in what you're trying to do.
3. It doesn't seem worth it to try to swap lighting in such a hacky way. Generated lighting designed to be stored per scene, so you should do one scene for each time of day. Your environment can be as a prefab in the scene, so every change will carry over, and daytime specific modifications can be as prefab overrides in each scene. You can use additive scenes or DDOL if you want to seamlessly keep or introduce other environments at runtime.
   Most importantly you have to test one thing at a time. It doesn't help to keep wondering if the light problems are coming from the chandelier, the basement, the sun, the sky, emissives, UV overlap, texel invalidity, the carpets, the swapping, the generation, or if the issues are affecting lightmaps, APVs, reflection probes or some particular feature of each
   Rather you test the specific system in a scene that has nothing except what you need to verify that the system is working

[leaden vine]

1. I don't think the evidence points to that, as you can see from my last reply
2. I'm not sure why Sky Occlusion and scenarios wouldn't be useful to me (or how they would even make things more complicated?) The scenarios work fine, I can switch between them in real time and see the difference. The APV lighting is just off for the day time bake specifically.
3. I don't see why that would be a hacky way to change lighting. This is officially supported by Unity and done through their API. There are a number of tools in the asset store that do the same. Unity just never bothered to implement this as an editor feature. I'd actually consider your solution to be way more hacky.

That being said, I appreciate you taking time out of your day and I generally agree with testing things in isolation, but that would involve a lot of work here

Here you can see the clear difference in lighting received from the chandelier lights

[lone quiver]

3. Per-scene lighting and additive scenes do the same but already are implemented as an editor feature, so there's no additional room for error there from introducing custom systems to the mix
4. Sky occlusion's purpose is to allow dynamically changing the environment lighting while keeping pre-baked probes for static light sources. Lighting scenarios are for smoothly blending APV bakes, or swapping them without having to swap scene lighting entirely. Neither apply for you since you are not doing blending and are swapping all the lighting anyway
5. All I can see from the evidence is that they seem to conflict with your assumptions, and they are indicating multiple overlapping problems.
   Testing in isolation may seem like more work, but my experience says it will save way more that would be wasted on chasing errors that are compounding from separate problems
   Lighting problems mix up more than other types, because usually we only see their combined result

I can help with testing the systems in isolation, but I can't help with there being something wrong in the scene somewhere
Poking around randomly might eventually yield results, but whether a fix is correct or not might not be apparent while there still is something screwing up the lighting
And that method won't teach you knowledge how the systems should work, which are kind of the cornerstone of troubleshooting anything

Even if I had your scene and could poke around looking for problems, I'd still rather get systems working one by one

[leaden vine]

3. There is no extra room for error added. There is nothing magical saved in a scene. It's a bunch of arrays of textures that are set. That's it. And I've shown you that the switching of lightmaps and APVs works fine. Hacking a bunch of logic on top to make sure that scenes are loaded in and out without anything getting lost / reset or whatever is way more hacky than just swapping these arrays of textures. It's also not feasable to do anyways as I will likely add baked light blending in the future.
4. I literally use both. I have a sky that changes based on the time and 2 sets of static lighting for day and night time

But honestly none of this is really relevant to the issue. I think I might have mislead you a bit with the high exposure adjustment of the APV probes. The adjusted exposure makes it seems like they are brightly lit, when it is at most a tiny bit of light leaking into the room through the doors.
The same goes with the glowing corners, that is light leaking from other rooms.

The actual problem is that the APV in this room is significantly darker then the lightmaps, although baked with exactly the same settings

Here you can see the difference between the front and back of the room. In both cases the APV is too dark for the room

Here is the same APV lighting the same character in a different room, working fine and matching the environment

[lone quiver]

If you will need smooth daytime blending then yes sky occlusion and lighting scenarios are justified
Though not necessarily for current testing purposes

[leaden vine]

Here is the character at the window. There has clearly light bounced inside from the window, lighting the environment. The APV, however, is pretty much unlit

[lone quiver]

I've given out all the guesses I had, and we found some minor problems and some potential unknowns
I'm not sure what you think the next step is if you don't want to isolate the systems, or do a process of elimination for everything that's even a potential issue

[leaden vine]

Well thats exactly the point I'm making. What are the potential issues I could eliminate?
There is a light 25m in the back, behind a door. That light may leak a little into the room, but it doesn't leak 25m into the room and thus lits the environment substantially more than the APV.
Soooo.... This is not a potential issue, right? Same for the carpet. is that good to know? Of course, but it's not a potential issue here.

[lone quiver]

How would you know?

[leaden vine]

How would the carpet lead to the room being more lit by lightmaps then by the APV?

[lone quiver]

If the shader produces NaN values in some rendering pass, potentially only for APVs and light probes, that error may propagate and screw up every probe in the vicinity

And that's just an issue that seems to make sense
When errors don't make sense, be skeptical of what you think makes sense

Maybe you're on a Unity version that breaks how APVs are calculated in some arbitrary circumstance
Or that causes light components to persist despite disabled but only during lightmapping
Or anything really

Unity 6.3 has been rife with these kinds of issues
But other versions aren't safe
Just recently in 6.0 reflection probes were broken in every update over a few weeks with no apparent cause

In that kind of situation you can look for the cause and try to logic it forever to no avail

[leaden vine]

That's all good info but that wouldn't really make sense to me as it works in the same scene just in a different room.
The carpet thing was a good point too. I threw them out, rebaked the APV and it's still the same.
I'll recreate this room in a separate scene but the thing is if I'm not able to reproduce it in a separate scene then I will be just as far as I am now 😬

[lone quiver]

You will be further because if the error isn't reproduced in the new scene, you can have confidence that what you have in the new scene isn't the cause of the issue
Be it the carpets, lights at the distance, lights of the chandeliers, whatnot

Removing those before rebaking the same scene would be kind of the easier step to take, but not as valuable for troubleshooting unless by luck what you remove turns out to have been the root cause of the whole issue

I think I also suggested at some point to change the room to get GI from light probes instead of lightmaps
Then you get a very intuitive view into how and what light the APVs are capturing
Way clearer than moving some guy around, and sometimes reveals more than the probe visualization grid

[leaden vine]

I'll get back to you once I've set that all up. Thanks for all the help

[leaden vine]

So I got it down to the Sky Occlusion setting of the APV. Unfortunately, even with the highest sample count, the APV is still a bit dark compared to the environment...

[lone quiver]

In theory APVs and lightmaps should have the exact same energy conservation which is a bothersome anomaly
There's no logical reason for it to happen, which is why I'm so eager to totally isolate the issue, even from the current project and editor version