formal cypress
I have one light (selected), set to baked and hard shadows. The box is set to static shadow casting. APV Probe invalidity settings turned off Dilation and Virtual offset. I expected the circled probe points to be dark, since they are in shadow. We can clearly see that another probe point closer to the box is dark. What's happening? Most points behaves as expected, but these I can't understand.
(Using Unity 6.2.1)
rocky heron
I have one light (selected), set to baked and hard shadows. The box is set to st...
Where are those in space exactly relative to the box?
Maybe another angle could be useful to show
Also I notice that adding a Probe Offset that's a fraction of the world unit grid that your meshes may be aligning with can solve a lot of this type of weirdness
formal cypress
Yes, I understand it's not super-easy to see from one angle, but basically they are on the row above the ones being dark.
We can focus on just the ones behind the box. I expected the "top" row to be much darker. It seems like they inherit values from their neighbor points or something. Maybe that is how the calculation is done? (but seems wrong to me)
rocky heron
We can focus on just the ones behind the box. I expected the "top" row to be muc...
I believe that's what invalidated probes are meant to do, but no apparent reason here why they'd be invalidated
formal cypress
Also why I turned that off, so it would not interfere with the "raw data".
rocky heron
Before I noticed that an odd offset can improve these errors, my solution was to try lower probe spacing so the accuracy improved sufficiently, or use virtual offsets locally to manually move the probes towards the area where the lighting would be more appropriate, like down and to the right here
Or move the sample positions rather than the probes to be exact
formal cypress
Unfortunately it's hard to know what settings are for baking and which ones are used in runtime
It would help to know how the calculations are done. Anyone know if that is documented somewhere (besides the code)
What I want to achieve is basically a voxelspace of lighting+shadow data of static objects, which it seems like APV is. But it won't behave like I want. 🙂
rocky heron
Unfortunately it's hard to know what settings are for baking and which ones are ...
APV settings in Lighting window and Probe Adjustment Volume properties are at bake-time
Only Adaptive Probe Volumes Options volume override is runtime, and is applied to the camera like most volume overrides
formal cypress
Ok, makes sense.
It's so weird. I moved the box a little higher and rebaked. We can see that now the column on top of the box is dark, because it's in direct shadow, but the column behind to the right is not dark.
rocky heron
It's so weird. I moved the box a little higher and rebaked. We can see that now ...
Did you try the odd offset yet? I recommend your minimum probe offset divided by three on all axes
formal cypress
World Offset?
rocky heron
World Offset?
If that doesn't change anything in this situation I'd do a bit of a sanity test and duplicate the problem area's meshes and lights into another location moved only on one axis
Then again onto a different location but rotate 180°, and a third copy that's angled 45°
Then bake again to see if the same "translucency" repeats in these different locations
formal cypress
Hm. That didn't work. But I just had an idea that could explain this. Isn't the APV data saved as a 3D texture? And if what is shown is fetched with trilinear sampling, there would be some pollution/blending from neighbours
Maybe. Grasping for straws. I have to go now. I guess I can try later on a simpler test-scene.
rocky heron
Hm. That didn't work. But I just had an idea that could explain this. Isn't the ...
Anything change at all? The problem probes should at least be different since they were baked with altered positions
Reading the APV is subject to sampling smudgyness, which is why it's not accurate with corners and fine geometry
Which is what the APV Options like normal and view bias deal with
But that should not affect what data gets written during baking, I think each probe's surroundings would be sampled precisely from where it is (after virtual offsets)
Probe Invalidity Virtual Offset is separate from Apply Virtual Offset
The former gets applied to probes that are detected to be invalid due to being inside geometry, the latter is applied manually with a volume
Assuming Dilation and Virtual Offset are disabled from Probe Invalidity Settings, the remaining mystery is why the probes at that position don't seem to raycast against the upper half of the box during baking
That's why I'd try duplicating the spot, as that'd reveal if it consistently occurs with those meshes and lights, or if the problem may change or disappear entirely if position and rotation changes also
Sometimes probes miss renderers for no reason and all it takes to make it right is to nudge them even a tiny distance with offset or virtual offset
formal cypress
@rocky heron Sorry I had to leave in a hurry yesterday. Adjusting the Probe Offset changed where the probes are, but the change in light was minimal. I'm gonna experiment a bit and see if it always occurs on all edges. My gut feeling says the occlusion check does something wrong, or unexpected.
formal cypress
I tried testing with just one asset and one point light. Set the point light to intensity 10 to "shine a light" on the problem. The red circle should be dark. It's on the same row as the other dark ones, and the asset is positioned with no rotation. I can only assume it is the occlusion test that is wrong?
More outliers, reversed. So perhaps the occlusion tester is just not as accurate as I expected.
formal cypress
Sometimes probes miss renderers for no reason and all it takes to make it right ...
Basically this. Do you know if this is an expected limitation, or bug?
formal cypress
So, one point light and a cube (scaled 1, 0.5, 0.1). Top image has some faulty light probes. Moving the cube away from the light (to the right in the image), corrects the probe to dark. I can't come up with a valid reason for this. I think I'm just gonna bug report it, even though I can't really see how this is not a known issue.
