My experience and thoughts on HDRP since its release.

THx @hippocoder for the explanation.
Yes, my default Volume settings are like your screenshot.

In the hierarchy, the "Reflection Probe Main" game object is making the reflections.
Since this probe is in a general fix position, the reflection will never much with the sphere game object.
So I need to take out the sun from the reflection as you mention.
And at that point, I get lost looking for cubemaps or skybox: I do not understand where this skybox is rendered or where is in the Project so I assume is a default one (so is not visible in the project). I'm also searching for this baking profile where the sun rendering can be removed. Do I need to make a new custom reflection?

 

I would like to advise that you give up completely on any sort of GI and Baked lighting solutions. After Enlighten and Progressive they are still not production ready for anything. I have learned that despite what they show do not raise your hopes up.

I myself have completely left the Lightmapping world and am very pleased with the quality that I have in real time.
Lightmapping showed promising results in the early stages of Progressive but then it just went to the dogs now that I tried using it-maybe I stuffed up somewhere but even with high scaled uv2 the baked results still look so blocky and buggy, light leaks in gaps etc.

AO was the main reason I needed lightmaps and have a look at Amplify Occlusions latest update and you can easily see why Ground Truth AO beats SSAO so much that they discontinued it lol.
So now there's no reason I see to even use lightmapping unless Directionality or baking the Shadow maps is your thing.

For me AO+some good post effects and happy days!
As with any new feature especially big ones I have learned to let the community be the decider and not Unity on whether it's usable so thanks for your initial opinion.

Honestly though the book of the dead showed just how much of the processing power went into shadows, there's a lot of money there for any next generation shadow solutions. 14 MS on Shadows for 1 Directional Light in book of the dead oh my lord.

 

GI has nothing to do with the baking backend you use. It's calculated separately. I use it fine with my realtime lights and shadows.

Enlighten confuses people because if GI is on, it's in fact always used behind the scenes for it's proper purpose of rendering GI maps in realtime, regardless if you use PLM or anything else.

When people see it in options, it's a tweaked version for offline baked rendering and not the GI thing. This is because it was used as a stop gap to get a baking solution going when Beast had to be replaced.

 

I know it's separate but my comment still stands as features that are kind of useless and didn't live up to what they promised. I just stopped using both but GI specifically because all it seemed to do is add a bit of highlight to my models, of which I could achieve the same result with some good ambient lighting at no extra cost but I might be wrong it's been a long time since I touched either. Not going back lol.

 

Not sure how we've come to talk about GI in the HDRP thread, but my opinion is this:

Enlighten is pretty decent for what it was intended to do : Precomputed realtime GI. It has a lot of limitations and it's sometimes hard to work with, but it's pretty cheap at runtime and what it does is pretty great.

And the progressive lightmapper is pretty decent. I am too fairly annoyed by the lack of meaningful updates to it recently, and it's pretty slow, but you can get results out of it (with minimal hairpulling).

 

Well GI pops up in the HDRP code and release notes a lot - it's actually an improved implementation over builtin's handling of Enlighten GI in a more physically correct way.

Unity's messaging is correct but unfortunately it's not easy for people who aren't obsessed like me, to see the differences:

• Enlighten renders GI to textures. Developers at Unity have in the past referred to this as realtime lightmapping, because it technically is. But this confuses users.

• Enlighten is also (butchered) to produce shadow+lightmaps (classic lightmaps) at editor time. I can't help feeling bad on some level because I strongly suggested it back when the hunt was on to replace beast. I don't know if my voice was heard, but I still cringe a bit.

• PLM is for the shadow+lightmaps (classic lightmaps) at editor time also, but has more code we can hook into to create data for occlusion probes and other nice things. This is why it is the better choice for offline lightmaps. The GPU accelerated version probably will make things much more tolerable for tweaking and getting good results, so I expect people to return to this.

I might have made some mistakes - hopefully Unity will correct me (please always correct me, Unity staff!) so that I can give out accurate information instead of half accurate, and inferring the rest <3

 

