Why is VolumeComponent a ScriptableObject?

Unity Engine
,
1

You created a paradigm where you can’t just play around with settings easily. Especially a pain when you have multiple precise settings that need to be changed together to get to a state you simply want to test.

And made worse by volumes not actually overriding anything.

So I have to create my own Volume basically to solve this. Not hard to do but honestly that this didn’t hit someone as an obviously bad idea up front is a bit surprising.

1 Like
2

Volumes override things from other volumes. For example, a local volume within a global volume can override what the global volume normally does in a small area.

It sounds like you were more expecting volumes to work like prefabs, where you can override a prefab value in a prefab instance?

3

No that’s not how overrides work. Volume blending is what you are thinking of.

A VolumeProfile is basically a list of VolumeComponent both being ScriptableObject’s. A Volume has a reference to a VolumeProfile and an optional VolumeProfile instance. That instance is the override. Or more specifically it’s list of volume components.

But being an asset it can’t persist in a scene, and that is where they went wrong.

If you have data that is not itself inherently tied to an asset or scene scope, then inextricably linking it to one of those is bad design. And you end up with the situation Volumes are in.

4

I’d guess the main reason it’s SO because PPv2 used SO’s as well. I personally like it because it lets you tweak the settings realtime in way that persist even after you’ve jumped back from play-mode.

I’ve love to have some better way to accomplish that specifically (without 3rd party assets) but SO’s are best we got for this today IMHO. While on this topic I’d love to have frame settings also as SO’s.

I’m not very fond of prefabs in general for this type of use, it’s feels like OOP inheritance vs composition.

5

You make a good point but I think this points to the real issue - why can’t we have both?

  1. The ability to persist changes made at runtime.
  2. The ability to override settings inside a prefab/scene without affecting other prefabs/scenes

These aren’t orthogonal choices. Or rather they are but only because of design decisions - not because of any inherent structural reason.

Unity manages to introduce 3 types of things:

  1. Things that discard runtime changes and only affect the current scene/prefab.
  2. Things that persist runtime changes and affect all scenes/prefabs.
  3. Things that discard runtime changes but affect all scenes/prefabs.

Rather hard to keep this all straight in your head! Zero points for predictability and consistency. :slight_smile:

But what’s missing is the one that would be most useful:

  1. Things that persist runtime changes but only affect the current scene/prefab…
6

The volume system was done this way (as was the PP stack) because at the time there was no other way. The system required polymorphic serialization which wasn’t available at the time.
We do have discussions to see if we can do away with the asset design but it goes with a huge impact on data migration and also can change workflow significantly.
As such we have no ETA yet as to whether or not we are going to change this.

1 Like
7

Might be my misunderstanding but I was talking specifically about VolumeComponent. Which is not polymorphic. It’s VolumeParameter children are. My understanding was in this case VolumeComponent being an SO doesn’t impact how it’s VolumeParameter’s are serialized. But that could be tainted by having worked with Odin Serializer for so long.

I wasn’t suggesting that VolumeProfile not be an asset.