Significant URP Lightmapping/APV discrepancy between 6000.0.11f1 vs 6000.0.3f1

Graphics Render Pipelines
, , ,
1

I don’t really know if this is primarily baked light from the lightmapper or apv, or really both, but there is kind of a huge difference from 6000.0.3f1 to 6000.0.11f1.

3f1 baked light results:

Unity_9awRJZ6tLT
Unity_9awRJZ6tLT1281×1179 282 KB

compared to 11f1 results:

Unity_1ipFMrCQyN
Unity_1ipFMrCQyN1281×1179 304 KB

and this is prior to baking lighting, in 11f1(cleared all baked lighting)

Unity_LYCNgS0gVf
Unity_LYCNgS0gVf1405×1080 238 KB

I’ve already downgraded and upgraded twice as well as deleted library to double check that this isnt a random chance thing. There was a shader change that added

#ifdef USE_APV_PROBE_OCCLUSION
    float4 probeOcclusion : TEXCOORD10;
#endif

to the varyings as well as a new way to sample probe data later on of the urp forwardlit shader that I think is when this discrepancy started but I’m not entirely sure.
Anyone else getting similar results?

2

@thelebaron I have the same problem, the lightmap textures are genereted as default textures instead of lightmaps. Go to the folder with the name of your scene, where your baked lightmap textures are, and manually change the lightmaps texture type from “default” to “lightmap”

Its a bug in 6.0.11

3

Thanks, always feel like Im actually going insane when these sorts of bugs pop up, did you by chance report this? Oddly enough I made a repro project with 11 and its not setting the textures as default, so I’m unsure if theres some further step to reproducing it other than just default behaviour of 11f

4

Also just setting it back to Lightmap doesnt resolve the brightness unfortunately.
edit strike that, needed to set DirectionalLightmap for the directional ones.

created a utility that automatically sets lightmap textures to their correct types after baking

5

No i haven’t reported this bug formally, i’m too lazy to make a repro project just for that.

Oddly enough I made a repro project with 11 and its not setting the textures as default, so I’m unsure if theres some further step to reproducing it other than just default behaviour of 11f

Maybe if you delete the library folder, unity downloads a updated version of some unity package that has the bug.

6

Do you use editor presets? I think Ive narrowed it down to a Texture preset that causes this, when deleted it doesn’t happen. I’m not sure if this is expected or unexpected behaviour when it comes to presets affecting what gets output by the lightmapping process.

7

I use the default presets that come with unity, never touch them.

I’m not sure if this is expected or unexpected behaviour when it comes to presets affecting what gets output by the lightmapping process.

definitely must be an unexpected behaviour.

must be the assetpostprocessor fault.

EDIT:

I think Ive narrowed it down to a Texture preset that causes this, when deleted it doesn’t happen.

Tried making a repro project with the urp template and noticed that there a no presets and lightmapping works like you said.

EDIT2:

tried making another repro project but this time in unity 2022.3.38, created a default texture preset and baked the lightmaps but the textures came in the correct format. So there is definitely a bug in 6.0.11. Lightmaps should not be affected by the texture preset but they are somehow.

I can’t send a bug report, it gives me a error message after finishing packing the report

8

Just skimming through what landed in that version. In 6000.0.11f1, a change was made that lets lightmaps be affected by texture presets. Before that version, it wasn’t possible to use texture presets for lightmaps in any way, and this was reported to us as a bug.

Now, we might have made a mistake here, but before I draw any conclusions, I’ll ask: Your project was using texture presets for a different purpose already, and after updating, these presets broke your bake, is that right?

9

IN-81000, I could not edit the title here to include the bug report. I’ll be honest I have no idea when these presets popped up(maybe it was from some samples, maybe editor alpha, maybe an asset), and I’ve never used them or given them any thought other than maybe I should delete these random presets I have.
Anyway, a texture preset were present and it broke the lightmapping result after updating to 6000.0.11f1.

10

We had a bug report from a user saying the exact opposite: presets should affect lightmaps. Basically, their argument was that lightmaps are textures, and Preset Manager can be configured to act on all newly created/imported textures, and thus also on lightmaps (because they are textures). After discussing this among engineers and designers, we agreed that that made sense, so we made (what we consider) a fix which means that lightmapping will now respect any presets configured in a project.

Note that you can of course still configure Preset Manager to only apply your presets to some textures using the “Filter” field. So after this change, we have now enabled the use case where a user (for some reason) wants to use the Preset Manager to affect lightmaps (like in the aforementioned bug report). Users who don’t want that can either 1) not use texture presets, or 2) use “Filter” to decide what presets should affects which files.

So from our POV, this change is a fix, not a bug. With this extra context, do you still think it is a bug? If so, please elaborate on why. Thanks!

11

After the change in 6000.0.11f1, presets will be applied to generated lightmaps. If the user sets up a preset and if this preset is configured to act on all textures and if a lightmap is a texture (which it is), then we think it makes sense that the preset acts on lightmaps as well. Hence, we don’t see this change as a bugfix but rather a fix. If you don’t want this behaviour you can either remove the preset or use the “Filter” field in Preset Manager to avoid applying a specific preset to lightmaps.

Please also see my reply above to Fazmo_dev. With this extra context, do you still think there is a bug in 6000.0.11f1? If so, I’d like to understand how/why you regard the behaviour as a bug. Thanks.

12

@thelebaron Also: I really like the style of your game. Reminds of the early Playstation era. Where can I see more of your game? :slight_smile:

13

I guess I lack the imagination as to why a lightmap texture’s settings might need to be affected by presets, but more importantly it seems more likely a preset you had for a regular texture will be applied to a lightmap after baking?

Im (reluctantly) on twitter @chrislebaron where I really need to post more stuff

14

I guess I lack the imagination as to why a lightmap texture’s settings might need to be affected by presets

One example I know of is that one customer wanted to use Kaiser mipmap filtering for lightmaps and they wanted to set a max size for reflactions. I don’t know why they wanted that because I suppose they have their reasons.

it seems more likely a preset you had for a regular texture will be applied to a lightmap after baking?

If you have a Texture preset configured in Preset Manager with no filter, then yes it will be applied to lightmaps. But as I tried to argue above, we see this as the desired behavior given the design of Preset Manager (a texture preset should act on textures, lightmaps are textures, thus texture presets should act on lightmaps).

In other words: If you add a Texture preset with no filter, then you are saying to Unity: Apply this preset to all added textures in the Assets folder. The recent change makes sure this is actually the case. If you do not intend to apply the texture preset to everything, then you can use the filter in Preset Manager to specify which textures should be affected by a given preset.

If you feel like this reasoning doesn’t make sense to you, I’d be interested in understanding how/why.

15

Delete the files in the Present folder