A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Universal Render Pipeline' started by Tim-C, Jul 9, 2019.
you have to write your own shader using VFACE.
Thanks, so the included Lit will not directly work for Both option
I will give it a shot, not sure how to go about it though, i hope they put up some tutorials on this
does not seem to find the VFACE in LWRP
I add float facing : VFACE; in my varying struct and get
invalid vs_4_0 output semantic 'VFACE' error
Also tried uint facing :SV_IsFrontFace; and still same
VFACE is not an output of the vertex shader...
this is how you have to declare the fragment function:
half4 LitPassFragment(VertexOutput input, half facing : VFACE) : SV_Targetthat is all you have to do. then you can access it using facing.
That worked !!!
Thank you so much
you are welcome.
omg – lwrp and urp are totally broken on older macs?
i am using macOS El Capitan (Metal 56,6 and OpenGL 12.1.0) and additional lights (spot lights) just go crazy: They randomly vanish and shadows render or do not render at all.
Is that is what universal means?
Which model of mac is it?
My old macs are dead, so I cannot add knowledge to this situation. I do remember that metal with unity on macos improved a lot via major macos version updates for some years, and had quite a few bugs or issues in earlier versions. But at the time my focus was on compute shaders, which are not relevant to LWRP/URP, so this might not matter.
Do you get exactly the same problem regardless of which graphics API you have selected?
Have you tried the same thing on a completely different machine, so know this behaviour is something to do with that mac, or could it be a broader URP issue?
Sorry for the questions, just trying to get a fuller picture.
mac book pro from mid 2014
yeah, both metal and open gl core errors compared to win 10 and dx11.
Has anybody experienced the bug of creating assetbundles with URP with latest Unity 2019.3.0b7?
Please see this bug report:
I have tested and have the same result.
If it wasn't for my 1-2 years of experience in Unity and C# and scariness of C++ and learning a new engine, I'll be there by now. I'll stick to Unity until my current project is finished, then I am gone.
Any ETA for shadowmask support?
Unite copenhagen says it's aimed for 2020.1
I was pretty shocked to learn that URP even though it says "it comes with post processing" does not actually support custom effects at all.
How long until we can write custom effects for URP post processing? What exactly is the point of post processing in URP if you cannot write custom effects and are limited by a very very small amount of them?
You're in for a lot of surprises with URP!
I believe I will be swapping to HDRP, I just need to find out if my URP shadergraphs will need a lot of work to get them working in HDRP and then I am swapping based on this
Renderpasses is kind of the way to do lite custom effect it seems.
After all you can do thing like see through frosty glasses.
What about making part of the screen have colored fog for underwater effects? So that when you go underwater the part of the screen that is underwater is fogged, while the part that is not is not fogged?
renderpass replace grabpass, right?
I haven't implemented renderpass, so I'm basically winging it. Here it is, to make glass, you have to get the content of the current drawn buffer, and read that to blur stuff, instead of blurring stuff you render the water plane and use that to apply fog and effect to any pixel behind it.
It's actually Opaue Texture which replaces grabpass, you can enable it with the pipeline setting file, then you can obtain the Opaque texture for that(just use _CameraOpaqueTexture, it's grabed from current drawn buffer after opaque objects are drawn)
Just read this in a pull request on the scriptable render pipeline GitHub...
"The deferred renderer currently lives in its own branch but will be merged into master branch soon."
And yes, this was in relation to the Universal pipeline!
Since we have all 3 pipelines at the moment I'm just wondering, will the standard Unity pipeline be deprecated at one point in favor of the universal render pipeline? Honesty, as an asset store publisher, I find the standard Unity pipeline as a good bridge for people to that download my assets after which they can switch to whatever custom pipeline they want. So far I don't like the universal pipeline as it's lacking in shader capability out of the box and I don't want to make my own custom shaders all the time as well as I don't target mobile specifically. So I stand by the fact that for me the standard unity pipeline is a good bridge for all pipelines.
Just something that's on my mind right now...
Yes, they want to deprecate standard built-in renderer at some point. They pretty much stopped adding new rendering features to the old pipeline ages ago, as far as I know, so in some ways its already deprecated in terms of engineering effort. But this sort of deprecation would have to be done very slowly, even if the new pipelines were hugely popular. And they can't really do this in the way I'm sure they originally envisioned until they are able to massively improve the adoption rates for the new pipelines. Which means adding some missing features (but probably not absolutely everything people keep asking for).
I would not like to predict timescales, I am really just talking about their original intentions, and they've already had to do things like rename Lightweight to Universal to try to keep somewhat on track with their aims.
Whatever actually happens, this is a multi-year story and in the meantime you may as well carry on regardless - if something you dont like the sound of does happen eventually then you wont be alone in the boat, many people will go through the same thing at the same time, and if this involves a big backlash then Unity will have to at least tweak their plans and do something meaningful about some of the complaints.
I would say that's a pretty good answer, thanks for that! Problem is, I'd have to invest a lot of time yet again in rethinking my workflow and remaking everything for the new pipelines this time but I do want to use a universal pipeline if possible. I would like it if Unity does keep the standard pipeline until the universal pipeline is good enough to be used actually "universally" I'm not really invested in it as a content creator.
Edit: Well, my concern is pretty obvious, it has to do with my target audience/ graphics and aesthetic level I'm aiming for. I don't make stuff for mobile but my target would be mobile and high end as well so what does that mean? That in my case I have to consider HDRP as the universal pipeline I guess? This is why I'm not sold on the LW being labeled as the universal pipeline you see.
By changing the name of LWRP to UNIVERSAL Render Pipeline they stated clearly that this will be the future standard render pipeline in Unity, both for desktop and mobile, being the current built-in renderers deprecated.
They stated so in the oficial unity blog when they changed the name.
That's what a lot of people don't like (me included): as long as it was an add-on package for Unity, everything was fine with us. But as soon as they made URP the next default, the lack of feature parity with the current built-in renderers became blatant. -EDIT: and the lack of compatibility between renderers for content created for any of them made it much worse.
The new Scriptable Render Pipeline has gone from a highly anticipated feature to a total catastrophe in the last year, fragmenting the user base and now forcing us to switch to a render pipeline we don't want.
They call it "growing pains", but it's more like a "train wreck" actually.
The long term intent for the pipelines has always been visible.
For example, when they spoke about Scriptable Render Pipelines in May 2017, they said stuff like this:
( quotes from this forum post: #1 )
I dont have time to look back through old blog posts and conference videos, but I know that on some occasions they made it clear that built in renderers were a legacy code quagmire that they did not want to be stuck with forever.
With that in mind, the long term was pretty obvious, these packages were intended to replace the old built in render paths eventually. Obviously not everyone understood that at the time, different announcements and comments over the years will have caused different people to realise this at different moments in time.
I guess the Universal name change & announcement was one of those times, but I dont think the intent of that announcement was only to make this clear. Part of it was actually an attempt to deal with some of the negative feedback they had received - they wanted to tell us that they were broadening the scope of LWRP somewhat, to the extent that it would be suitable for more platforms and projects. They wanted to mention certain new features they were going to add to begin to improve the lack of parity with old renderers. And some of the negative feedback they got seemed to involve people being unhappy about having to choose which pipeline, so they wanted to make people think of Universal as the default in order to reduce the anxiety that the choice between LWRP and HDRP was causing for some people.
If I combine my opinion of the current state of the pipelines & tools with the negative feedback from other people that I am able to see publicly (as opposed to all the other feedback Unity get from their customers that I cannot see), then it is extremely easy for me to see why some people use dramatic language to describe the current situation as deeply unsatisfactory or some kind of disaster.
However, its also really easy for me to imagine Unity adding enough features to Universal that a good proportion of the major complaints and concerns are removed. And there is no way they will remove the old renderers before they at least get to that stage. So I cannot call this a train wreck, because nothing was announced that actually forces you to adopt one of the new pipelines right now.
So to my eyes what we are left with is not a train wreck, but rather some remaining areas of concern which Unity have not yet promised to address, and a variety of disappointments about how long it is taking for Unity to fill in some of the gaps that they have already said they are addressing.
Its not that I have no concerns or complaints, but I know that they cant complete their SRP and old renderer deprecation agenda until they make Universal more compelling. Having said that, even when the time comes and the old ways die, I know there will be some unresolved complaints. Because some of the complaints are about conceptual disagreements over very specific functionality or implementation. Some people are wedded to some ways that Unity believe have no place in their modern render pipelines. In some cases Unity will stick to their guns, and in others they will get so much overwhelming feedback (and lack of new pipeline adoption) that they will just have to have a rethink. Not about the merits of scriptable pipelines in general though - I never want to see Unity u-turn on that, and pretty much none of the major complaints or concerns people have are about the very concept of having pipelines, but rather the detail & tools provided in current specific implementations, or confusion about the additional choices people have to make in the modular Unity era. A lot of it really is growing pains and immature systems, but these are still plenty severe problems (not justifications/excuses) especially if they drag on for too many years (which clearly they've already shown every sign of doing)
i has been said several times (officially) that the built in standard pipeline will stay for a while and that it will not be deprecated soon.
i would read this as 2 – 3 years.
but this is just my guessing based upon the following observations:
urp still lacks point light shadows, all kind light cookies, bakes shadowmasks, box projected reflection probes, custom image effects...
the standard command buffer functionality still is not entirely adopted as well.
the deferred urp renderer seems to come soon, but probably to preview first.
so it might be at least one more year before urp is feature pair.
but if you can go wide and support urp, hdrp and built in – why not?
it is definitely some more work, so always flag urp/hdrp as preview...
The built-in renderer and GameObjects and other non-DOTS stuff, is called "old Unity" now.
While Universal Render Pipeline is currently not the default render pipeline, we do plan on making it the default render pipeline once we have a feature set we're confident about. To help inform us on what features are most important please vote on our public roadmap.
Universal becoming default is different than built-in being deprecated. And deprecation is different from removal – as an example, our Legacy Deferred Lighting Rendering Path which we marked as deprecated with the release of Unity 5.0 and is still around. We were trying to get it removed during the 2019 cycle – which would have left 2018 LTS as the last supported one, and made for a 6 year span from being named deprecated to actually no longer in engine. But that was lower priority to do than other work, so it lives for another day.
I can't say that built-in will follow the exact same path though, our goal is to make this transition as painless as we can. To that end we still have work to do in addition to our feature set – like improving our upgrade path, and upgrade documentation.
What are Motion Vectors ? Where are they used ?
Per object/pixel motion blur is the most common use case but there are others.
Also, in Unity language, deprecated means anything, from "WHY ARE YOU USING THAT?", to "yeah of course use that one, it's faster than our non deprecated solution".
And you have been historically bad at providing upgrade paths for anything non trivial.
In short, I'd better be done with what I'm doing with Unity by the time you decide to transition to that stuff, because it won't be pretty and I don't to go through another horrible upgrade experience again.
Are Motion Vectors in HDRP ?
Yes. You can enable them in built in if you want them too.
That sums up pretty acurately my feelings about the whole situation.
That's basically what I mean by "sitcom lighting", silver bullet that kill edge cases and make everything look the same based on an arbitrary metrics. It's paternalistic when they don't understand the nuances of implementation vs concept (see "no plan for surface like", "no plan for multi pass" and horrible limited shadergraph).
i came across this:
That tweeter thread is SPOT ON on EVERYTHING.
I have been a Unity Pro user since Unity 3 and a huge Unity fanboy too.
I recommended Unity to everyone that asked for advise.
Today, I'm very seriously thinking of switching to Unreal Engine and I just can't recommend Unity to anyone anymore.
Everything went downhill when they hired the ex CEO of Electronic Arts as the new Unity CEO.
I don't recognise Unity anymore.
This is how I feel too. SRP was the most interesting feature I've waited for. But after working with LWRP for the last 6 months I can't say anything good about it. Also the fact that LWRP assets are not compatible with HDRP is quite scary.
Indeed. As stated in the tweeter thread: UNITY LACKS UNITY
ETA on Ambient Occlusion with URP?
We can thank the package system and each team lazily and independently over-engineering their systems.
Any news on the custom FX in URP?
Any news on custom FX in URP?
Any news at all??
From that "vote for a feature" thing posted above it looks like custom FX will come in 6 months time!?!?!? I mean, what the actual ****, what are people meant to do in the meantime. URP SRP are genuinely a joke at this point.
Taking a look at the SRP pull requests it looks like everyone on the LW SRP team is getting ready for 2019.3 (non-beta) and 2020.1 - Camera Stacking is going through the merge process right now. The recent features on the deferred renderer branch look good too, though I don't think (from an outsider's perspective looking in) that'll be available until 2020.1
We're targeting landing custom PP for 2020.1. If you need custom post effects your options are a) staying on 2019.2 or an earlier version or b) look into moving over to custom renderers/render passes for similar functionality (which does require rework).
And, yes, Camera stacking is targeting 2020.1.
How is concept of a custom render pass not at the core of the new render pipeline?! Everything core included should be a pass. This way its modular from the get go that way adding and getting snapshots of the buffer as step n would just be a default thing.
Lets not even think about the convoluted Ui of this and the convoluted new Render pass feature template file.
You had a good API before hand, needed some upkeep for docs and use of Custom Buffer.
But the newest URp HDRPRP LWPPRD what ever its called now brings a hostility to its basic task that is control of a necessary pipeline.
I'm gonna stray here a bit, but its related to trying to use these new render tools that I wasted a good week learning cause sure its looked neat and powerful to use the new tools, but im just gonna revert to basic render pipeline and cg shaders cause its just works and I can some what control it better.
You can't be referring to a non paid users video post as a document of your features (from a post above ) just cause you lack the time to produce said documentation. Put someone on docs duty per day for 2 hours and rotate for the week. Sure its not fun, but its crucial. Apple Xcode is worse for new docs of new features so you are doing better I guessssss.....
Build SMALL digestible examples, and thus small asset folders we can import with out a: waiting 10+ mins to load in, and b: little to no dependencies and no convoluted mini apps that obfuscate the core feature task. This one is ebbing on complicated https://github.com/Unity-Technologies/UniversalRenderingExamples
Its got a lot going in the full set of files. The 3d models and textures are unnessasary to just dig in and find the core parts of the elements.
Also can you put at the top of script files at the very least a summary of what it does or what it was used for? Example that project has a Blit class. But the use of Blit is also a core function so I dont know as a new user a what this is and b if I do later on if this file is not a core file since it has naming ambiguity with Graphics.Blit
I type this right now having found out after building and testing the various platform versions (lwrp pp2 native hdrpwp ...) and building a full shader with the new graph shader tool I am just having to convert everything back to classic CG shaders and the older render system to get any real controllable work done.
This way I dont have to stray to far when I need to port over to ios and such. And also this way I can once again use common design patterns.
Also having all of these different naming schemes makes searching a chore of time. I have to type in both 3, 4? different terms for googles and forums search to dig up info and tests. Anytime I need a shader "cg shader" does the job, hlsl sometimes.
I love the unity teams internal gumption to making new things and wild new ways to make them. But as a company you REEEEALLY need to use your own app for a few months to make a game or two and not have access to the core base to change anything.
You need to really feel what paying customers and building dev teams are working through with each basic feature and work flow.
As a single dev its fine to write native and feels soooo much nicer to just build the metal. But in a company setting a solid app that has its basics down and is simple to onboard a new recruit is crucial.
They better not remove the built-in renderers because this whole Scriptable Render Pipeline is a train wreck.