Official SRP Rendering API Survey

Is it ok to share this survey outside of this forum? I'm in the UK Games Industry slack.. we have a Unity channel that many in may want to complete the survey.

 

Starting the survey.
Thanks for hearing us out.
PS: I will share it on social media.
[EDIT] Done and also shared on my social sites.
Feel free to contact me if you need additional input or feedback.

 

This survey design is an insanely terrible.
Cmon guys, you know what we want: render with shader, proper shader fallback, multipass, acess to culling and per renderer data, feature parity for RenderTexture and RenderTargetIndetifier

 

I was able to use the Custom Pass API to easily replace those in the situations my project used them - with the former, the Custom Pass API ended up suiting my needs much better than the old RenderWithShader, too. Maybe your use cases are different than mine though (in which case it'd be better to discuss use cases than the old solution for those use cases).

 

You talk about replaceMatrial, i - about replaceShader.
And for multipass - try to create old-style shell fur or silhouette outlined material with custom pass
https://wiki.unity3d.com/index.php/Silhouette-Outlined_Diffuse

 

Thank you for making this survey.
My input was mostly complaining about SRP promoting shader graph and lacking a more programmer-friendly support for optimization and workflow reasons. Doing shaders in SRP is really slower than writing it in code tbh. I've tried porting BRP to SRP shaders and it's something really time-consuming.
* EDIT * if there are resources on SRP coding, please excuse my ignorance on the matter. I have not been able to find them.

 

@ali_mohebali,
Also we would like to have news about the public Graphics repo, the reason why it was archived/set to private and if it has something to do with new changes to SRPs?
This move by Unity really made me fear about investing more time on SRP, I have assets being ported to URP and HDRP and it requires sources changes to both renderers but I fear of wasting my time, once again.

 

Yes, my email and asked to be contacted for further questions or feedbacks.

Thankyou.

 

Been using Unity since version 2.x and I have no idea what most of the questions referred to, but I chose "No" to the question of whether I would switch to the SRP's in the future. Checkmate, I guess?

Either way, I won't use the SRP's until built-in is actually removed and replaced by the SRP's and by that time I hope you have figured out this mess.

 

Unify teams that work on SRP, put a proper abstraction layer on top and don't break everything every release ....just from the super noob user perspective. Its kinda annoying that shaders are not intersrp, keeping stuff with URP HDRP and atm built in is annoying, especially when tehre are a lot of breaking changes between versions.

 

Not strictly SRP, but not possible because of the way things are handled in SRP.
What recently I tried to do this outline effect:

Setting up one camera to be the main renderer, the base camera, and the outline to be the overlay camera.

The issue is I want my overlay camera to manipulate an independent render texture, but my understanding of the base/overlay system is that both the base camera and the overlay cameras use the same render target, so when my outline shader blurs the screen, zeros out pixels, etc, it ruins my main render.

If in future it could be possible to make a setting which allows Overlay cameras render to their own RenderTexture, rather than straight to the main camera, then to apply that render to the main camera after the pieline is done, that would be very useful to me. Maybe default the background to new Color(0,0,0,0) instead of skybox when changing the setting to stop potential issues when using independent rendering.

My current workaround is to turn the Overlay camera into a base camera with a lower render order, apply it's texture to a render texture, then apply that texture to the main camera with an "Overlay" RenderFeature which I've written myself.
Although that feels a little silly since there's already an overlay system within the engine.


All the best,
Harry.

[EDIT: It seems in working on this problem for very long I've missed something quite basic.
Instead of being a limitation of the Overlay System I may have instead found a bug in the BaseCamera system.

Since BaseCameras have priorities, if this allowed you to overlay Base Cameras in the way I'm describing without using any overlay cameras, then I retract my suggestion due to it having no purpose.

As Unity is in 2021.1.0b1 though, only one Base Camera can render to the screen at a time and that is the BaseCamera with the highest priority. It may be something just isolated to this version, I have not checked.

Seasons Greetings,
Harry]