An issue I’ve noticed in a few assets is many assets seem to be designed around old methods. Especially visual assets that seem to go around the unity setup. Sometimes this is fine, but often it can make things more difficult.
And I think the issue might get worse with the release of Unity 6 and beyond. So, I wanted to explain the workflow Unity seems to be going for and what I’ve come to expect. Especially as a dev who releases on multiple platforms (PC, Android, console plans).
This largely pertains to URP but from what I’ve seen of HDRP it’s similar.
Hierarchy
For a while now in URP quality settings are largely in the render pipeline asset. Which makes them also configurable per platform per quality level. I have a unique config for each.
The pipeline asset contains two major things:
- The renderer list which contains Universal Render Data
- An override for the global volume configuration this is new to Unity 6
Universal Renderer Data contains Render Features:
Lastly another new feature build profiles:
Which allows specific player settings. I haven’t dug into this deeply just yet.
Now I understand to an extent this can be kind of a lot but to me it’s extremely useful.
This breaks down in a number of ways:
- The most core benefit is it’s easy to define configurations per platform with less worry. I can make builds and it just works.
- I can globally remove certain effects regardless of if the game has them enabled, which is useful for mobile builds
- I can configure my games general visuals in the global config, then in the Pipeline Asset override them for performance.
- You’ll note I have a title screen renderer in the URD, this has made it extremely easy to setup a performant title screen. It’s devoid of render features and runs at a high FPS. This lets me ensure basically no issues with loading the games title screen.
What I expect from assets
Now the issue I encounter with some assets is a reliance on components over volumes and render features.
For example adding components to lights or a camera for an effect, and specifically having performance related features there not just visual.
This causes a lot of problems for me cause it means I have to do one of number of things:
- Go in each scene the component exists and change it
- Go in each prefab and change it
- Make a custom script to manage the setting in the scene
To me none of these are ideal in comparison to the native solutions. The problem with the latter solution is even if the script sets things per platform it can also mean unneeded features aren’t stripped.
Personally, I prefer the following.
- The effects quality settings be in the render feature, generally these are the kind of settings unlikely to be set independently. (Heavier toggles and deeper quality settings, disabling entire features/effects to exclude shaders, rendering mode settings, etc)
- Volume settings for generally more visual features but some quality (down sampling, samples, etc)
This applies to just about any visual effect. I will say in the worst case having everything in the volume setting can be fine but is less than ideal.
In some cases it’s true some settings may be needed per light/camera but even in those cases I would prefer the above. Possible solutions for that being how lights are handled having high, medium, and low settings that are configurable.
Which helps keep things simple across quality and platforms.
A bit on Volumes
There’s a lot more utility in volumes too which shows in URP and HDRP.
Now APV visual settins are per volume cause settings that work in inside scenes may not work outside.
Recently I noticed in HDRP you can set shadow cascade settings per volume which is HUGE for cinematics. If you’ve ever played something like FFVIIR that sort of thing they do a lot, where the shadow cascades change so that close up character’s shadows are rendered better.
Otherwise they look like this 
Being able to configure volumes per camera in general or with stuff like cinemachine is extremely useful to avoid these problems. And can be much more useful than having specific configurations in a component on a light/camera.
Beyond Unity 6
I think in the long term this process will be expanded even into the unified pipeline based on the roadmap video.
Like now the nature of the rendering is determined by the pipeline asset. I think it’s clear this format is the workflow going forward.
It’s something that doesn’t matter too much if you’re just building for PC, but if you’re building for multiple platforms this stuff is super important! I just want asset devs to keep this stuff in mind.
I hope this post creates some understanding!