Really? AFAIK they've made some changes to falloffs and some conversions to linear for lights (which you can do manually for non HDRP), but AFAIK it uses the same stuff we've always had in Unity. Enlighten and PLM.
I mean from the blog posts here: https://blogs.unity3d.com/2018/03/16/the-high-definition-render-pipeline-focused-on-visual-quality/

Unless something changed really recently that I'm unaware off.

I did too. But I don't feel bad. Sure the implementation was/is bad, but it was also bad that we didn't have a replacement for high density lightmapping. And it's not like we knew that they were working on a separate lightmapper (I don't even know if they were at the time).

(you should also add "at runtime, after precomputing offline", because renders GI to textures is also what offline lightmapping is )

 

I have to disagree. Enlighten may or may not be decent and I cannot say much as I have no experience with Enlighten outside of Unity, but its implementation in Unity is very poor. I say poor for the following reasons.

1. It is very slow and iteration cycles are horrible - hence the creation of PLM.
2. It requires a lot of texture and UV adjustment to get artifact free results.
3. 1 & 2 combined can make your day a living nightmare. 100m x 100m scene iteration times can take up to a week for production level grade.
   
4. light leak is just too much and the Precomputed Realtime GI which works with radiosity is very limited (no moving emmissive lights) and fails to work properly with thin objects (eg. table top or walls.).
5. all of the above (1, 2, 3 and 4) was achieved recently. It took close to 2 years after the release of Unity 5 to get where we are now - this is my opinion, but I think it started to be good enough around 2017.2-ish. It was much worse when Unity 5 was initially released.
   
6. Lighting and baked data access is very closed box - making custom input textures or using the baked textures sort of exclusive for the Enlighten pipeline only. Some things can be worked with but not enough to implement a meaningful variation of our own.
   
7. Performance, while great for GI, the use case is very specific. A small scene with static lighting with few moving parts. Outside of this scope, the whole GI implementation is just not versatile enough.

To reiterate, I cannot judge Enlighten in its entirity as my experience ends with Unity. But, the implemented Enlighten in Unity is very limited, took too long to mature and outdated at the moment.

Enlighten, if it was stable and maybe a bit faster when it was first released, I would have thought otherwise. But, it just wasn't quite there.

I love that PLM is gaining its own place and hopefully when GPU lightmapper is released, HDRP will pickup more raytrace based approach and dump Enlighten asap.

This is a link to a recent video presented at Unite Berlin:

While they don't quite say it, my guess is that they will sequentially implement AMD based raytraced solutions, starting with the GPU lightmapper, then the hybrid then the true raytrace. I could be wrong, but seems like a future proof move.

 

Everyone keeps blaming Enlighten. It's actually Unity's fault for mixing it up with the baking process and not communicating which parts are good and which parts are bad. (Enlighten is very good).

 

@jjejj87 The big problem with Unity is they have their own opinion on what's important and what is not. So you see nobody asked for these new render pipelines. Unity is leaving current major engine features 80% documented, production ready and complete. No joke they are moving onto new features before finishing their current promises and obligations in a kind of hack job. When I look at Crytek and Unreal I feel a sense of quality. What am I gonna do with a PLM system that spent over 2 years in development but is still not ready, 80% is still not ready by the way. I don't see any demo teams presenting some good use cases for it yet, the problems they encountered and how they solved them-without reverting to creating custom solutions which they seem to always revert to when there's problems. Instead they pushed ahead with book of the dead which is nothing more than eye candy and not practical at all for a game since it barely scrapes 30 fps with no characters, enemies or ai etc.

@hippocoder Yes exactly so and because of my past negative experiences and financial loss with Unity they have lost my faith for any new major feature as they are always not as advertised and always not production ready (anecdotal).

-I have more faith in Crytek and Epic Games because they are a game company so you know when they show a feature there are no questions, it's being used in their games and that's very admirable. I barely found a single bug using their engines and I can only say this is only possible because they use the software they are making so bugs and problems rarely get to their users. Their Q & A team kudos to them.

-The Unity demo team is the closest example we have of them having their own game studio but sadly as you can see you hear many times those teams have produced their own versions of key features like shadows and lighting for the Blacksmith, Fog/Area Lights for Adam and Atmospheric Scattering for The book of the dead demo. These are very key features and only proves their own in house demo team finds their current engine capability limited which Unity should take note of and learn from.

