Please stop with the package release breaking fixes.

Graphics Render Pipelines
,
1

Currently, if you download a Unity 2019.3 version and choose a URP project, it may install:

URP 7.1.6
URP 7.1.8
URP 7.2.1
URP 7.3

This will depend on which patch release you’re on. A PATCH RELEASE, not a Unity version. 3 of these have breaking changes in the shaders that make them incompatible with the other versions. You also can’t downgrade to, say, 7.2.1 on the latest Unity, or upgrade to 7.3 on the older versions.

The same is true for HDRP, as my users are reporting issues in HDRP 7.3 vs 7.2.1 due to undocumented changes.

It is impossible to maintain compatibility with these changes:

  • You don’t document the changes, or any of the shader code
  • You release these at seemly random moments
  • There is no Unity 2019 version of the SRP that anyone can count on actually working
  • Different assets are going to be written for each one, because it’s impossible to support them all. So now any two things on the store won’t be compatible with each other.
  • People don’t understand this when they buy assets, because Unity used to “Just Work”, now, it “Just Breaks”.

So fine, you might write a shader abstraction layer one day to deal with this, which you should have done from the start- given the glacial pace of Unity fixing things vs. breaking things, that’s at least a year or two off. In the mean time, can you please limit breaking changes to align with Unity version changes? Not patch releases? Patch releases are supposed to fix things, not break them, or make it impossible to support your pipeline.

You’ve gone over the cliff of insanity at this point- can you dial it back just a hair?

36 Likes
2

I actually have a question, I’m using Unity 2019.3.8 now and URP and HDRP in package manager just shows 7.3 version and there is no option to go back to 7.1.8 (no other version or drop-down available) even In Unity 2019.3.10 latest version the same problem exists only 7.3 of URP and HDRP is found. Since your post said 2019.3 and the related URP versions posting it here looking for an answer.
Unity 2019.3.5 had options to download any versions (7.1.8, 7.2.1 etc) of URP and HDRP.
I have installed both 2019.3.5 and 2019.3.8 now on my system could this be also the reason as to why 2019.3.8 does not show other URP downloads except 7.3

3

Yes, newer patch versions are forcing newer versions of the SRPs, so if the asset you’re trying to use is compatible with 7.1.8 but not 7.2.1, which is quite common, you can’t upgrade to that patch version of Unity and have to stay on an older one. Of course, the next asset might be compatible with 7.2.1 and not 7.1.8, so you will have to make a choice of which assets you can use as well. And if one asset upgrades to 7.3, and your stuck on 7.1.8 due to another asset, you won’t be able to upgrade that asset or Unity version until every asset is on the new version, or you are willing to remove the older asset from your project.

Basically it’s a massive mess with no workable solution for anyone, and completely disregards the asset use, asset publishers, or how people use actually use Unity.

Unity need to adopt a rule of letting any version of the SRP install in a paired version, not patch release, of Unity, and never changing the API during that release cycle. In other words, in Unity 2019.3.0 → 2019.3.9, or whatever it gets to, you should be able to use any version of the SRP released during that cycle, with no incompatibilities between them. They should not be introducing things like cascaded shadow maps in the middle of a patch cycle for the engine.

This is the exact opposite of what they promised with things like packages - instead of being able to get bug fixes faster, or get them only for what we need them in, we now have a massive cascade effect where trying to get a bug fix for, say, asset bundles released with a Unity patch release, will force you to upgrade to a new rendering engine and break all your 3rd party assets and shaders. And if you want to upgrade the URP to get that new cascaded shadow map code, it might break half the shaders in your project. A surface shader would not have had this problem, and upgrading Unity versions from 2019.3.0 to 2019.3.1 didn’t have these kinds of issues previously either. They’ve made things so much worse.

8 Likes
4

Thanks for your reply, yes a lot of issues regarding the shaders.
For now, I installed 2019.3.7 which gives the option of downloading different HDRP and URP versions. Yes just as a user and indie developer I understand how much pain it is to use assets on a project because of the various render pipeline versions that Unity has now. I’m just wondering how much of a pain it will be for the asset developers, waiting for the 2019.4 LTS version in spring as mentioned in unity site to sort out these issues, else have to go back to default render pipeline or go back to Unreal. Unity is more a 3d software than a game engine because of the way the new updates have been done.

