Feedback Wanted: High Definition Render Pipeline

Is Graphine tech already built-in Unity?

 

I think it's on github, but as it's not really usable by anyone right now and there's been no announcements, I think it's best to hold judgement. Be nice if there's a response about it though.

 

jjejj87 alphas after 11 basically likes to get stuck at the opening any project HDRP or not. It some kind of linked to new file system or something.

 

I see, thank you for the information.

As for getting around the issue, I copy pasted the Assets folder from the stuck project to a backup and it worked.

 

Is 2019.2f1 totally incompatible with package manager's 6.9.1? Getting gray scene view with nothing rendered and infinite spam in the console:



Tried using a new default render pipeline asset, deleting library, using an empty scene, disabling pipeline asset render options selectively and whatnot basic stuff but this is just borked.

 

By digging really deep the chances are good for everyones use.

It s a communication thing too.

Like i said. Mine and Others projects are on hold because of no answer from Unity and Graphine for for more than 4 months.

There are several forum threads with similar problem.

We cannot talk about would be an acceptable answer.
No answer leads to searching for alternatives and solutions.

So the competition did a full virtualisation (Lightmaps too) in record time after Unity aquired Granite.
Two big projects were switching to the competition because they had have an answer and delivered.
Good read. Full readable VT implementation.
Merging //UE4/Dev-VT/ to //UE4/Dev-Rendering
https://github.com/EpicGames/UnrealEngine/commit/354796606b52dcb49ff5fdd5cfc68e2281eb9423
(Unreal source git access could be needed)

When you compare this against the VT branch from
HDRP there are some questions rising.

Biggest difference i see is that Lightmaps (custom LM s too), are not into. Hope i am wrong.
Is there any information?

 

Page 19 need some pictures. This car* is just so photogenic!

*I've been messing with some of the materials/finishes (ie gloss white rims, different paints than you can get IRL).

 

About volumetric lightning.
There is a bug when you have intense volumetric lightning next an object and the light casts shadows and the volumetric shadow dimmer is high you get artifacts when you look at the shadow.

And I also will we be able to have normal fog and volumetric lightning at the same time ?
I dont understand why its not possible to have both fog and volumetric light.

 

Ekincan actually it's possible:

 

Something went wrong in the new version (HDRP 6.9.1), in version 5.16.1 this problem is not observed ...


I can not turn it off and I do not use XR

 

