Just tried a build for android and there is no banding there 
Looks very nice.
I would also be interested in a solution for shadows. Guess i have slightly below intermediate shader knowledge 
But i have not yet found a solution for shadows i am happy with.
It’s also what I’m aiming for, we’ll see what can be done here
Cool, everything is under control then. I’ll add Editor anti-banding fix in the next release.
Yeah, I’ve found a link to the package I was referring to and a guy has put that package down - Mobile Shadows | Particles/Effects | Unity Asset Store
It’s most likely because of that “customer support hell” I was talking about
That solution was even superior to what we’ve had, it had layers and inter-layer shadowing.
I will keep this request in mind, but right now I’ll focus on Sleek Render effects to make it more feature-rich so it really can rival with the Standard Post Processing Stack
Also, I guess mobile shadows will be easier and more user-friendly when the Scriptable Render Pipeline comes live
Finally got my hands on vignette, but I’m not happy with the performance yet. So I guess I’ll update just the editor andi-banding for now and the vignette will have to wait for a bit longer
Editor anti-banding patch is live. @sylon your issue should be resolved, it would be nice of you to check it
I was able to improve the performance of vignette while keeping the ease of control and the update will be coming soon. There are still some micro-optimization things that can improve the performance even further and I will continue to iterate on that. While at the same time I want to get some real-world usage feedback on vignette usability/stability.
I also exposed internal HDR Compression parameters to allow more user-based tweaking. It was there from the beginning so no performance penalties introduced there.
Just updated and the banding is gone. Thanks!
Assetstore just updated with a Vignette version! It’s the second price tear already
Nice update
Question:
I am trying to get SleekRender to work with a depth based fog effect. No luck so far; fog get’s completely destroyed.
I tried to change Script execution order, but that didn’t help.
Know a fix for this?
If you need more info, let me know
@sylon As Sleek Render is very different from what other post processing effects do (including Unity’s), it’s not compatible with them. This makes much sense because all other PP effects are generally too slow to work on mobile. Adding other “normal” post processing effects will nullify the point of this package - to increase post processing speed on mobiles, as the performance will be tied to a slowest part. Not true anymore. Sleek Render works with other effects
The only way to solve this for your case is to add a depth-based fog into Sleek Render directly This kind of feedback is exactly what I’ve been looking into while creating this package as an “open development” solution and I’m glad you’ve raised this topic here.
Also, as you’re developing for mobile, you’re most likely won’t be using the Deferred Rendering path (which is the reason for the post-processing depth-based fog to exist in the first place) and you’ll probably be better to go with a built-in Unity fog from the Lighting panel. Is there a specific reason why you need your fog to be of a post-processing nature?
We can iterate on your case specifically, you can contact me via an IM here or via the support e-mail
Cheers
I have updated the package description so it’s clear that it’s a different solution and any form of other post processing effects are not going to work in conjunction with it (update will take a bit of time as it’s the same review process as updating the functionality of the package)
For me it was obvious that using any form of other post processing effects will nullify the quality of this fast package, but this is not the first case this question rises up (it’s actually the second).
Oh is there a way in settings to disable effects? or will it be one in the future release?
It’s what I’m actually currently working on. This feature is a must, but it’s not as straightforward as it may seem because usually several effects are combined into one post-processing pass. So I ultimately will need some sort of a dynamic pipeline/shading thing that will handle changing the pipeline steps and call appropriate shader variants on it.
@MP-ul Do you experience any performance issues?
I did not test it yet, i will let you know after I test it!
I have taken some time for deep profiling of internal shaders and it turned out that all of the blur, bloom, vignette and other steps cost almost nothing compared to a full-screen luma color grading (which I believed to be an almost free operation). I trusted a more experienced guy on this, everything was as explained up to the last line of code. So I will surely take some measures.
Hi @Kumo-Kairo
Your asset looks promising, could you give us a little more details on how exactly this is so different than other post processing solutions? Because it seems every PP asset seems to display the better promising FPS numbers but all generally have similar performance in the end, (From our experience).
Also do you have any screenshots of the UI, etc. ?
Thanks.
@o1o101 Hi! I have a few comparison screenshots in the header post, it has fps couners on a bloom effect.
What is different in my case is that it doesn’t use any of the slow unity’s APIs that are not flexible enough-
No “OnRenderImage” or “Graphics.Blit” directly. It uses a custom render passes and does most of its work on downsampled textures. For example, two-pass blurring is done on a tiny 32x128 texture and these two passes take around 6.000 GPU cycles. As a reference - rendering a 3k polygon model with two textures that is taking about 30% of the screen will take around 4.000.000 cycles. And rendering a simple plain that takes around 80% of the screen with a standard Unity shader will take around 40.000.000 cycles (sick!)
Right now the most expensive step is a pixel-by-pixel color grading (luma based color overlay), it’s taking about 7.000.000 cycles just for luma calculations.
And there are still things that can drastically improve performance on older devices like master downscaling (works very well on hi-rez devices that are not very powerful), I’m just gathering some real-world use cases to create an automatic downscaler that knows which devices need this and which do not.
I’m not the first one to do this by the way, there’s an old post Post Process Mobile Performance : Alternatives To Graphics.Blit , OnRenderImage ? where the guy uses a similar approach and is getting 60 fps bloom on an S2 phone.
And what I’m doing is very similar to what graphics guys from https://play.google.com/store/apps/details?id=com.creativemobile.nns&hl=en did. They have a full post-processing stack made in Unity that works on mobile and doesn’t slow them down to a halt (they even did a real motion blur and a radial blur that are also very fast).
And these things usually pop up from time to time on forums, but no one has made a drag-n-drop solution to my surprise. Which is why I decided to step in.
As for “they look promising but have similar performance” you can ask a few people that use it already, like @TylerCode for whom this proved to be a deal-changer. We managed to get it running with all effects on the oldest tablet on pretty stable and high framerate. It also proved to be more consistent because it worked and looked exactly the same on all devices, where the standard post-processing stack turned green on a few of them.
One downside of this approach is that it’s not compatible with any other post processing effects that use OnRenderImage for example because it’s so much different. But right now I don’t see a big problem with this because OnRenderImage-based PP effects are usually too slow to be added in a mobile game any way.
@o1o101 what do you think of an in-depth video explaining the differences between this Sleek Render approach and a common approach in Unity? What will help to assure you (and other people) that this really works?
I will post a screenshot of the UI in package screenshots, thanks for pointing this out
This is how GUI of settings look like right now.
I will make it look more like Standard Post Processing stack with an ability to turn separate features on/off to provide even more performance boost if you don’t need some effects.
Well for me the 0.3 works okay!
@Kumo-Kairo Thanks for the in depth response, you earned my purchase!
I noticed an issue regarding what appears to be something to do with clipping plains, I can’t exactly describe it but it seems to cause some odd rendering and flickering.
Also, it seems to work fine along side Amplify Color, is this not meant to work this way?
Lastly, it really important for me to be able to any of the the effects I do not need, eg. Color Overlay (Which you mentioned was eating performance compared to other effects, or is that something else?)
Other than that everything is working good, nice work!
Looking forward to some new effects!
Is tone mapping an option, how heavy would this be?
Thank you for your support
Yes, this is currently in process, you can always check the open development trello board to see what I’m working with right now Trello
This is a common issue with bloom as it usually flickers a lot. I have this anti-flicker feature already in my roadmap, so stay tuned. (Standard Post Processing stack also has this issue and clicking a “reduce flicker” checkbox sometimes even increases that artifact in certain cases)
Amplify Color - this is interesting, I think I’ll get to you in IM to get more info, maybe there IS a way to make it work with all the other post-processors just for the sake of user experience and consistency (if it’s working with Amplify Color)
About tone mapping - I have a unique idea on this, never seen anyone implement that before. But it may be because its performance is not acceptable anyway But LUT tonemapping will always be many times more expensive than Color Overlay I already have because Color Overlay is already almost as simple and as fast as it can get. I may win another clock cycle or two in a fragment shader (which will take down the total cycle count by about a million on most devices), but that’s it. Tone Mapping will always incur dependent texture reads, even if it’s done on a lower resolution so it’s most likely won’t be an option on lower end devices like my ZTE V811 or Asus ME173X, but again, we will see once I implement that and check how it performs on those devices.
This is interesting, i will definitely be purchasing this soon to use in my project. Initially thought of using FxPro but after some experiments i have found it to be impacting performance.
Hi there! Very curious as to where you get some of your info from regarding Post-Pro on mobile, particularly regarding the use of OnRenderImage and Graphics.Blit. In my experience, I have never had a user report any issues on mobile with a correctly optimized Graphics.Blit/OnRenderImage shader, and unless your special method is full-screen triangle rendering, there really shouldn’t be anything different going on under the hood.
Also, without using OnRenderImage, I assume this plugin doesn’t work in scene view?
How do you mean tone mapping will always incur dependent texture reads? If you are combining your effects correctly, the tonemap should simply be an ALU operation right at the end of your HDR pipeline.