5

Sometimes I feel like HDRP was made so they can say “Where is your Unreal now?!”
Not for people to actually release games using it…

9 Likes
6
1 Like
7

Oh missed this the whole time, I just noted you are the great author of the whole Microsplat series :slight_smile: love all your assets, currently own the Terrain collection, HDRP, URP and the low poly set, still haven’t used the asset :frowning: as I have been working on an old project where I have gaia and cts linked on all my terrains. But want to try out the wind and glitter and lava soon on a new project; as I have been used to the CTS workflow and still need to learn the PBR workflow of Micrsplat but saw some videos love how much control is available need to switch soon.
Meanwhile I have started a low poly project using Poseidon, guess it supports Microsplat so will be adding the low poly pack to it.
Again love all the pack’s great fan of them all.

8

I don’t want to put oil in the flames, but not too long ago I started poring some old code to hdrp and now I’m very surprised there aren’t more threads like this.

When you start reading the hdrp shader code, down to bottom of it, you’ll notice this whole thing is a dune of shifting sands.

What I find baffling, is to the very core of hdrp, the Unity team decided to wipe out everything and start from scratch. But that’s not how things are done. Here is a very very simple example:

For whatever reason, Unity now decided to change the name of the base texture in hrdp. So in code we read:

        _BaseColor("BaseColor", Color) = (1,1,1,1)
        _BaseColorMap("BaseColorMap", 2D) = "white" {}

Brilliant. It’s a base texture, we should rename it so right? Why keep with 10 years of history or so and name it ‘_MainTex’ ?? Now we should rename!

Well down in code we read this:

        // HACK: GI Baking system relies on some properties existing in the shader ("_MainTex", "_Cutoff" and "_Color") for opacity handling, so we need to store our version of those parameters in the hard-coded name the GI baking system recognizes.
        _MainTex("Albedo", 2D) = "white" {}
        _Color("Color", Color) = (1,1,1,1)

A hack eh? Brilliant. We’ve now realized we can’t just name it ‘_BaseColorMap’. But instead of fixing our code to keep with what’s has been laid out there, we stand our ground, It should be named ‘_BaseColorMap’! What can wrong?

We’ll let’s try the following simple code:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class CahngeMat : MonoBehaviour
{

    [SerializeField] private Texture2D newTex;

    void Update()
    {
        if (Input.GetKeyDown(KeyCode.Z)) {
            this.GetComponent<Renderer>().material.mainTexture = newTex;
        }
    }
}

Attach to a mesh with hdrp material. Plug a tex, start the game, press Z. What happens? Nothing. Nothing at all. Because ‘_MainTex’ is hard coded to bottom of the Unity code.

Unity 2019.3.10f1, HDRP 7.3.1

12 Likes
9

Not invented here syndrome. You hire a bunch of new coders, they want to forge their own path, and often don’t want to sift through things to figure out why they were the way they were, what was good about them, or what the ramifications would be when removing them. Instead it’s off into the ocean looking for new land, and we’re all forced onto the ride.

8 Likes
10

Unfortunately, this summarizes my experience with Unity over the last 2 years very well.

The problem is not slow bug fixes and breaking changes between versions. That’s always going to happen in any moderately complex project, such as a game engine. The problem is that now with the engine being fragmented into dozens of separate packages, it becomes a daunting task to assemble a list of working and compatible packages. And as you point out, sometimes this is even impossible.

This is not just an issue with the SRP packages and shader incompatibilities. Almost every part of the engine is now in a similar state. UI, Input, VR, Physics, Rendering. All of these modules have 2 or 3 separate, independent implementations in the engine. In a perfect world, this would give you some flexibility in choosing whatever version best fits your project and that’s probably what Unity envisioned with their package approach. In reality, however, it becomes a nightmare of dependencies and incompatibilities.

12 Likes
11

