[IMPORTANT]Asset store compatibility and SRP issues, for publishers and users in general

Basically, it would have been responsible and valuable to developers to have provided a clear answer before the 2018.1 beta release.

 

Exactly. It would have avoided this whole situation both for them and us.

 

Hello guys,
I'm the author of NGSS (Next-Gen-Soft-Shadows) asset and also wanted to chime in.
First, I have some doubts people will start to re-invent the wheel and create new renderers with SRP to the public. I think most people will simply take what's already there and customize it to their needs.
In my case, NGSS is not a simple shader that uses macros, it's a custom shadow system that requires access to renderer sources for optimal performance and visual quality. For this kind of asset to work with both (or at least HD) renderers, they need to remain modular and well structured.
So my message to asset store (specially custom shaders creators), make sure you don't touch HD/LW renderer sources, you will end up having an isolated asset on the store. Try to workout within both renderers limitations (as you did till now). If you think some X features must be added or changed on any renderer, just try to do a pull request, so everyone using it will be on the same wave length.
To Unity developers (HD/LW graphic guys), make sure all the code it's extensively well commented, structured and clearly written. I've been working with default renderer internal files for a while, most of it is undocumented, badly named and disorganized (and some unoptimized or unfinished).
Besides, I think SRP it's one of the best thing added to Unity lately, allowing users to customize more in depth the renderers or write their own custom renderer (good luck on that though) even allow community contribution it's the way forward.
Finally, I love how Unity is become more and more modular. I'm for instance not a fan of heavy engines with trizillions tools where most of them won't be used in my projects. Install what you need, write it or buy it on the store if you don't have it.
With that said, happy SRP transition.

 