-I find the idea of the new render pipelines a complete waste of time and resources, the reason being because there was never a need to change the current system. In my experience of using a fairly old video card on purpose I find the vanilla engine contains many features to optimize the engine to produce AAA quality every time as long as you are willing to explore and use some imagination you can get very far.

Final Note:
Currently my experience with real time and asset store features have made me a very happy man.
Q and A and start making games with your own engine, nuff said.

 

But the people doing this stuff are the AAA developers. They are the same people who worked on all those top games... Those people now work at Unity, so in effect, Unity is an AAA games company that has shipped a lot of AAA titles.

It doesn't help doing your own games when:

• Studios (AAA etc) only have 1 game to make at a time, they modify the engine per game so there are no problems
• Unity (and UE4 and Cryengine) suffer because their feature has to work on any of the 100,000+ games not 1

So it's a small miracle anything is even functioning with any sort of flexibility since the intended purpose can be anyone's game.... not 1 studio's game. Unity making their own games means it works with 1 game. Not yours. Not mine... so it's a way harder problem.

When Unity try to solve that issue they are complained at because SRP gives you freedom to tailor the engine to the game like big studios do to escape the problem... I am not saying Unity is perfect but I'm thinking that it's certainly not as easy as a company making their own games cos their own games != our own games, and that's not a problem AAA studios face (they make one game at a time).

 

I agree with most of what you said, but I cannot say that the new pipelines are something that nobody asked for. I think it is the right move and the correct move and most likely will evolve into a giant over time.

I also have mixed feelings about Unity not making games, and partly feel the same. The 3d Game Kit they released was just disappointing in many ways. Nevertheless, my big issue with the Demo team is that they promote the demos as a "Unity Demo" when in actuality it is not. They use way too much third party stuff that are either not supported properly (eg. atmospheric scatter on Blacksmith) or just closed off (light occuluders for Forest demo).

Either way, since the release of LTS, I don't really have issues with Unity pushing forward. I see it as their endeavour to stay relevant, hence making the games I make relevant.

 

@hippocoder

There is a point in a products development cycle where It wouldn't matter how good their developers if the result of the software is so bloated there's not much they could do without a whole restructure.

The whole basis of my arguments comes down to Unity making bad decisions which result in unnecessary consequences and bugs as a side effect.

Why not hire small indie teams to see first hand their use of the software, best practices and feedback?

Why not dedicate massive resources to proof all their current features?
Current features need to be completed first before taking on newer ones.
Counter opinions should be taken highly before introducing new features.

In fact I want to redefine all of this away from bugs because those are indirect consequences of larger root causes.

I myself had a big headache with the new graphics tier stuff. It's not documented properly and google only takes me to the old ways of changing from deferred to forward etc.
When I changed it there was no change and contacted a developer saying bug? He was stumped and so was I.

It turns out there is a separate tab that also needs to be ticked in Edit>Graphic Emulation....why? The better decision making would be to add a "Use this Tier" check box in the Edit>Quality>Graphics area next to all the other same features. It's a very clean decision.

So a simple choice to make cleaner decisions result in saving a lot of time and headache.

Clean, predictable, 99% bug free or higher software is possible and with growing complexity of a software must come smarter more lean decision making. Blender and Zbrush are very powerful examples compared to other Industry apps. They wipe the floor with them in almost every way for example 1-2 sec launch times. Unity just kept getting slower launch times with each revision from 4.6 which was instant to Unity 5 which is like 10 sec lol. So many useless features added which should have been optional modules.

I might even go as far as to say the real time GI should be one module and the Baked GI should also be another module. Having most major features being modules would make bug catching very easy too. You can just download the module, test it and if it doesn't work you get rid of it.
No need to download another engine installer or whatever.

It looks like Unity is already going in that direction because the package manager introduces the new render pipelines as modules now pretty much. A very wise choice.
I still don't want all that Unity collab and AR, VR stuff in my project if I don't intend to use the engine for those stuff. They should all be modules that would be awesome!

So why can I come up with these win win decisions but their army of 1 million strong developers won't....

 

