Sleek Render - Lightning Fast Mobile Post Processing Effects

I had bought many post processing effect assets in store, including fxpro and beautify, which claims to work in mobile (but not saying optimized), Sleek Render is the best in mobile use!
Besides, Will it have a chance to add lens flare feature in the future?

 

Just to clarify - by "lens flare" you mean "lens dirt" overlay effect? If so, it's on backlog. It's not implemented yet just because there was no demand in community. So stay tuned for later updates

Thanks for the feedback!

 

Hi. interesting asset. I want to try this asset on the consoles, so I wanted to ask if you think it will work on the consoles? Also does it work with deferred rendering path? Does the effect require HDR enabled camera? or will it also work as LDR?

Consoles can also be pretty performance hungry so I was looking for the best visual per performance buck asset.

 

Hi, @castor76. I'm afraid Sleek Render is not the best solution for consoles. It doesn't support HDR render targets (I have an interesting stiry about adding HDR support for Sleek Render, and generally it's not worth it as Unity still has bugs with HDR on certain GPU vendors on mobile in 2017.x and 5.x), so it's all plain 32bit LDR calculations. As for deferred rendering - it doesn't really matter when it comes to post processing, so it will generally work with any rendering pipeline.

With that said, I would definitely make (choose) a different solution for consoles as the performance difference in platforms is enormous. HDR support is usually a must on consoles, as well as different blurring algorithms for bloom and DoF (consoles allow more render target switches so it's possible to use different, more visually pleasing blur techniques).
And I'm not a fan of "one size fits all" solutions - every solution should depend on a platform, and, ideally, on a specific use case. So I don't think I will extend this package to be a "console oriented" solution. It will always be extended with mobiles in mind (and mobile VR in future).

Right now Prism looks quite good, and I think it's built for consoles, so it should perform better than built-in PP Stack. You can get more info from the creator (GoGoGadget) here on unity forums

 

Hi. Thanks for the info. But you will be surprised at how under powered the consoles can sometimes be, especially if the console is "mobile" I can understand what you are saying, and reason why I asked about HDR was because I do in fact want to use the asset on the LDR setting. So if the solution do actually work on the consoles, it does have its own options to be used. Having said that, it would definitely be great to have some kind of better color correction method. Just plain color overlay is ok, but way too limited for its purpose. Some kind of approximation of tonmapping like color correction or simple RGB channel mixer can really make it worth while.

 

What do you mean by "consoles" then? When people say "consoles" I usually think of PS4 or Xbox One, something like that.

LUT-based color correction would only effectively work on Vulkan / Metal capable hardware. Docs usually say about GLES3 - capable, but it's definition is very vague due to a lot of low-end devices with GLES3 for its own sake, without actual power and proper hardware pipeline performance.
So it's not really about work to be done to implement it, but more about work to be done to make it clear to the package users that other color correction techniques may only be applicable to really high-end devices.

I will definitely look into other means of color correction, including LUTs (it seems to be the most popular), but they most likely won't be so widely applicable to all sorts of low-end 2012-ish devices

 

Ok thank you

 

The lens flare I mean is something like lens halo effect. But never mind, just want to see if it's on the road map.
Thank you!

 

Oh, I see, so it's really lens flares. There's a cool technique similar to "high speed offscreen particles" (described in detail here https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch23.html) which allows to render flares at a much lower resolution, which saves a lot of bandwidth and fillrate (flares are usually very fillrate-consuming which is disastrous for mobile), and it's relatively easy done using some custom pipelining code (it's also relatively easy to hook that up to Sleek Render using downscaled precompose step). But the scope of generic lens flares goes way beyond the scope of this package as there are hundreds of different applications which depend on their rendering order, possible partial obscuring and all those sort of things that would require quite a lot of different specific solutions.

The "Lens dirt" that is on backlog is simpler than that, it's just an overlay texture that is partially masked using bloom values, so it's not what you may be looking for.

I may, however, provide general downscaled flares implementation info if you want to implement that yourself (PM me here, or drop me an e-mail for further assistance)

Cheers

 

@Kumo-Kairo you mention somewhere motion blur - is that on your roadmap? I can't see it on the Trello I don't think?

 

@adslitw Motion blur is tricky as good implementation requires custom graphics pipeline (some fake low-poly geometry needed to create more or less accurate motion vectors), so it's not really postprocessing package friendly. It also depends greatly on the setup - for example drag racing motion blur would be very different from some FPS game motion blur, and as I've said - I'm not a fan of "one size fits all" solutions unless the technique is really generic (or unless there are a few different techniques to chose from).
So it's not on the roadmap yet.
But I can provide some general advice about implementing motion blur if someone is interested. There's a guy who effectively created a radial motion blur for their highway game, implemented on top of Sleek Render (because it's pretty easy to add custom stuff to it).

 

