Instantiated content not affected by scene fog?

I have a scene that is mostly instantiated from an addressable asset, expect for the excavator in the discance (I forgot to add it :p)
However, that excavator made a bug clear: the addressable content is not affected by the scene’s fog in my built version of the app (Oculus Quest)

Here you see that only the excavator (part of the scene) is blueish, while the rest of the scene (addressables) is not blue-ish

In the editor however, everything loads fine and blends with the fog, everything in the distance has a blue tone:

What is going on?

Using Unity 2019.4 with URP 7.x

I’ll kick this to the team for some insight, and guidance. Which version of Addressables are you using?

Hi

Thanks for getting back to this. In the meantime I found out about the problem: the addressable system doesn’t take into account shader variants that may occur when loading it into a scene that contains fog. In my case I had to set these values and now all works. But I think more people will experience this problem at some point so it probably needs some explanation.

Unity 2019.4.17
Addressables 1.16.16
URP 7.5.2

2 Likes

Hi could you explain a bit more on how the scene/its objects are being loaded. Is the scene an addressable asset that contains all the objects (with the exception of the excavator)?

Also when in the editor, are you using a play mode script other than “Use Existing Build (requires built groups)”? That script most closely replicates the behavior of a build application as it will access data from your AssetBundles. This might be the reason why you’re seeing different behavior in the editor vs the build.

Hey - i have the same exact problem. Took me forever to find because i thought it is some kind of bug in the shader compiler. It is present in Builds as well as Play Mode Script → Use Existing Builds.
The attached image shows the same Model with a material assigned in the prefab itself and on the other loaded with Addressables. The loaded material has no fog. Same for every Asset i am loading with the Addressables system - no matter what (Prefabs, Materials etc.).

Addressables Version: 1.18.4
Unity 2020.3.3

Reproducible on MacOS (Metal) as well as Windows.

1 Like

It’s hard to determine without knowing the exact project setup. If the scene containing the assets is not addressable (is only in player data) but the assets are addressable, then shader variants won’t work for assets in the scene.
Otherwise I would recommend submitting a bug report with your project if possible :slight_smile:

Just came here while hunting for the very same issue.

That this is flagged as “intended behavior” and not “bug”, or more as “caveat/limitation” is plain silly. At the very least, it should be more clear in the docs, with a potential warning in the editor to flag that “You’re instantiating Addressable contant in a scene with fog, shader variants may not be computed correctly as a result”

2 Likes

Hi, I got same problem in Unity 2020.3.9
The prefab which has original material Instantiated from assetbundle that could not affected by fog.
But when it already instantiated, after gave it the same material it affected by fog.

We are seeing the same issue here. Asset references loaded using InstantiateAsync(transform) do not seem to be taking fog correctly in builds, and in editor when using PlayModeScript-Use ExistingBuild. We are only a few months from shipping so we’ll probably have to move the assets to the resources folder and load them the old way.

Unity 2021.3.30
Addressables 1.19.19 which is recommended for our build

.

Here is an image that shows the problem. The assets that are unaffected by the black fog are object references loaded and instantiated asynchronously after the level is loaded. The assets that are working correctly are static assets in the scene.

We found that the shader stripping option in player settings fixed this for us.

1 Like

I agree with IronHelmet and believe that fog stripping behaves incorrectly when you have a built-in scene and asynchronously instantiated assets from the addressables bundle.
It could’ve been considered “fine” at least if warning mentioned by @khan-amil were implemented…

1 Like