With the release of 2019.3 just around the corner, and 2020.1 in alpha, I’m at a crossroads with my project where I’ll need to make a decision soon about the future of my project. I’m hoping that Unity could provide some additional guidance to developers like me on what my realistic options are. (Perhaps @Remy_Unity or @SebLagarde could provide some direction here?)
My project uses HDRP along with Enlighten for Realtime GI. 2019.3 will be the last Unity version to support Enlighten if I want to keep using HDRP. But HDRP isn’t “done” yet, despite coming out of preview, and there are plenty of features I was hoping to see that won’t be included in the 2019.3 version of HDRP.
It seems like I have the following options for my project, and I was hoping someone could tell me if there is another option I’m overlooking that’s better than the following compromises.
Abandon Realtime GI - This is probably the most straightforward choice, as it’s the main constraint. But it has a major impact on the visuals in my project, on par with many different HDRP features. Even something as simple as a swaying light looks dramatically different with Realtime GI, and it’s hard to me to give this up. But this approach would allow me to continue on to 2020.1 with HDRP, and not be version-locked to 2019.3.
Abandon HDRP for the built-in pipeline - This approach would allow me to keep using Realtime GI, at the expense of pretty much everything else. None of HDRP’s advanced, no Shader Graph, no Visual Effects Graph.
Switch to URP - This is effectively the same as abandoning Realtime GI, since URL already doesn’t support it. This so this worse than the first option, as it means losing Realtime GI, along with downgrading from HDRP to URP.
Manually modify HDRP package - As new features are added to HDRP under the 2020 cycle, I could view the changes on GitHub, and try to apply bug fixes or other features to the final version of HDRP that works under 2019.3. This sounds pretty hard, depending on the changes/feature, but it means that if the HDRP team can’t back-port a given fix, there’s some small chance I could manually apply it to the 7.X HDRP stream locally.
Stick with Unity 2019.3/4, and HDRP 7.X - This is the default choice, where I get to keep Realtime GI, but I lose out on HDRP improvements. This might end up being okay, though I don’t know how much back-porting will occur with HDRP functionality. I’ve been on HDRP for a year now, waiting for it to stabilize, and it just seems unfortunately to have to forego HDRP improvements in 2020.1 and beyond because of the Enlighten issue.
Ultimately, it seems like some pretty major trade-offs here, whichever way I go. Either I lose Realtime GI, or I lose HDPR improvements. Do I have any other options than what I’ve outlined here? I’m planning on releasing my game in about a year, so I don’t really have the option to wait until 2021.X to see if Unity’s Enlighten replacement is ready.
Thanks, I added that as my default option to the list. That’s most likely what I’ll end up doing, but that means potentially/likely no HDRP improvements moving forward, which seems pretty bad.
I mostly agree. This project is coming up on two years old now, and I really don’t want to have to up-end everything to rework the graphics at this point. Writing off enlighten right now is a shame.
The current situation is really unfortunate. Several different systems within Unity are competing, and are incompatible with each other (e.g. post processing V2 is incompatible with HDRP since a couple of releases; you have to use the HDRP post processing instead. The editor won’t even give you a warning about it). In my short period of trying out lighting, it happened to me a lot that I changed a setting - and nothing happened. Bad luck, that setting belongs to another pipeline you’re not using, or is outright unsupported.
The enlighten issue only adds insult to injury. What Unity needs is a uniform configuration for lighting and post processing which can be understood and picked up by any chosen render pipeline, at least for the built-in ones (default, URP, HDRP). Features limited to either pipeline should be marked as such, and settings exclusive to other pipelines should not even be visible. HDRP not supporting terrains and foliage is another thing that bugs me greatly.
As the OP stated, Unity is forcing us to make trade-offs in areas where there really should not be any (built-in renderer is stable and supports all features, but too bad, no shader graph or VFX graph…).
I would stick with the latest Unity/HDRP version that supports Enlighten. It hurts to miss out on upcoming fixes & features, but at least it will provide some continuity which is crucial in the final phases of a project. Upgrading projects to newer releases of Unity has proven to be… problematic… in the past, even before the render pipeline confusion and Enlighten.
Hi, Some information that may (or not) help you to take a decision
There is no new feature on builtin. i.e what is available currently stay and remain.
We don’t backport feature to 2019.3 LTS for HDRP. We do backport fix (if they make sense). So current package 7.1.6 contain all the feature for the 2019.3 LTS version.
Enlighten is indeed a no go in SRP land
No development or fix are plan for Enlighten. New project created with HDRP for 2019.3 don’t support Enlighten, only project created with older version have access to it (or if you change the code).
So only way to use HDRP with Enlighten is to stay on 2019.3 LTS and package 7.1.6 (and above fix package) from a previously created project
Backporting feature yourself from 2020 to 2019.3 can quickly become a nightmare (change dependencies mean that to take a particular feature you need the previous particular feature that it rely on) and may not compile if it rely on a C++ change.
Realtime GI remplacement working on all platform will come very late, my advise is to not rely on it for 2020. In particular if you plan to ship in 2020.
So that leaves a whole year without any realtime GI solution, right? And will this new solution work accross low and high end devices, like Enlighten? For anyone creating game to ship in 2021 and beyond, the information is really important.
Just for clarity’s sake … when you say “will come very late” and advise not to rely on it for 2020, that could mean a lot of different things. It could mean you expect it to come by 2021, but maybe 2020. Or you could be telling us perhaps years later … or even … there is no stable eta at all, and we shouldnt even expect it years from now.
Any chance you can let us know how to understand that statement, besides “dont expect this in 2020”?
My tentative presumption is not to expect anything production ready in 2020, but I think there is a chance we could get preview releases, only working on a few specific platforms, in 2020. Just a guesstimate though!
If I believed UT was going to throw as many devs as needed to make this happen, maybe I would believe production ready could happen. But its one of a million different big things being built at once, so … probably, no one should expect it to be ready, until its ready. Besides that, just hope for the best, or as you said … okay enough to work with.
I hate to say it, but my view of Unity at this point is a company that has bitten off far more than it can chew at once, and is still stuffing stuff into its mouth while acting like it can handle it all gracefully. Great work is done … but nothing should really be expected until its ready right now. I can’t help but get the feeling that someone high up got the idea to making Unity appeal to an audience(s) that it wasn’t right for, and then gave the go-ahead to try to build/change/fix every single part at once so the marketing could begin … /sigh.
One of the benefits of using HDRP is that you can use up to 24 lights per tile (tiles are small subdivisions of your screen) so it is often possible to add a light entity to simulate a realtime bounce for a specific effect (the ones you really want to keep).
This adds some manual work but at the same time not using enlighten removes the need for some of the precomputations and assets setup so you also get some time back.
Thanks. I’ll experiment with that a bit. A user in another thread suggested using two sets of baked lightmaps (one for bright light, one for lights-off mode) and switching between them. That might cover my needs in terms of turning lights on/off in bulk, and maybe combined with this approach it might be close enough to meet my needs. Thank you.