@Kumo-Kairo understood! That would be super interesting yeah, I'd be looking to do something similar I think (not sure what a 'highway game' is!) - racing game motion blur essentially. Like vignette, but instead of a vignette it's blur! Any tips greatly appreciated.

 

This is the "highway game" that I've been shown a while back It uses Sleek Render and it also implements a custom radial blur. Looks like your case exactly.

I will add this feature to backlog as it doesn't require any custom graphics pipelining or objects shader tampering. This will most likely go into the package along with alternative blur techniques and DoF

 

You're a star @Kumo-Kairo, thanks!

 

I'd also be very interested in motion blur! Thanks a lot for the great work so far!

 

Hi, any update on this? Very interested in it.

 

Sorry I haven't been very active lately. I had to go fulltime as a contract worker to get some family budget (Sleek Render didn't prove to be profitable enough to support us yet).

But fear not, I'm still tinkering with updates in my spare time and I'm full of interest and motivation.

@hungrybelome as for approximate release dates - I will reconsider my public Trello board to also include deadlines as additional reference points for the community and as deadline anchors for myself. I will post updated info here once I will have a feature list for the following month.

 

Do you think 0.8 will be available soon? I'm looking forward to checking out the Bloom spread

 

@mdud99 yes, improved bloom features are definitely coming in the following month.

 

@mdud99 I've made some calculations and new bloom improvements are to be expected around July 6th (roughly in three weeks).