What happens to the memory in the build on win 7 x64? With default rendering, the memory does not increase with time, but on HDRP it increases until it takes all that is (((

This test was done on Unity 2019.1.14f1 and HDRP 5.16.1. (Only camera in scene. If there is geometry, then the memory fills up very quickly ...

default render:
start ---------------> after an hour


HDRP:
start ---------------> after an hour


On windows 10, this is not!

 

AFAIK, there is some unclaimed garbage created every frame in HDRP at the moment. According to Github activity, this is to be addressed soon.

Hope this helps.

 

Just noticed that if you can't build using latest HDRP 6.9.1 and Unity 2019.2.1f1. Is says something about uninitialized variable in some hlsl files. 6.9.0 is ok though ! I don't have the time to fire bug reports currently, so if devs read, they might want to double check that !

 

HDRP 7.0.0 with a12,

All non read/write enabled mesh colliders cause error in built standalone. They don't spawn at all. This includes Terrain.

Also, after building a standalone, the project, once closed is no longer re openable. It gets stuck in the launcher window the next time.

I did this couple times, and so far it was replicated 100% of the time.

 

It is just me or the shadows are flickering?

Default HDRP scene... shadows flickering when rotating the camera (play mode)...
Mixed and realtime are flickering... baked is working.
Tried removing the "baking sky" script and baking the lights, also tried increasing the Directional light shadows resolution. Tried even reducing the shadow cascade to 1.

Tested with Unity 2019.2.1f1 - HDRP 6.9.0 and 6.9.1

Thanks.

 

Hi,

I have around 20 reflection probes and my level mesh is all one mesh. Is this a problem with HDRP? Should I split the mesh up?

I'd love some more information about this because I had some issues with reflection probes rendering black squares in the vicinity.

I'm using latest 6.x on 2019.2 with deferred if that makes any difference.

 

Still more issues with decals. They seems to work but now they don't respect drawing distance setting and they appear when you are like 5 units away of them !

Unity 2019.2.2f1 and HDRP 6.9.0 ( not installing 6.9.1 because it wont build with it ) !

Visible !



Not visible - 5-10 units back ! Does not respect the distance option !

 

SG will get an update soon so maybe they'll this too.

 

I wanted to publish a small game using HDRP but i got that issue with decals in 6.9.0 and i can not build with 6.9.1 because it throws these errors. Could we get a 6.9.X fix ( at least being able to build ) so we can proceed... Thanks !

Using Unity 2019.2.2f1 and HDRP 6.9.1

 

My feedback on HDRP 5.16.1 after have spent a few weeks working with it, upgrading my game from Unity 5.6 to Unity 2019.1.14f1 .

The Good :
- all the new goodies are great, the way to set up lights, double-sided shaders, SMAA, etc.
- work relatively well despite still being in preview
- faster SSAO & FAAA post-processing

The Bad :
- performance wise, for a scene with a lot of polys, 1 directional light, realtime GI, normal & mask maps, it's almost twice slower than the legacy built-in engine (not counting post-processing), for no significant visual quality gain ; this is really very bad and not what has been advertised in the Unity blog posts for the past year & half (dedicated topic here : https://forum.unity.com/threads/huge-performance-hit-with-hdrp-vs-built-in-pipeline.729416 ) ; I hope we can expect some significant optimizations for the final release...
- it doesn't work on Intel Iris on Mac (and on Windows as well ?) ; I know what some people might say : "HDRP is for high-end hardware" ; maybe, but I can downscale a lot my rendered assets to make it work on powerless GPUs, which is way better than not working at all. At this point, releasing a game on Steam with the HDRP likely means several instant negative reviews, and thus for an Indie game, a possible early death

The Ugly :
- no warning when using a SSS profile that hasn't been added to the HDRenderPipelineAsset profile list
- the initial learning curve is too steep, especially as you have to learn about the volume profile whose functionalities might be useless for your game (ie: when there's no change in overall environment and post-processing within the same scene)
- overall lack of integration with the Unity classic system, making the initial learning curve even steeper, and the general use more painful than it should be
- default Shadow Map size for the directional light is too small : it's 512, which gives subpar shadow, way less good than default built-in shadows ; it should be 2048
- FAAA is too blurry

Little request :
- it'd be nice to be able to disable the probe reflections on a material basis, like with the LWRP

 

Man, can't build with 7.0.1 either - after two hours of shader compilation it got to this !

 

Just build it again and it should go through. There's an error that the first build fails, then if you build again (It cached everything so it goes fast) and it works

 

Ok, thanks i will do. As 6.9.1 failed all the times i tried, i just gave up as soon as 7.0.1 failed the first time

 

[HDRP Reflection Probe]
Please make custom frame settings saved as scriptable object or something. Otherwise it's impossible to quickly share settings with other reflection probes. Also settings checkboxes can not be applied as prefab's modification.

 

Did anyone get the new SSAO working? I have constant flickering (or sometimes even no SSAO at all) even with the default settings... is there anything specific one has to consider?

 

You can't use it with more than one window open, so be sure to check it in play mode only with a single window for now- it should provide acceptable results. Let us know how you get on.

I suspect it's just not using the right cam/aspect/etc for the rendering with editor windows open.

Also: when reporting be sure to specifically mention version of Unity, HDRP etc

 

Quick question,

should I be using DX12 for HDRP? is there any performance benefit that DX11 loses out on?

I tried to look for answers but was not able to get any info, so I ask here. Thanks!

 

On a semi-related note to Unity:

I'd be entirely OK if HDRP production version was only supported (developer and customer side) on:

Windows 10, PS5, Xbox Next (and any other future next-gen consoles ie. Switch#2)

And thus enabled something like DX12 or Vulkan as the baseline.

Windows 7 and current-gen consoles will be EOL in 2020 (and realistically we are only going to see the mass of high-quality HDRP games coming out in 2021 considering the length of time needed for actual gamedev)
MacOS doesn't have the hardware to run HDRP games anyway,
Linux has negligible market share
Mobile was never the target of HDRP

These above platforms can be supported with URP instead.

I'm assuming this would go some way to simplify HDRP support and development? Maybe its already the case?

I'd also be entirely OK with HDRP on the *developer* side requiring a DXR-compatible graphics card (minimum 6GB), maybe to support the default lightmap baking method (probably too early on the customer side though), especially since you guys have to redesign a whole lot to replace Enlighten.


Edit: when exactly is HDRP meant to exit preview? The Unity official roadmap is very unhelpful, and I'd prefer not to have to dig through slides in keynote speeches. Edit Answer: 2019.3

 

^ I'd be totally against this

Unity has always been approachable engine, there's no need to make it some elitist setup that only few can access if they want highest fidelity renderer. Requiring DXR gpu from devs is total overkill, Unity could technically do DXR baking but that would always be optional, there's zero reasons to reduce the amount of people being able to bake lighting just because few users have GPUs that can do that faster.

Windows 7 and 8 should stay supported as long as Unity supports Win7 in general IMO, just look how long people stuck on XP in past. Many are still objecting Win10.

Also current gen consoles stay relevant for years to come, they don't just vanish once the next gen consoles appear (which aren't even on the market now so dropping support for existing gear is just frankly silly).

Do note that many have ongoing HDRP projects already, just because you don't have HDRP project that's going to release in following months doesn't mean there isn't bunch of such projects out there, just pulling the rug under all these people when they know 2019.3 is targeted release for HDRP would just be super bad.

 

Ok, want to expand on that? We're here to discuss, after all.

 

oh, I just edited the message

PS. I got RTX gpu, I just frankly feel it shouldn't be any kind of requirement to do gamedev on Unity's HDRP that you have specific gpu brand and model.

 

DXR is a Microsoft standard. AMD just doesn't have the GPUs out yet to support it (can still do so in software I believe). I'm planning to buy an AMD 5700 next, and will upgrade when their DXR variant becomes available.

Last-gen Consoles and Windows 7/8 could continue to be supported on the legacy render pipeline, as long as Unity plans to keep that around.

Its just a matter of time until a major game studio eg. EA, Activision drop support for Windows 7. I wouldn't be surprised to see it in 2020, in coordination with next-gen consoles.

I don't think statements like 'Elitism' have a place, Unity is here to make money from us, and we're here to make money from our games. HDRP development seems to be... inconsistent, at least from reading the reports here, and measures like this could prove beneficial. Its up to Unity anyway.

Tightening up developer and customer-side software and hardware requirements would be perfectly reasonable with the render pipelines being split in two. Its an opportunity for a clean start, as well.

You have a point though, doing this at the time of production-ready is perhaps too early, and HDRP is already running reasonably on current-gen consoles (looking at the Book of the Dead demo). But Unity will keep developing the engine and HDRP for many years, and could enact these requirements some time down the road.

 

Even If Unity actually supported both URP and HDRP on same project easily, without having to redo half of the art setup - which it 100% doesn't, it's not supported workflow at all, I'd still strongly disagree on this. Having PS4 and Xbox One (+ their stronger versions) and Win7 are very big requirement for people even considering HDRP today.

It also doesn't matter if you are AAA or indie for needing these today, if you make games on PC, you need to support Windows 7 unless you only plan shipping on Windows Store.

Also mind you, the support is already done for these platforms, you suggest now to remove these and waste years of hard work just to have less options? If you just pick up HDRP today, DX11 is still the most robust target for it and you'd want that to just get removed.

I really do get what you are after (it's easier to maintain simpler more focused setup) but Unity has always been more about supporting as many platforms as possible instead of sticking to few like the competition. If it were up to me, HDRP and URP would be merged and we'd have just one setup with even more options as that would bring way more power to the devs (instead of doing the opposite). This way people could just opt in to compute capable feats or pick some slimmer versions if they need to support low end devices without the overhead that full HDRP itself brings.

 

I hope unity standalone with directX12 will support Async compute. It will push the limit of HDRP on pc.

 

Yes it does, if you use an eGPU. I've done this and I've been impressed by how well HDRP & VFX Graph has worked on MacOS.

True this is not a huge platform for high end gamers, but its still important to support Unity on as many platforms as is reasonable, and also for people using mac to run Unity editor. Just because you dont see the merits in it, doesnt mean everyone else is the same.

I love DXR and have a nice windows machine for that too. I am perfectly happy with some DXR-only functionality in HDRP. But DXR-only is a terrible move and it wont happen, no chance - they havent put all the effort into cross-platform HDRP only to switch to an absurdly narrow target at this stage, no way.

 

@Rich_A DXR provides an API for queries and the likes which a GPU can be accelerated for, it cannot replace anything, the design of it is that it is not renderer-specific...

Also Unity business model is not acceptable discussion in this part of the forum at all.

 

Found the culprit: "link FOV to Physics" camera option... if checked, the weird shadow flickering begins at camera rotation.

I believe this should be addressed, because it can spread a bad feeling about HDRP, specially to beginners.

HDRP is awesome, by the way

 

Ubisoft drops Windows 7/8 support on Ultra mode for new Ghost Recon:

https://news.ubisoft.com/en-us/article/354539/ghost-recon-breakpoint-pc-specs-revealed

DX12 or Vulkan replacing DX11 for HDRP (at some point) for the editor and builds seems perfectly reasonable.

 

Yes, on some graphics setting. That's nothing new, we have plenty of games that have optional DX12 mode already. They are not dropping Win 7 for the whole game as you can clearly see from the chart you linked.

 

Even if they dropped DX11 for Windows HDRP support at some future point, they are still going to support other graphics APIs, including ones necessary for other platforms such as certain consoles, macos etc.

And they envisage supporting more platforms going forwards, not less. eg high end mobile is very much a target for HDRP. And the simplest form of stating HDRP requirements will continue to be 'paltform/graphics API must support compute shaders'. Its not going to be 'requires raytracing'. OK this point may not be true forever, if some future world has all high end targets using raytracing as standard, then HDRP can move with those times. But they wont do it stupidly early, not for example as soon as raytracing from other vendors and APIs is available.

 

Isn't however Windows 7 support dropping in january !?

 

Also the fact that we have entered a hybrid rendering era, rather than a purely raytraced one, means that lots of traditional raster stuff still needs to exist. And in various scenarios traditional methods may still need to be available as a fallback, and as a user configurable option for performance reasons. So, I dont think too many parts of HDRP could be thrown away, making development of HDRP easier for them etc. The advantages of your suggestion are crushed by the downsides, as best I can tell.

And they arent even really marketing the DXR support as being game-ready at the moment. For example in the blog post about 2019.3, they say:

This may be in part for performance reasons, but also likely because of things that havent been implemented yet as far as I recall (eg skinned mesh support).

Anyway, Unity would have been a different beast with a different history if it had not prioritised the wide array of platform support that it has over the years. And I am not against them occasionally filling in certain gaps with something that is specific to just one or a few platforms, such as DXR at this stage. But its already clear that they have already invested in and done a lot of the work in making both pipelines and light baking systems that retain the core Unity advantage of working on multiple platforms, graphics APIs and with multiple hardware vendors GPUs. It will be interesting to see what they do for their own GI solution. I can imagine them sticking with their usual ethos of wanting to make something that, if not completely platform-agnostic, comes somewhat close. I will be quite happy if they do a system that can work in both DXR and non-DXR (and other sorts of raytracing API as they become available/mature) modes, with some variation in features, quality and performance.

 

Oops part of that last message might be confusing, because DXR implementation in HDRP already has a form of GI we can try. But I was thinking of the broader Enlighten replacement solution for 2021. And there isnt much point talking about that now, not until we learn more detail about Unitys plans in this area. It is relevant though as an example of a system that Unity will want to be modern but also quite broad. To match their variety of users and those users expectations.

 

Outcome of an longer test period from 12 months possible through the open development from HDRP ob GitHub.

HDRP will get finally productive for our scenario and can shine when

- Bakery Shaders are HDRP ready
- Crest Ocean is HDRP ready
- Overcloud is HDRP ready
- Texture and Lightmap virtualisation is fully integrated
- PPV3 is customizable , DOF reachs Yebis quality, TAA reachs CTAA quality
- realtime GI replacement is available

Otherwise there is no
- productive Lightbake solution
- perfect , high quality , high performance ocean
- perfect, physical plausibel procedural hdr sky with volumetric clouds
- draw call and tex memory optimisation like possible with deprecated granite in BuiltIn RP
- higher quality Post Processing and TAA in BuiltIn
- realtime GI in combination with baked Lightmaps

Up to this point we stay in BuiltIn RP because of quality, peformance and workflow benefits.

Further preparing assets (mostly materials and textures) the way, that we can auto convert them to HDRP if requirements are reached.
Also all new geo assets already get bent normal maps and an sdf generation to allow an faster switch.

 

Does the screen-space reflection not use reprojection? It has a noticeable latency when rotating

 

I've been testing this HDRP Custom pass PR, trying to make simple gaussian blur effect with it but I struggle to figure out how this is supposed to be used when you need multipass effect (like most blurs are). Since this approach doesn't use subshaders for the main function, I apparently can't just add additional pass easily to the shader itself.

I then thought that ok, I'll just make two fullscreen passes and pass two separate materials for this but the next issue I get then is that second pass I make doesn't take first pass into account at all, I can only do either horizontal or vertical blur but not both as the source data for both seem to come from same original buffer instead of getting updated data after first blur pass.

Am I missing something obvious here? Surely they can't design this so that people can't do multipass effects as that would rule out most of complicated PP effects out. @antoinel_unity, could you give some pointers on how to approach this?

Edit: I did end up just using the LOD control for blur effect but would still be interested on the multipass thing as I'm sure there are plenty of things that require it. In case someone wonders about the LOD setup, here's the blur snippet (to be used with this PR):

Code (CSharp):

1. float _BlurSize;
2. float4 FullScreenPass(Varyings varyings) : SV_Target
3.    {
4.    float depth = LoadCameraDepth(varyings.positionCS.xy);
5.    PositionInputs posInput = GetPositionInput(varyings.positionCS.xy, _ScreenSize.zw, depth, UNITY_MATRIX_I_VP, UNITY_MATRIX_V);
6.    return float4(CustomPassSampleCameraColor(posInput.positionNDC.xy, _BlurSize), 1);
7. }

 

I have another question as well: Why is PCSS disabled on HDRP's deferred only mode? We need this mode for DXR, I'd like to use DXR mainly for reflections but I do lose the nice PCSS shadow filtering on HDRP's forward-only with it.

 

Ah I had made a silly mistake in the last example upload my standard shadows were totally rotated the wrong way and the HDRP were overblown with post effects.
Here now are the final updates of all the pipelines.

After seeing HDRP on the same playing field as the others I can confirm that it's pretty much useless as it produces the same results as all the other pipelines out of the box.

The main benefit right now is they have added better post effects and shaders. Not really worth the 300% out of the box performance cost compared to the other pipelines.

Some people claim it can handle more in more dense scenes that the other pipelines cannot, maybe that's true, we'll need more tests to be sure.

So far HDRP for me is very disappointing and a downgrade of the standard but maybe I made a mistake somewhere can someone help me out here?

I have also uploaded a HDRP with post effects.

 

@SebLagarde will 7.11 require beta 3 or has there been a slight mistake with the package file in the release/7.1.x branch?

I ask because I saw and was unsurprised by the fact that beta 3 is required for the 7.2.0 development/version bump thats now begun. But HDRP/Staging branch of 7.11 does not have that requirement in its package file, but release/7.1.x does! ( https://github.com/Unity-Technologi...render-pipelines.high-definition/package.json )

 

What you are trying to accomplish? If standard works for you -- keep at it. If you want to see how HDRP compares to Standard _for an actual game_ ... shouldn't you be testing more than just the default starter scene? Standard already has PBR ... I'm not surprised the starting scene looks very similar, and I wouldn't be surprised if they have different requirements either.

I highly suspect that Unity isn't throwing this much dev cost at a downgrade ... but if it is ... maybe post some screenshots/videos of a game with all its components working, and show the difference of the two systems under real working conditions?

[Edit -- I dont mean to sound accusing. I just don't understand what a comparison of the initial scenes is really accomplishing, short of proving if we're making a game with that level of complexity, we should use Standard ... which I guess is good to know? But not at all indicative of HDRP's usefulness.]