I can see how you guys got to where things are but you really should clean it up and fix the documentation.
An override in the scene changes the data in the profile asset, there is no overriding going on here. A volume component in addition to the functionality it has itself, just exposes the editor for the volume profile.
The volume profile is overriding the global volume profile, that is actually an override.
Volumes are sort of like if all MB’s were SO based with some type of separate MB editor component required in the scene.
If Volumes did what the docs actually said they do, that would be great. I could have a set of base volume profiles that I can share over multiple scenes. But as it stands it’s mostly annoying indirection.
There were always a few things that didn’t have the same behaviour as monobehaviours in this regard (materials for example) but they were few enough that you could just remember “all data belongs in the scene/prefab except for materials which are shared throughout the project”.
But now it’s a mess. (Timeline events - I’m looking at you).
Some things only affect the scene, some things are saved to the shared asset. Some assets even remember changes made at runtime…
I can’t think of a technical or logical reason why volume profiles overrides don’t behave as you suggest.
It is strange - like when you change a volume in the inspector at runtime - and it changes forever, including the profile asset it’s using…
Not sure there should be an editor in the scene inspector for a volume (just select root asset only). Or at least make it obvious that the edits are tied to the root asset not just that volume instance.
Why can’t you instance volumes for slight changes anyway? - to be fair you can make partial volumes to take priority over base ones
It looks like the behavior of Volume is actually a bug. Volume has an internal VolumeProfile that it’s supposed to instantiate from the linked VolumeProfile asset. But it’s not doing that, the internal profile is null. Or they could be short circuiting that intentionally for some reason.
I can see a couple of ways you could go on the flow here. But I think maybe a good middle ground is make VolumeProfile a plain class. At least make storage a separate concern. So you could then have VolumeProfileAsset SO and VolumeProfileComponent MB for instance. And be able to add a VolumeProfile to your own classes. I would probably also abstract out override handling.