From now on I will also post relative deadlines and ETAs for the future versions of Sleek Render so it's more transparent and clear about what's currently going on. (Will be posted on the Open Trello Board https://trello.com/b/2EneJjKX/sleek-render-open-development-board)

 

Do you have motion blur capability?
I want to know if there is an additional plan.

 

@Metoong motion blur is usually very case-specific, especially for mobile.The only motion blur that is going to be implemented for sure is the radial blur (like they usually do in the highway games). But it's not a real motion blur, and most likely you are talking about a more generic one.
Implementing a more generic motion blur that works efficiently enough for mobile is only possible through working with other parts of rendering pipeline, e.g. rendering your 3D scene using greatly simplified geometry to find the pixel motion field (it's too resource consuming to render the whole scene geometry twice, although some AssetStore solutions do that). So it's a broader task than just using a simple drag-and-drop postprocessing solution as it requires additional work on art and on general rendering pipeline too.

So the broad answer is "no" - there's no motion blur yet and it's not likely there will be a drag-and-drop solution for it. It's possible to do a working solution, but it would be far from being efficient and I just can't take that responsibility of lowering overall efficiency by using a one-size-fits-all solution (which, as I've said a few times already, I'm not a fan of)

BUT Sleek Render allows to cut corners in implementing a custom effect by combining custom render pipelining code with the Sleek Render post processing framework (I'm not only talking about the SRP). And I usually give working advises of how to make things work if they are not present in Sleek Render (there are a few successful cases when people implemented custom extensions ontop of SleekRender and it greatly improved overall performance in comparison to the standard PP Stack)

 

I look forward to the radial blur and film grain effects! Also is it possible to make things gray scale using the existent color filters?

 

@TigerHix grayscale is available with Sleek Render using a Colorize effect (set color to white and effect alpha value to 1 to make it completely grayscale).
Film grain is pretty trivial to implement, I will add it in the newer version after 0.9

 

Okay, my calculations turned out to be a bit off, but I have managed to get some spare time for the project and the student intern Amir is back from his summer vacation, so things will get more stable, bear with me.

I'm also doing pretty active support through the e-mail, so if you have any package or rendering related questions - feel free to write me back.

Cheers

 

Is possible to enable blur only for some layers, using ofr example 2 cameras?

 

Sleek Render doesn't have a separate blur effect yet. You mean separate bloom?

 

I would want enable bloom only for particle objects, avoiding in ground, or interactable icons

 

Oh, I see. I will try a few things and will write back with the results by the end of the week.

 

thank you very much!

 

@pvalium okay, I tried a few things, searched a lot of info and it seems that the only real way to make selective bloom is to render the whole scene twice using different materials or hand-testing currently rendering things against the main depth buffer (which essentially requires writing custom shaders for glowing objects).
Using different hand-testing depth buffer techniques is also error prone as Unity likes to clear the buffers along the way, especially in currently available rendering pipeline - implementation depends on whether or not you use realtime shadows or other effect packages like flares or additional image effects.
Rendering the whole scene twice would most likely be just too resource-consuming.

So currently I don't really see a way to make a generic solution for this. Standard PostProcessing stack, both legacy and current, don't support that either, requiring some custom pipelining and shader logic. It really depends on a project, on which objects need to glow or bloom, whether it's the whole object or only some parts of it, whether it can be occluded by other geometry or not. Like a fighting game with glowing weapons, or a topdown shooter/slasher - one can completely omit depth testing for the weapons as they most likely won't be occluded by large objects. First-person project solution for selective glow would be very different from that top-down or fighting game.

As for your case with particles - I bet you can make it using only your particle system - glowing semi-transparent overlay for your particles (as separate or "merged" particle texture) would most likely be a good solution.

I'm eager to provide general information on custom pipeline implementation, pointing to some resources on graphics, but it's certainly something that requires an intermediate graphics programming level (I have already helped some studios that use Sleek Render implementing a few custom things for special cases).

I will let this feature sink in and maybe I will come up with or stumble on something applicable.

 

Thank you very much for complete answer.

 

What about using the stencil buffer? I'm not entirely clear on how the render pipeline works in the manner you're using it, so stencil might get cleared before you need it. But if it's usable, it could be a toggle as to whether to use stencil masking at all, and when it's on, you could set the reference and mask so it could work with (most) projects regardless of how they're already using the buffer.

 

Yes good catch, stencil is usually a viable option.
But with a few caveats on mobile - it slows even medium-performance devices considerably (it can easily eat up around 4ms just because you are using it) and it has binary testing nature which results in very aliased edges, so some additional anti-aliasing or manual multisampling technique is usually required.

For a use-case scenario take a look at how uGUI Mask component works - it's very slow (generally not usable on mobiles) and it only supports hard edges. For masking with uGUI we have a custom component which provides fast soft masking at the cost of only one additional texture fetch and it's incredibly faster than the standard Mask component which uses stencil buffer.

That said - it may be an option if you are targeting modern iOS devices (iPhone 5s and higher are good "performers"), but it's definitely not something I would recommend as a general implementation. And it will definitely slow down the whole Sleek Render pipeline considerably, nullifying all the performance things I've done and still doing, so it's not an option for me either

 

Okay, there's some new info on the update and future work on the package.
First - I'm terribly sorry for the update delay with the improved bloom features. In the end I have managed to do a lot of research work and try quite a few different ways of handling increasing package complexity.

Right now there's a REALLY improved bloom without any performance penalties. It has also become much more tweakable - it's now possible to precisely set the spread using texture size and passes count. All thanks to the newest Dual-Filter blurring technique that works amazingly well on tiled mobile GPUs.
I haven't seen other packages using this method - it's usually Gaussian (pre-0.8 blurring method for Sleek Render) or Kawase, which is quite hungry for the passes and is not cache-friendly.
All in all - I have even managed to simplify and improve the pipeline even further, removing one of the ealier passes which didn't do much work, but consumed one render buffer switch.

Small video footage of the new functionality - https://imgur.com/a/T70hsN8

I'm currently building the package using all possible versions from 5.3 to 2018.2 to make sure that it works consistently across those versions. Once I'm sure everything is OK, the package is going to be submitted for the review and it will come live by the end of the next week (1st of September).
Right after that release of 0.8 version, I will "patch" it with an almost-ready-to-use Film Grain effect on which my intern guy was working and which needs some extra care in testing and performance tweaking (so it's fully ready to use on its release). It will be a 0.8.1 release and it will come in two weeks after the 0.8 release.

After that I will post some post-release thoughts and mentions here and will write on future plans for features and support as I have got a lot of customer feedback and requests during these three months.

Cheers.

 

Pretty Awesome stuff you got there Well Done. (y)

 

@Kumo-Kairo

I'm interested in your asset, but not to actually use it I have our own post process stack, and I've sort of hit a wall in optimising it. So I found out about your asset and I'm interested to buy it and see what you're doing, in order to pick up some tips on how to optimize my own stuff further. (I'm hoping that's okay)

I do have a few questions:

1. You mentioned somewhere that you don't use Graphics.Blit. I'm assuming you're drawing a quad and drawing on that directly? Is there really a performance benefit to that? (Isn't that what Graphics.Blit actually does?)

2. I see you switched to OnRenderImage and you mention that you have (or will have?) some way to render to a lower res without affecting other cameras..? Is that even possible?

3. One of the performance issues I have that I'm trying to solve (if it's possible), is that, I'm doing all the rendering to downsampled RTs (and even further downsampled for some of the effects) so that our 3D stuff can be lower res, but the camera with the GUI stuff can be at full res, so text etc is always crisp.

The problem I'm running into, is I'm using OnPreRender and OnPostRender, and in OnPostRender, the final blit I do, which is to null so it will write to backbuffer takes a really long time (it takes like 4-5ms on a iPhone 6S Plus), even if I don't set any special material for it and just writes my final rt to backbuffer and nothing else. I guess writing to the backbuffer is really slow for some reason? Does your asset somehow avoid this?

Hope I'm not asking for too much, please feel free to ignore my questions. I'll buy your asset regardless.

 

Hi @AcidArrow, thanks for dropping by

True, I use a custom screen-space quad instead. The initial impulse to do it this way was an advice from a much more experienced graphics guy (who worked on games since like PS2) and in case of their mobile game (Fetty Wap Nitro Nation Stories) it enabled them to save 1-2 ms on low end mobiles.
Most likely Unity did something more than just calling a draw call on a quad with a matrix, I don't have sources and can't check.
A custom quad method worked well, but I got curious and made some measurements - it wasn't as severe as 1-2ms in my case, it was 0.5ms tops on my lowest end mobile. But again, it may vary from Unity version to version, so it's advised to check what it does for your particular case. In case of Sleek Render I at least save some matrix calculations for quad vertices (as my quad is already in screen space), but it's like a mosquito sting to an elephant and may not worth it.

Yes, I still use OnRenderImage to allow users to combine other effects with Sleek Render (it's the easiest way). And unfortunately there's no way to easily downscale the main render target using OnRenderImage as it requires tempering with camera render target.
The main problem is that Unity doesn't allow having single scene camera that renders to a render texture, there has to be at least one camera that renders to "null" (the main render buffer that Unity treats as its backbuffer), even if its culling mask is set to "nothing".
A lot of time has passed since my switch to OnRenderImage and now I know how to approach this problem of combining other effects with a custom render target and I will definitely get to it (it's pretty high up in the package backlog)

There's nothing internally slow in a full-screen blit copy, Unity actually does this every frame at the very end - it's copying its framebuffer contents to a backbuffer using a simple identity shader - just sampling a texture and returning it as it is without any math. It's not shown in the frame debugger and the only way to check it is to use native graphics profilers for specific GPUs (my all-time favorite is PVRTrace).
Sleek Render also makes a final full-res Blit (because, as you have noticed, it still uses OnRenderImage), and I just try to do as little work as possible - even just calculating luma values of pixels can slow things down considerably if used on a dense resolution screen. This is another case that would benefit from using a downscaled main render target.

Another thing that I notice quite often in other packages is usage of float and fixed number precisions. That graphics-guru guy told me some info on gles implementation on certain GPUs like the PowerVR used on older iPhones. He said that it uses half precision for its fragment shaders internally and returning it as fixed slows things down quite considerably as it has to convert them from fixed to half. I can't really check this info (so don't quote me on it), but the guru guy was quite serious about it when he saw compiled GLSL code with lowp in my shaders - he was like "KILL IT WITH FIRE - IT'S PURE DEATH!"
I personally just use half for everything - position, color, uvs and all calculations, and judging by PVR GPU pipeline specifications it can do twice as much work when compared to float and we don't need to convert it to a different number type on older iPhones (and possibly other than PVR mobile GPUs as companies tend to borrow pipeline processes from one another). There are also things like SOP vs MAD forms where some math equations can be calculated in one GPU clock cycle instead of three, which ultimately saves millions of clock cycles on high-res blitting.

I sometimes still finding ways to make things faster, but Unity doesn't always help us here - I have noticed overall performance drop starting from around 5.3, some torn-out graphics debug info from around 5.6 (I can't check timings and stall info on PerfHUD ES in newer Unity versions, but can if the project is built in 5.3).

So yeah, I don't think there's some magic here, just trial, error, native profiling and some really experienced guys who I can talk to if I'm really lucky.

As for your particular case - Sleek Render would be a good framework for building your custom effects stack. I've had a few customers who have successfully extended it to their needs as the package is relatively easy to customize.

 

As promised, 0.8 update is now live. It includes greatly improved bloom (more quality and stability).

Package price is also increased by 2$ (it's now 19$) as it took me quite a while to get to this point. This price will be frozen for the next 3 months regardless of new features (till 30th of November).

Film grain is coming with the 0.8.1 version in the next two weeks.

 

Updating to 0.8 completely broke my project, with multiple errors. I'm on OS X running 2017.4.
"Shader error in 'Sleek Render/Post Process/Brightpass Dualfilter Blur': failed to open source file: '../SleekRenderCG.cginc' at line 15 (on glcore)

Compiling Vertex program
Platform defines: UNITY_NO_DXT5nm UNITY_ENABLE_REFLECTION_BUFFERS UNITY_NO_CUBEMAP_ARRAY UNITY_NO_SCREENSPACE_SHADOWS UNITY_PBS_USE_BRDF2 SHADER_API_DESKTOP UNITY_HARDWARE_TIER3 UNITY_LIGHTMAP_DLDR_ENCODING"

Thankfully I still had .7 available and all was fine after replacing the update with that. Hopefully it's just a minor fix, just thought people should know. I'm really hoping for a blur effect at some point, thanks for all the great work so far!

Edit :
Developer already contact me trying to help resolve issue, superb service! Also the new version works fine imported in a fresh project; so it must be something related to my project, where I'm doing a lot of adjustments from code.

 

@ErikSmith, Thanks for the feedback, I will contact you directly. It still works OK in 2017.4 for me, so I need a specific scenario to see what can be wrong in your case.
Most likely you have moved the Sleek Render package from its "Plugins" directory somewhere else so it can't find appropriate CG files. It's advised to completely remove a package before importing an update, Unity still has problems tracking package contents and changed folders.

 

Hi!

I'm using Unity 2018.2.5f1
The new update makes the bloom tint completely opaque... If I lower the bloom intensity it creates a semi-transparent overlay...

 

@FineAllDay do you have a before-after screenshot to see what you mean?

 

I don't have a before, but the bloom was working normally. I have this error now:
Shader error in 'Sleek Render/Post Process/Brightpass Dualfilter Blur': failed to open source file: '../SleekRenderCG.cginc' at line 15 (on d3d11)

Compiling Vertex program
Platform defines: UNITY_NO_DXT5nm UNITY_ENABLE_REFLECTION_BUFFERS UNITY_NO_CUBEMAP_ARRAY UNITY_NO_SCREENSPACE_SHADOWS UNITY_PBS_USE_BRDF2 SHADER_API_DESKTOP UNITY_HARDWARE_TIER3 UNITY_COLORSPACE_GAMMA UNITY_LIGHTMAP_DLDR_ENCODING

 

@FineAllDay wrote an IM regarding this, also seems like a package moving-importing problem.
I may need to remove the .cginc files completely in this regard, they are just too much folder structure sensitive and break if any part of the package is moved separately

 

After talking to a few people it became apparent that the issue only exists when the original Sleek Render package was moved or modified - clean install works correctly.

Made a small "hot-fix" release completely removing the cginc file to increase robustness of the process when moving a package to custom location. Should make the updating process easier.
The update will be live on Monday-Tuesday (as I don't think Unity guys actually work on weekends). Anyone experiencing similar issues after upgrading to 0.8 - write me an e-mail or a direct message here, I will send you the 0.8.1 version right away and will provide additional support.

Cheers.

 

Hey we are looking for a depth of field that is on Mobile is this available with sleek render ?

 

It's a common feature request, but it's not available yet. It's pretty high on the backlog list and it will be implemented after the master downscaler for 3D for the standard legacy rendering pipeline.

 

Hi

Really nice your Asset!

two questions please

How is going the 0.9 version?

I'm implementing an experiment with Arkit and Unity 2018.2.6f rendering with Metal. My fps is slowing to 50fps from 60fps when using the asset with colorize, vignette and bloom. There is some known trick to improve performance with this settings?

thanks

 

Hi!

Usual case is rendering already taking around 16.6ms and any additions to pipeline (even 2-3 ms in average) can bring overall FPS down to 50. So general shading considerations should be taken (most common thing is using standard unity shaders on a mobile target). You can send me more info on the project on my support e-mail or here via IM to receive more specific advises on your rendering and overall project setup. I've helped to speed up quite a few projects already, so please don't hesitate to contact me on this.

I'm currently testing film grain, but right now it really slows down the rendering due to the fact that it's also a full-res pass with additional precious GPU passes spent on arithmetic (there are options of using downscaled pass, but it doesn't look good in every case and for every blend mode). So I'm considering adding a separate master downscale functionality for 3D scenes in that version to enable users speeding up the overall 3D rendering process (to mitigate the drawbacks of a usual case with using unity standard shaders for 3D objects), so overall rendering (post processing included) becomes cheaper. Something that Unity has in a new LWRP right in the pipeline settings (they have a scaler slider for 3D geometry built-in).
I'm not sure about exact ETA now, but will post once I will have more info.
Alternatively, I will add the downscaler first and film grain right after that.

Cheers