6 months later, any updates on your thoughts? How are things developing? Do you think 2019.1 will be a point where Indie teams can start using these new features in commercial production?

 

It's really too early to tell how 2019.1 / 5.x HDRP will turn out, we need to get closer to 2019.1 release to be wiser on this (probably early next spring).

They have changed a lot of things from 4.x.x SRPs and even while I type this, they are making big changes for the master. With big changes a lot of things may break (despite HDRP teams extensive automated testing). I guess it also boils down on what you need. Right now afaik HDRP doesn't quite scale down well, so it's a big limiting factor for commercial productions unless you target some fixed hardware platform only.

They are swapping the PP on HDRP any moment now as well, old PP stack v2 will not work anymore and we get HDRP specific PP from now forwards (and no info given how people can author custom PP to the new solution yet, or any timeframe for such extensions if being even possible). VR support is changing, afaik it's going to be SPI only and this combined with the new PP change breaks pretty much all PP on VR (but I'm sure they'll fix that).

How long these all things take to mature is unknown right now. SebLagarde wrote recently that their current target to get HDRP out of preview is around 2019.3. Considering that target has already shifted a lot in past, I'd expect non-preview version around 2020.

 

The official release is planned for 2019.3.
@SebLagarde mentioned that the API would be less likely to change from 2019.2 in another post. So I speak for myself when I say that I am using HDRP right now for my project in development, and yes, I accept that I do have to change things often.

For example I predict I will change all of my post effect stack sometime in the 2019.x cycle as it will be re-written for HDRP and there will be occasional API/visual changes/bugs/performance issues

 

It really depends on how you plan your project. HDRP, in my opinion, has been rock solid for quite some time, and the bugs that come with it, also happens with normal Unity(unity bug + third party asset bugs). So really, unless one sticks to one unity version from the beginning and plans on sticking to it throughout the development cycle, there isn't really that much of extra work one has to put it because of HDRP. Problems with authoring tools and game engines are something that any developer has to get used to.

As for whether HDRP is good for a commercial project, then the story changes a bit.
1) It is not battle tested. It is still in development as a preview package.
2) It will be changing its API and I expect this to happen until mid 2019-ish.
3) Barely any third party asset support

But, projects take a long time to finish, and I am personally using HDRP with the following conditions

1) Q2 2020 or later release window.
2) Graphics assets are not worked on heavily - just one type of each for design. I have scheduled mid 2019 for graphics work.
3) Work on render pipeline independant things first.

With the above conditions, I have found HDRP to be more than satisfying.

As for the progress in HDRP, I am generally happy with the way it is going. But there are some things that worry me.

1) HDRP also includes VR, which in my personal opinion, a mistake. HDRP should really just be HDRP, there should be a separate RP template like VRRP. All the required optimizations related to VR rendering is not really needed for desktop or console renderering and I feel like it should have been a separate RP from the beginning.

2) HDRP roadmap is not stated nor clearly communicated. It is pretty much just "best renderer for high-end gaming". But not much information is shared until there is information to share. For example, raytracing for HDRP is WIP, but was not announced to us. Don't get me wrong, I am not complaining or saying that HDRP shouldn't support raytracing. It is just that I feel if they shared the roadmap for HDRP, it would have helped. Even if it is a vague one. It is quite hard to measure what HDRP will be 2 years later. Will it be an ongoing platform aimed at best graphics? Will it stop at some point and announce HDRP 2? and so on.

There are some extra information if anyone is interested. I gathered the following information from the HDRP code and github pull requests. Sort of hacking for information.

1. ECS based scene management and rendering will boost editor and in game performance. This will make large scene editing very comfortable. I expect this feature to arrive and stabilize around Q4 2019

2. Raytracing based reflections - I have not seen any GI related information - is on the horizon. The extent of the development and information is not available. No ETA dates either. It is not announced yet. The link is a pull request, so it may not be available soon (when it is closed)
https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/2622

3. Post Processing Stack V3 is also in works. No ETA as well. But I expect some sort of Raytracing incorporation (AO and reflections maybe...purely my speculation FYI)