Hi there,
I used your asset as an example (even if I didn't mention it by the exact name) when raising potential issues to the Unity devs. The Lightweight pipeline does not support point shadows, and one of the main features of your asset (at least one of the most attractive for most users) are precisely the soft point shadows that it adds to replace the standard (and frankly, ugly) Unity ones. That was the reason I bought it (and it is a great asset )

Using your asset as an example allowed me to raise the potential issues with the way this transition is being proposed to us, namely :

1 - What happens if 1 pipeline (Lightweight) does not support core features of our assets (which may reduce greatly its appeal to users of this pipeline and thus reduce the incentive to support it) ? Do we still HAVE to support it?
2 - What happens if 1 pipeline (HD) will already, at least as far as we know, have native and potentially better versions and support of core features of our asset? Do we still HAVE to support it?

While I also appreciate and fully support the transition to a much more modular engine (since I have always felt that the need to support the multitude of mobile devices was what held Unity back in the past), it is also very important that Unity lets us know for sure if we will need to support all 3 pipelines or if we will be able to choose.

The great appeal behind a modular engine is that what happens in one module doesn't affect the others. With that in mind, we as asset developers should not be forced to support every module, we should be given the chance to focus on the best one(s) for us and pour all our resources on producing the best possible asset for that specific pipeline(s).

Yours are excellent warnings, we as asset developers should do our best to stay inside the limits of each pipeline. Unity has to document everything ASAP if we want a smooth transition, and a good amount of freedom has to be given to asset developers to ensure that each pipeline has proper assets that are specific to their unique workflows and that truly improve them, instead of a collection of subpar, unnecessary ports from other pipeline's assets.

I've made several assets for desktop platforms due to the intensive calculations they make and their use of DX11/OpenGL Core. I would love to have the reassurance that I only need to port them to the HD pipeline once available, and not that I will need to somehow manage to make a heavily downgraded port for Lightweight (mobiles) which was never my intention and which I won't be able to support at the same level as the desktop version.

I am completely aware that the questions I have made sound very obvious, that we all would think that of course Unity will let us choose since that is the option that makes the most sense to make the best out of this new system they are developing, but sadly they haven't given us any official nor clear answer in that regard, so I have had to keep bringing all this up over and over again, until we get that answer.

Again, great asset, and completely agree with your points
Lets hope the Unity team takes to heart your recommendations.

 

Unity has responded to my main question behind this thread just a moment ago. Thanks to @AndrewAssetStore for his clear (and very needed) answer on this matter!

While there are still several issues to work out and solve, at least we now have the assurance that we can roll out support for these new pipelines at our own pace and with a good amount of freedom, which is what I am sure many of us will need.

 

@IrrSoft
Completely agree with what you said. I don't think that forcing developers to support all renderers will be a sane decision. For instance, LightWeight was invented for a reason, to be the fastest possible renderer in Unity. So I don't see the point of lets say Unity asking Volumetric lighting asset developers to support LW. It will become FW (F for fat) hence not "light" anymore.
On the other hand I think some sort of filter submission tools needs to be added to the Store Publishing Portal. For example, you will have 3 options to check whether your asset is supported by Default (current) renderer, HD renderer or LW renderer so asset store users will see clearly if the asset will work with X renderer.
To your 2nd question, If Unity ever adds similar or better shadows, I will try to beat them with new shadowing techniques in a further version. Ok jokes aside, but isn't that the main purpose of SRP and all this modularity shift Unity is doing right now? I don't think it's a good idea to re-implement popular assets that works very well on user end. I mean, as a business point of view. Unity is heading towards a super modular, super lightweight future to allow a better Asset Store and developing ecosystem.
Regards,

 

What exactly was their response?

 

Hi there,

Their reply was that they are still working to decide how to implement all this change, but that we will not be required to support all 3 pipelines.

We can decide which pipeline to support and which ones not, meanwhile they will try to make and improve tools to automate and ease the transition as much as possible for those who decide to support the new SRPs

"Scriptable Render Pipeline is the future of rendering for Unity. Though right now we're still in the early days and appreciate your feedback. While we would like folks to upgrade assets, and continue giving us feedback – support for all 3 pipelines is not required. We do expect there are assets that make sense on some pipelines but not others.

As for tools for updating projects to various pipelines, we're looking for ways to improve our workflow." from @AndrewAssetStore

You can read it in the Asset Publisher forums too, here https://forum.unity.com/threads/2018-1-beta-is-coming-get-familiar-with-srp.508513/page-2

 

There could be new filters on the Asset Store, so anyone can just select Standard (Legacy), LD le HD compatible assets - so all assets could just show up by default on the traditional pipeline unless explicitly marked by the publisher.

 

This is important, it will avoid most complains and support requests from people who could be confused as to which assets run on which pipeline. Though to really avoid any confusion, I would prefer that when publishing assets there is no pipeline selected by default, so we have to explicitly select them for every new asset. The less chance for human error there is the better.

 

Agreed. As important as chosing the Unity version which is minimum supported.

 

A forced check boxes in the Asset Store submission panel (for publishers) where you check which pipeline your Asset is compatible/set with to my eyes is kinda mandatory. For example, 4 Checkboxes (something like this):
- Legacy (current Renderers)
- HD Pipeline ( high end desktop / consoles renderer)
- LW Pipeline ( low end desktop / mobile renderer)
- Custom Pipeline (Enter the name of renderer your asset is compatible)
Special attention to the fourth checkbox, as some assets in the future may work with some custom renderer that sells in the Asset Store too.
And then users on the Asset Store will see in the compatibility section the compatible renderers before buying the asset. This will spare publishers headaches and avoid the 1 start "I don't know why the asset don't work" hate rating.

 

@Tim-C

Any chance we can get an example of a working hand written shader for SRP LD? If you install the SRP pipeline from BitBucket, it doesn't compile in the 2018 beta. If you try to use one of the examples from BitBucket to write a simple shader in the shader graph demo project, it cannot find any of the include paths. It's impossible for us to start porting our shader to SRP LD without knowing what the proper include paths are, and I've ran out of 'guesses' at what they might be. Having to try to reverse engineer this system without a single example is very annoying..

 

Isn't everything being developed in github only?

 

I think this will take a very long while, since in their original email they said they wanted us to try our assets with the standard shaders and that custom shaders would come later. Seeing that they took quite a while to reply to our questions about basic requirements, I guess that they will start the work on shader examples, documentation and everything else for custom shaders in a few months.

They made it sound like custom shaders are not really a priority nor the main focus of this beta, which is why I needed their response about if the updates were mandatory, since right now there is no way to upgrade most of my assets.

I hope though that they do bring support for custom shaders sooner to start making the upgrades.

 

Yeah, it's all in github, but what's there doesn't compile correctly under the 2018.1 beta, and trying to include files with that path structure doesn't work when you use the shader graph example project.

 

Hmmmm, I see. I just got confused because you mention BitBucket a lot, and I remember that unity used BitBucket in the past, but then they changed to github completly right?
Also, there are many versions of the SRP on github, but the latest taged one is for 2017.30b1. Would be nice if there was an update in the tags for 2018, since the master version is aways ahead.

 

Thank You