I agree, it’s completely maddening depending on what you’re trying to work on. For instance, working in AR you hit this issue immediately and you end up spinning multiple plates trying to figure out compatibilities between ARFoundations major releases, Unity patch releases, and URP patch releases.

The package manager is a godsend for Asset Store packages, as well as managing your own internal packages across projects, but I don’t believe Unity should be using it for their own engine features. Engine features would preferably all be released in sync and updated along the main engine versioning path. I would imagine this would make the unit testing for feature upgrades much easier for Unity to manage internally, and would reduce the chaos we are feeling as devs.

1 Like
12

Yes, please. Unity is doing too much.

13

That is not good to hear

We planned on relying on Microsplat for HDRP as Unity terrain is still in 2005 in terms of materials especially
But yeah everything is a mess right now. This package manager madness where nothing works or exists out of the gate is a struggle. It feels like the 3DS max patchwork monstrosity of engines right now.

14

This is why I still will not touch URP or HDRP for anything important. Did a big eval over a year ago and nothing’s changed.

3 Likes
15

This :“forced onto the ride”… this is a scary thing.

    // A Material can be authored from the shader graph or by hand. When written by hand we need to provide an inspector.
    // Such a Material will share some properties between it various variant (shader graph variant or hand authored variant).
    // To create a such GUI, we provide Material UI Blocks, a modular API to create custom Material UI that allow
    // you to reuse HDRP pre-defined blocks and access support header toggles automatically.
    // Examples of such material UIs can be found in the classes UnlitGUI, LitGUI or LayeredLitGUI.

Very thoughtful. Would have been useful if those classes were public. But who would want to use those outside hdrp, right? What kind of person would ever want to write a plugin or an asset for hdrp?

Edit: don’t really mean to flame or rant. HDRP is great. But it sort of feels like a private party.

16

an important question :
Do the bug fixes in the latest version of URP apply to previous versions as well? For example, I want to use the unity 2019.4 LTS , which finally supports URP 7.5 . Will the bugs fixed in URP 10 also apply to URP 7.5?

17

This is going to be a very much more painful road for asset publishers now that EVERY unity version can ship with different SRP version, or if we are lucky, they don’t update it between the versions but there’s no real wording so far how they are going to message the changes from now on.

For people who haven’t followed what Unity is doing so closely: There will not be SRP package updates for future Unity versions in Package Manager, you will not be able to pick of the SRP variant like 7.3 or 7.5 there. Instead each Unity release will have it’s own SRP package shipped with it (in Unity core). Meaning if you need an update to fix a bug you are having, you have to upgrade from say 2021.1f1 to 2021.1f3 to get the SRP package they ship with that version.

This of course doesn’t make things easier for asset publishers, but the opposite (now Asset Publishers that support LTS versions have possibly like 20 different SRP versions to support, instead of like 4-5 we had in past).

18

But you couldn’t use older Untiy version with newer SRP version before as well. You would have to upgrade Unity. I guess it will be the same only now SRP in Unity core.

Main challenge should be to have only few hotfixe versions like in Unreal. So 2021.1f1, 2021.1f2, 2021.1f3 maximum.
That would make version control a lot easier.

19

It’s not the same. You can use 7.1.8, 7.2.0, 7.3.1 etc HDRP versions on pretty much all released Unity 2019.3 and 2019.4 LTS versions. 7.5 requires newer 2019.4 LTS but 2019.3 support was already expired by the time they shipped 7.5. But the main point here is that old SRP versioning wasn’t tied specific minor engine version, only limiting factor is that you had to have 7.x and 2019.3 or 2019.4 coupled together.

In the future each minor Unity engine version could potentially have different variant of HDRP or URP, making it really hard to just give support for few popular variants of it. You can’t just tell your customers to only install 2021.3.f0 or f15 specifically (or can but it won’t go that well).

For example, imagine if Unity did provide fixes to URP on every minor engine release (they won’t but it’s still theoretically possible), this would potentially mean 40 different URP versions throughout one LTS support cycle.

20

Different versions of 2019 shipped with different supported versions of URP, so that part isn’t much different. That said, closing down access to the graphics repository so we can’t easily diff changes and figure out what they are doing, that’s a kick in the teeth.