4. Visual FX is only HDRP. I am not sure if it will be available on normal Unity one day, but at the moment, this is a big plus.

5. HDRP already has big shadow improvements (contact, micro etc) and built in volumetrics.

6. Lighting workflow is getting constant upgrades, and so far, they really add a lot to the existing lighting. Not just quality or visual wise, but it allows the developer to utilize the already existing tools more efficiently. Examples here:
https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/2630
https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/2631

7. Physical camera with f-value, aperture and etc. This could make a HUGE difference to workflow. no ETA.

So overall, I recommend HDRP, but only if you know what you are doing. If you are planning to use HDRP for your first or second project, then I'd advise you against it. There is a cost related to using unfinished product and one may not be ready or skilled to work with it.

Also, It is not just HDRP, but Unity Engine, in general is evolving into a beast in every aspect. But that means there will be many things changing and bugging out for some time. In my opinion, the change will be much much bigger than when Unity 5 was first released. So expect things to go south all the time if you are thinking of choosing HDRP. I'd say HDRP will be ready for production in 2020, but before that, it will be an adventure ride. The choice is yours ultimately.

 

I couldn't disagree with this more. HDRP is supposed to be general purpose next gen rendering pipeline for Unity, it should support both low end and high end hw and VR.

There are plenty of games that implement both traditional display desktop/console and VR mode both. I'm in this camp myself as I'm building a racing game with optional VR mode. Unity has also been really clear on not supporting swapping from SRP to another on the fly so having a separate VR specific SRP would be a disaster for games that are not strictly VR-only.

Also a lot of the rendering feats needed in VR are already in LWRP and HDRP. Doing additional VRRP would just mean they'd need to duplicate a lot of work to cater whole range of mobile VR and high end PC VR, probably ending up with LWVRRP and HDVRRP which would just be silly. What they do now makes more sense IMO as VR related things are just additions to existing SRPs, they don't limit you if you don't need VR in your game.

There's no ETA but this PR got already merged into hdrp-master branch. PPv3 is going to be only option for PP for 2019.1+. At current state, PPv3 doesn't do any DXR things you've mentioned (and I don't think Unity would even call DXR related things post processing). Worth noting that PPv3 isn't going to be separate package like old PP package either so these all (PPv3 and upcoming raytracing feats) will blend into main HDRP package eventually.

I seriously doubt it's ever coming to old renderer but it's coming to LWRP soon. They'll first bring compute shader version and later down the road they'll have version that has CPU fallback mode for devices that don't have compute capability.

 

Appreciate the detailed feedback, thanks

I guess the other complication, if you're starting a new project next year, is whether to target current or next-gen consoles.... rumoured to release in 2020.

 

Yeah, like a draped tablecloth over something interesting, we did something similar - it's a relatively neat solution
<3

 

Is hdrp ready for production use in 2019.1 ?

 

No, they are targeting 2019.3 for it to come out of preview. Some productions may use it anyway, but usual disclaimer about risks etc.

 

Also expect slim to no supporting materials like documentation until then.

 

My impression or are you at the limit of Unity technology and need a final product?

I use Blender 2.8b and it is full of errors. I lost many models or modifications due to crushing. And this incredible awesome Blender beta is still used.
I left Unreal as a developer. It's good to play now with the shading graph, ECS, but I think you should consider the Unity 5.6, 2017LTS pretty solid and the next 2018LTS Unity PBR for production.
I still believe that Unity 2019 should have called 2020.

 

Your suggestion creates more confusion and problems with communication than it solves, in my opinion.

Whatever is done to names, version numbers etc, there is no getting away from the fact that we are in the middle of a multi-year period of large, fundamental changes to multiple parts of Unity. This does pose problems for a variety of cases, but I dont think there is really any way around it, other than developers making the right choices for them about when to stay on an old version or older parts of Unity, and when to jump onto the bleeding edge.

 

