What is this lightingdata?

[neon palm]

when I bake with adaptive probe volumes it appears, the scene goes way too dark unless i set that to "none" ...

Do i need that?

[smoky gate]

It contains the baked data, including APVs
So you do need it

[neon palm]

Seems to make it lighter on bake I just had a increase the density... I did a 0.4 minimum but do you have any typical values you'd use in a dark house?

[smoky gate]

Depends on how much lighting variance you need relative to objects in the house

If you have no detail objects in it, 0.4 could be even too much
If you do have many, it could be way too little

[neon palm]

Can you give some average example of both situations?

[smoky gate]

I don't really have those
Each probe in the volume is a point of stored lighting
You only need them where the lighting changes in a meaningful way
That can happen in occluded crevices and spots between light and shadow, for example
You only need enough probes that the changes in lighting in space are adequately represented by them

[neon palm]

Yeah I got a more expected result at 0.3-06 but now the walls are splotchy in some bits

[smoky gate]

There's some official videos about APVs on the Unity youtube channel which are good

[neon palm]

I watched one with a tent in the desert but a lot still left me confused

[smoky gate]

Splotchiness is typically due to low sample counts
APVs require pretty big sample multipliers on average
But it can be also be due to resolution if the splotchiness is less random and more inaccurately capturing nearby light sources or light bounces

[neon palm]

Ah my sample counts are set really low I guess

What would you set an indoor sample count to on average indoors vs outside then?

[smoky gate]

Not really "averages"
Start with default sample counts and crank up the multiplier between bakes to see if the noise is affected

Any non-direct light is prone to requiring a lot of samples

So it depends on the lighting conditions

Emissive materials when used as light sources for example

And light that's reflected from surfaces will scatter the rays a lot, also requiring samples
Especially so if the light source is very close to a reflective surface

Like a wall or a lampshade
All light hit by such a surface will be calculated as indirect light
Which are noisy because they scatter

[neon palm]

im scared of crashing so ill just bump them up a bit at a time

[neon palm]

which one is most important?

are they supposed to go up a tick together

[smoky gate]

"Light Probe Sample Multiplier"

You can leave the sample sliders where they are

[neon palm]

oohhh

[smoky gate]

It's possible to also bake lightmaps with APVs, so that allows them to use separate sample counts
As lightmaps need much fewer

[neon palm]

yeah thats

im seeing it go away more and more for each +1

[neon palm]

I went up to 8x, it seems that 5x was probably enough, but that seems to have fixed it now i just wonder why one of the lights has a tendency to go reach where it shouldnt

[smoky gate]

Hard to see much
You could turn up the camera exposure to reveal the light that's there
and/or use the rendering debugger's APV view which also allows you to adjust the exposure for preview iirc

The last image shows a scenario where you have object geometry so close to a light the probe resolution might not be enough
But because it's only an apparent problem with a single lonely probe, it could also be fixed with probe volume adjustments

Like virtual offset

[neon palm]

it seems its lighting up 4 probes there

[neon palm]

in this case would i need to raise it or lower it?

[smoky gate]

With virtual offset you'd offset the affected probes away from the light they're not supposed to be lit by
So that when lighting is calculated, they don't catch the light rays

That said there could be some other issue, as it doesn't really seem to make sense why those probes are lit and so brightly too, so out of place

[neon palm]

i moved the APV override box to be isolated to the inside of the house and now the light looks spread more evenly so i guess thats more accurate?

previously the box was extending out quite a bit outside of the cabin, does that make sense as to why the result was off?

I'm guessing its really important to box that in properly?

I just used "fit to selection" previously

[smoky gate]

Not particularly, unless you changed other settings
Even if you had a scene-wide APV it still uses the same logic to determine placements and high and low resolution bricks
But just moving the volume a bit will cause subtly different generation results despite the same logic used, which may have been enough to fix or at least improve the light distribution error

Not a proper solution though