Exactly, That's the point, there is no way around. We need to learn not to use a racecar when they are upgrading it. HDRP LTS is what we should use for development. Some people consider the latest LTS PBR rendering an old version. Up to today, there is no better and newer version than solid 2017 LTS (I think that should be called 2019 LTS). It contains a mature UI, timeline, cine machine, collaborates and a pretty stable PBR. A nice release where to make OTOY rendering... probably now thinking to migrate versus 2018.4 next LTS. I'm pretty happy that they are making that for me. And not to be complaining about the multi-year period of large, fundamental changes because as soon as they finish HDRP for you there will be real raytracing rendering pipeline(RRRP) {is a joke}
Making migrating of a game is hard. But If you are also in the middle of the bugs and changes is even harder.

 

Alan, that is what I thought and chose the 2017LTS for my already shipped game - it is available on Steam.

But, after going through the actual experience of LTS, I cannot say that HDRP LTS or any LTS is the way to for development. Sure, on paper it seems like the logical way to go. But, in reality there is a massive gap between what most people perceive as LTS and non LTS.

What I noticed with LTS.
1. There are bugs. Surprising but there are quite a few. They are mostly fixed.
2. Some bugs are chosen by Unity not to be fixed. (eg. the UI assigning massive garbage collection, I can find you the thread if you want to follow it.)
3. Some issues are not classified as bugs and will not get an update (eg. All experimental features are left as experimental)

What I noticed about the latest non LTS
1. There are bugs, not surprising. They are mostly fixed.
2. Bugs are not "chosen", they just get fixed, and if not, on the next version.
3. Issues not classified as not bugs are fixed in the future.

So at the end of the day, what ever you use, you actually end up with bugs. No matter how you want to think of LTS, that is the truth, (I mean, 2017LTS has received 23 patches and it is Q1 2019 now)

Bugs are usually fixed for the latest first, then backported, so usually LTS is the last to receive the bug fix if the bug exists in LTS and latest.

Combining all the aspects of LTS and non LTS's pros and cons, at the end of the day, you will have similar problems regardless. That is the life of development. Working with broken stuff
The only upside to LTS, is that you can maintain third party asset compatibility for sure. But at the cost of some Unity native bugs that you cannot workaround unfixed. I had to implement TextMesh Pro mid development, taking a whole week to port and doing further QA.

So, what I have realized, is to start with a non-LTS version, then keep updating it maybe a patch or two behind to be safe then, switch to LTS, when the version becomes LTS.

This way, during development, you get to keep third party asset compatibility and to an eventual stability.

Both LTS and non LTS has bugs, and is going to have bugs. Period.

The best approach is to minimize build porting time between Unity versions.

So, simply put, if you are starting your project now, then don't start with 2017LTS, that is not smart.
Start with 2018 or even 2019 alpha.

Then after six months, move onto 2019.1 full release then make your way up to 2019.LTS which will be around the Q1 of 2020.

Just make sure you are working with a .3 version or .4LTS before releasing the game.

Engine upgrades are time consuming, but is often a good thing. Just plan it in your development and allocate enough time for it. And get used to the fact that things move on, get upgrades and will always have bugs. Our games are not the only software that can have bugs. The quicker you realize it and get used to it, the more productive you will become. At least, that was the case for me.

I have seen a fellow developer going full rage mode complaining how Photoshop still crashes, Maya failing to load plugins, Substance Painter doing its own thing and etc. I mean, these software are industry standard and should not have bugs right? He then spent the rest of his day writing emails and complaint letters. Then another few days solving it. After a week, the general answer was: I am sorry, we will look into it. He repeats this process every month.

Stability and assurance is a good thing, imagine a world where everything is 100% perfect for your game and you just have to make it, but it is like a rainbow that one will never catch up. Get used to it, and just make the best decision for your project. And move on when it is done

Just my 2 cents.

 

I mean depends on the magnitude of the project and people involved. I'm just me so smaller plugins for my game are made using 2017LTS and 18. Even smaller advance prototypes are 2019 in HDRP. The big game full of store assets is actually in Unity 5 and I will migrate it to 2017LTS this year so that I can appreciate all that Unity work (patches). I love to have my console clean! Is nice to pick up the full spectrum. Also, for big scenarios give time to the player to upgrade their hardware.

Speaking off hardware, I do not know if I can use HDRP VR, a mega scene and then switch to LDRP for old hardware that will sofer the big scene. That was good in U4 and not so bad in U5 PBR.

When I try to ship using Unity 4 my game crashes each time I exit. At that point, I realise that Unity needs time for fixing bugs. 2019.LTS will be around the Q1 of 2021 with 23 patches. 2018.3 has a lot of bug fixes because is closer to .4 LTS release. Is lovely to follow HDRP evolution. Is not always possible. They try to look into the C++ PBR rendering code and decided to make a new one. HDRP with ECS try to fix some bugs that are by design (eg. the UI assigning massive garbage collection) rendering fps spikes.

When baking came out, my conclusion was: When we will be able to bake an entire big map scene probably we will be able to make a real-time rendering on a small screen. So I decided to avoid that feature unless it was an interior. For me game=realtime. I think that rendering and storing 100m x 100m or 1km x 1km is not a good idea because is like having to render a 100x100 meters screen (+-) + objects (and at low res). Unless you do it almost at the end. But rendering takes the month. If a static light is used, then I try to bake my 3d model textures with shadows inside the 3d rendering app to achieve better quality. Also, I do not back AO in Substance Painter; I try imported it or make it using rendering apps.

 

Four months later... time for another bump! How has HDRP evolved? Do you think it, and its associated features, will be ready for production come 2019.3?

 

i want to know too

 

Mate you're on the wrong bandwagon the new craze everyone's talking about now is "What regression that was fixed is going to return this time Oh boy!".

I can't test any further HDRP or LWRP iterations since my last report because If you buy stuff from the asset store HDRP/LWRP want to know your location-legend says they like to bring baseball bats.

Though I was told that HDRP was going to use a lot of resources even on basic scenes like unreal engine does; the main performance gains are supposed to be advantageous over Unity standard mainly on very large scale scenes like Book of the dead.

To fully answer your question why would you be so naive to believe the words of the Unity team?
Many of their major tech have extreme limitations even when they are complete-I would not expect HDRP to be production ready for another 1 and a half years but if I am wrong then it marks a new milestone in the level of competence by Unity but I personally don't think the little guy wins here because only a few select assets will be upgrading to HDRP so even if it's usable by 2019.3 it could take many more months just for asset store giants to all come aboard and many medium assets will probably die out due to Unity changing so fast now....

But hey that's just a theory-a factual theory-thanks for watching!

 

SilverStorm HDRP is ready to use, Of course there is still some issues and bugs, but I already use it (and I like it). Why do you need asset store anyway? HDRP alredy have all fancy features, even RTX will be there soon. If you need shaders, it can be done in Shader Graph, I personally make a couple, and I know nothing about writing shaders. And why everyone think they make the game faster, than HDRP will be ready for production?

 

1.HDRP is ready to use:
Do you have any games you've made with HDRP that I can see which demonstrate its usability?

2.Why do I need asset store anyway?
Mainly to automate many tasks that are repetitive or would take many man hours or teams to do.

3.And why everyone think they make the game faster, than HDRP will be ready for production?
Because we use the asset store and you can make games much faster with them....things like Archimatix Pro, Wet Stuff, Umotion, Microsplat, Terrain Former, Any water package, Any 3d model package.
Every game needs Dialogue System and Text Mesh Pro and there's like 200 more I could describe....

If you have a lot of money and a large team you can probably skip using the asset store but why....

 

I saved you all the effort, I did all the tests in 2019.2 for all pipelines:
https://forum.unity.com/threads/fee...n-render-pipeline.560653/page-18#post-4838966

Right now my eyes are on Lightweight pipeline since what I saw looked pretty darn good.
I will tell you right now if all my asset store essentials were supported I would be jumping ship to LWRP but right now even famous ones like Amplify Occlusion just didn't work in LWRP.

HDRP was performing abysmally for what it offered-not worth it even on a high end PC but maybe there was some secret super setting in there that could have changed the frame rate but I suppose same might be said about the other pipelines too.

My final verdict is if you must use a pipeline go for LWRP because it's important to understand the LWRP still looks good despite having no post effects on and the skybox looks foggy and ugly and i couldn't figure out how to change that. If those were fixed and some post effects that worked were applied I am sure it would even better with a lot of performance to spare.