Sleek Render - Lightning Fast Mobile Post Processing Effects

Hi

Thanks for the quick response, and sorry for the late mine.

I've tested with the postprocessing stack v2 and the fps is slower, 40 fps. Could be great if you can show me some knowledge on speeding up, I will write you with more info.

Sounds really good the library advances, LWRP looks like a big open door but not easy to cross, I will be waitting the next release to try learning how do you use this big power

Thanks

 

Hello!

Can we block post-processing for some layers? Like, don't do post-processing on "Particles" layer?

 

And one more thing, is it possible to add anti-flicker to bloom?

 

Hi @ytaha!

This is usually not a trivial task (Unity's PP Stack can't do it out of the box either). But it depends on a case - if you have a 2D game where particles are always on top of everything else, you can try rendering them with another camera. Particle rendering is actually a very good candidate for optimization and they usually allow for downscaled off-screen rendering. Ultimately I would suggest rendering them offscreen with a downsized RenderTexture and applying them to the Master render after the post-processing step. But you are surely would have to do some manual pipelining coding to achieve it (I can provide further info on how to approach it if you're interested).

It seems that the white lines are too small for the bloom to effectively pick it up. When we're blooming, we have to downscale the whole rendered scene and the resulting texture has pretty harsh quantization properties (some pixels get lost when moving) and it's a general bloom problem that relates directly to processing power and the size of blooming objects. Sleek Render has anti-aliased downscaling (both in hardware and in the shader), but as you can see, it doesn't solve the problem in a case of such fine details.

You can crank up the pass count for the bloom up to 5 (and maybe customize the Sleek Render code to go up to 7, but it will be considerably slower and most likely won't be suitable for lower-end mobiles) and also increase the size of the bloom texture (so more pixels get to the texture).
The "anti-flicker" switch is usually implemented using this approach - cranking up the texture size and blur passes quantity which results in lower performance. The latest bloom update does exactly that - it allows for better quality bloom for less flickering. White parts are just way to small in your case.

You have two good options though:
1. It may sound silly, but you can put a semi-transparent glow sprite over your objects that looks like bloom (with a simplest additive shader on it). You can even make a few frames of animation, or transform its scaling based on velocity of your moving triangles. It will look way better, will enable you with better overall control over shape and appearance and most importantly won't require any post-processing at all. I really think it's the best way in your case.
2. Using some custom pipelining logic (again) use some other objects for bloom (not the triangles with white rims themselves, but maybe bigger full-white triangle) and render them only for the bloom camera (not to the main view camera). Apply bloom to that "fake scene" texture and overlay it ontop of the master render. Flickering would go away as bigger all-white triangles would be much easier to pick up. You will also be able to stretch those fake white triangles to make some kind of anamorphic bloom based on their direction and velocity. It will most likely look the same (or even less nice) as the first option but with lower performance (Sleek Render is fast, but it can't beat the no-post-processing way)

Anyway, there wouldn't be a magical "anti-flicker" switch in this particular case that will perform good enough for stable framerate on mobile, good performance in specific cases usually requires some customization anyway. Again, I can guide you with general advises on custom pipelining and general graphics stuff, IM me if you're interested.

 

hi @Kumo-Kairo , am interested in buying this asset, but am waiting for Low Weight render pipeline support.

 

Hi!
Last time I have checked, LWRP requires binding to the standard PP stack (source) which basically means we are bound to additional standard PP Stack overhead even when not using any of the built-in effects. The only "robust enough" way of hooking up Sleek Render to the standard stack is to us it and extend it.
I've seen quite a lot of users report overall performance drop and hugely increased build times (shader variants compilation) by merely adding a PP stack to the project. I haven't looked at myself it in depth yet though.
Moreover, LWRP is still in preview and although they don't seem to be shifting many things around lately, things would definitely break like they do with standard PP stack updates.

This whole picture would imply false hopes on the Sleek Render package because however fast it may be, it will still be slow right at the beginning just because we have to go the Unity way and extend the standard Post Processing stack instead of replacing it completely.

I will definitely add support for custom Scriptable Rendering Pipelines, so it's easier to add Sleek Render to a custom pipeline. And will most likely post some guides on cloning and changing the source of the LWRP to use Sleek Render instead of the standard stack and not extending it so we can have at least some rendering performance back.

But right now I would suggest sticking to the "legacy" rendering pipeline which as of writing is more customizable for the not-really-graphics-tech-guys than LWRP which requires you to stick to certain lighting models and predefined rendering behaviour.

 

@Kumo-Kairo thanks for replay, i haven't delved in learning how shaders work that much.. unity engine devs embraced the new render pipelines fully for their future unity releases.. which is kind of feels we are going to be left out behind if we don't embrace it as well.. am sure many will feel the same (also potential future buyers)

regarding build times, is not a big deal for me.. only performance is what i care about!

what i would suggest personally to you.. is maybe it's a good time to start "Addressing" your concerns and communicate with a unity dev.. to see how to possibly achieve same performance numbers on the new pipelines!

am sure they will be interested, since the team behind LWRP and you are both share the same goal to achieve best performance on mobile.. maybe they will make few changes that make it possible for sleek to run as good as it is now.

sadly the current postprocessor despite being enhanced to be mobile friendly... it stills chops fps from 60 to 30 even on just enabling single effect!

 

I really think that LWRP is just a big marketing selling point. The pipeline is bloated with general stuff that is suitable for all things from PBR to unlit VR, which is generally not a good sign. It's good enough for general solution, but not more.

If you really care about performance - avoid LWRP at all costs and write a completely custom pipeline. I haven't seen any serious and successful Unity game that was OK with using standard shaders and pipelines (which is applicable to legacy pipeline as well as it's still quite customizable). Look at any Unite talk about "how we made our game" and see how they tell what they didn't like in Unity's rendering and how much they have customized it. Same thing would be with LWRP, we have just changed names.

This is exactly why PostProcessing stack was added to LWRP so it could be extended with custom effects. The reason they are not adding more hook points for post processing is that anything that is more elaborate would increase the complexity of LWRP reducing overall robustness. And this is where I completely agree with them. Custom pipelines exist for this exact reason - to enable as much customization as possible.

I would definitely prefer losing some buyers over making false promises about possible performance that can be achieved with LWRP + Sleek Render. We have enough of this bad marketing already.

Again, as I have said, I will surely add Scriptable Pipelines support so Sleek Render could be embedded in custom pipelines, and this is really the only real way to make Sleek Render serve its purpose.
I would rather invest some time in educating people on mobile rendering - both in shaders and pipelines, so more people will be able to correctly reason about rendering performance and be comfortable with writing something custom.

I will continue looking into LWRP for more updates and possible hook points for Sleek Render, just in case something drastically changes, but can't really promise LWRP support. Be sure to wait for Custom Pipeline support though.

Cheers.

 

makes sense.. but i have zero knowledge of shaders writing.. thats why am posting here in first place

that's why i said before that you might need to be part of beta forums or perhaps discuss how to achieve same performance numbers to push unity team to do something about (all stuff you mentioned).. currently unity team is focusing their tools/optimizations on these new pipelines..

looking forward for the updates in future.

 

How do you add bloom to objects? Specific objects or at least sprites? I have no idea and I'm trying to make a glowing game. Im so confused on how it works. Sorry t

 

Hi @Kumo-Kairo, I just bought this, thanks for making it.

I have a somewhat stylised requirement- I want to make the glow affect less saturated colors less, so before the threshold multiply the luminance by the saturation. The attached image is what I mean.

How should I go about doing this in your code?


On another note, I'd recommend updating the sample images in the asset store as I spent quite a while making sure this plugin did in fact do non-anamorphic bloom. You don't want to undersell your great work!

 

This is not currently possible out of the box (it's not possible using standard Post Processing Stack either unless used with HDR rendering) as it requires advanced graphics pipelining which masks objects using custom alpha values or using dual-pass logic like in Tron 2.0 (http://developer.download.nvidia.com/books/HTML/gpugems/gpugems_ch21.html)
It seems to be a popular request, which is unfortunately not really possible to solve in a generic way that is also performant on mobile, so I will most likely add a how-to tutorial on this with customizing shaders used in a project, please stay tuned.

It's totally possible. The "hardest" part of it is calculating saturation (converting RGB to HSV) - it's a pretty costly operation. There are other color profiles that use saturation like YCrC or YCoCg (chroma there is stored in two channels) and they are usually easier to get from RGB than HSV. Contact me on support e-mail to discuss this in more detail for your specific case.

Thanks for the advice, I will be sure to update the screenshots.

 

Heya,

I'm a PlayMaker user and i'd like to write my own action that lets me control color value in the colorize module. I've written a few actions before but i'd really appreciate some tips as to the scripting syntax I should be using.

Cheers,

Simon

 

Hi @avrigus
Writing custom actions for Playmaker to control Sleek Render is a trivial task - just follow the PlayMaker manual to hook up a reference field and tweak the settings values from your action code. There's nothing special or different from the standard custom action creation process here, so any general tutorial on PlayMaker actions would do.

 

any example code to access Sleek Parameter via Scirpt ?
Actually i wish to change value of Vignette Color from black to red when player dies..

 

@mbhagat it's the same as tweaking Standard Post Processing stack parameters. Check the 4. Script Control section in the ReadMe file

 

Hello,

Thanks for the great asset. I have a feature request for the bloom effect.

Right now bloom has very high saturation and for this reason it doesn't fit our game very well.
For example, bloom effect on a red surface is (that is lit by white light) is red. With unity's post-processing stack it's reddish white. I think that's also how it happens in real life.

That's why I wish to request an option to set the saturation value of the bloom.
If the value would normally be (255,0,0) with bloom, When saturation is fully reduced it shouldn't be (85,85,85) but it should become something like (235,235,235)
And for (255,255,0) I guess it should become something like (250,250,250)

When saturation is in the middle setting, it should turn to full white on areas where bloom effect is most intense. And where it's less intense it should keep the saturated color.
I think that's how it works with unity's post-processing and also in real life. But if it's very costly on performance a simple saturation slider can also work.

Thanks.

 

@Meceka thanks for your feedback.
Yes, real-world lights work like you've described - we observe desaturation when brighness increases (while physically leaving the light source with the original color), and it usually happens not only on blooming objects, but with bright objects in general. This is actually how Unreal Engine handles their color profiles and tonemapping (and this is how our eyes actually work, where certain colors sensitive cells "overlap" in their response and tend to "leak out" on other "channels" when light is too bright).

Although it sounds like a total win-win (in the end don't we all want more realistic effects?), it's actually pretty project-specific. In fact, you're the second person to tell me about this brightness-saturation thing.

I'm not exactly sure how Unity does this right now, but last time I checked it relied on HDR quite a lot, which makes it much easier to handle overly bright colors through tonemapping.
LDR, on the other hand, has an inherent limitation - it's pretty limited in terms of "raw" luma calculation as we won't be able to rely on that luma value if only one channel is maxed out and others with zero. We will have to convert RGB space to HSV (or some other sort of chroma-luma color space where these things are separate and color values aren't tied with saturation), which is usually quite costly and requires a lot of ALU clock cycles.

And while it seams like an unsolvable problem for a general case, it can be hacked a bit to work on specific project to get a specific look. Like you've said, we can desaturate bloom separately. You can actually do some extra stuff to approximate that corner cases of high saturation with low overall "lightness" (luma) like (1, 0, 0) with some simple almost-sigmoid function that boosts luma values quickly after some value and then leaving it as it is, not making any brighter to avoid hard edges of white color.
As bloom is calculated only on downscaled render targets, it's possible to do this work at a lower cost than running an actual Desaturation effect on the whole picture.
It's quite a specific case and I can help you add these things up to your local Sleek Render copy if you want to get into shaders a bit. I definitely won't add this to the main package in nearest future as it's pretty project-specific and will just increase overall cognitive load on users increasing confusion.

 

Hello,

I think you can add this option as a slider and with a shader variant. (multi compile) So that it wouldn't cost performance to users that want to use the saturated bloom. (as it is now)

It took me some time to understand why your bloom looks unrealistic compared to Unity's post process bloom. And I could find the reason after spending some time comparing the effects. The reason is this issue.
By this, I mean that most developers wouldn't actually realize that high saturation is an issue without comparing it to a more realistic bloom effect. I think it's not that project specific and you can make lot's of developers happier by adding an update that adds an option to improve the realism of the effect.

And I didn't really understand the reasoning behind why it would cause confusion. Every developer I know likes tinkering with such sliders

I worked with surface shaders before, but I don't know about luma or post-processing. I'm not sure what you would recommend for modification, but I can give a try to modify the shader with your directions.

Doing such local modifications on assets can be very time-consuming for developers because when asset-developer updates the asset, you are either stuck with the old version or you need to re-do same stuff again every time for updates.

 

I also think @Meceka's idea would be nice to have built-in into sleek. I had to do some changes to sleek (a "low-pass" filter of sorts) and would rather not make any more local changes.

 

You would be surprised how many seemingly-trivial and simple questions I get on everyday basis and how simple changes can cause quite a lot of confusion for such users. Befure I started making packages I didn't even think there would be some problems with it (it's completely unintuitive for me and for most experienced developers that I know)

Tinkering with assets is usually incouraged - there's just no good-enough general tool that will suit everyone. Most of professional commertial projects I have worked on (or consulted) customized most of the things that related to core functionality (especially graphics). I personally consider Sleek Render a good ground point for commercial projects that is relatively easy to extend or change.

@Meceka , @SugoiDev I got your feedback and will consider implementing it as core functionality in future versions. It would be best to receive some screenshots of your projects, something like before-after, or just the desired output compared to current implementation so I'll be able to actually represent the desired result.

Cheers

 

@Kumo-Kairo I'll see if I can get some shots of my current changes. They are not directly related to this feature request, though. What I did was to make it Sleek only apply bloom to HDR colors with high enough exposure setting. Our current game is very colorful, but also has lots of very white characters (ghosts), so the default implementation was making the whites too overwhelming and the artists could not get to the same effect she had with the PPS.

Specifically, this is what I did on the getTapAndLumaFrom
I get the luminance from the tap, and use it to decide whether to apply bloom or not.
It's far from optimized and more of a proof-of-concept so my artist could decide if Sleek was able to give the effect she wanted, or if we should continue with Unity's PostProcess stack. In the end, Sleek won and it seems we'll be using it!

Code (csharp):

1.     //Only HDR stuff (components > 1) contribute to bloom.
2.     //this is the luminance of this tap.rgb
3.     //it's the Y from YCbCr
4.     //it can tell us how "white" the color is
5.  
6.     half Y = 0.2126*tap.r + 0.7152*tap.b + 0.0722*tap.b;
7.  
8.     //if the color is almost white (0.8 out of 1, but NOT HDR, ie, not over 1, then we don't apply bloom to it)
9.     //this prevents "whiter" colors from becoming too overwhelming (like Ghosty's white color)
10.     //it also gives the chance for other colors to glow prettier
11.     if (Y > 0. && Y <= 1) {
12.         return half4(0, 0, 0, 0);
13.     }
14.  
15.     //now, we only consider colors over the threshold to contribute to bloom
16.     //this could be just half3(1, 1, 1), but using luminanceThreshold makes it better to configure in the inspector
17.     tap.rgb = tap.rgb - luminanceThreshold.rgb;
18.     //we call those max below because, if a component was smaller than the threshold's component, then
19.     //that component would now be negative
20.     //In that case, it was below the threshold, so we want to treat it as zero
21.     tap.r = max(0, tap.r);
22.     tap.g = max(0, tap.g);
23.     tap.b = max(0, tap.b);

 

Hello @Kumo-Kairo

Great to hear that. I will send you some example screenshots this week that shows the desired output.

 

Hello. I'm really sorry for the delay. Here are the screenshots.

Edit: Bloom settings


No Bloom


Unity Post Process V1 Bloom


Sleek Bloom

 

No Bloom


Unity Post Process V1 Bloom


Sleek Bloom

 

@Meceka thanks for the screenshots, very informative. I will look into it, stay tuned

 

Hi @Kumo-Kairo, thanks for your excellent work.

I noticed that this reference https://forum.unity.com/threads/pos...phics-blit-onrenderimage.414399/#post-2759255 has mentioned something like "Don't use OnRenderImage(), use OnPreRender() & OnPostRender() with custom targetTexture instead" in order to avoid CPU ReadPixel().

Have you tried that? Since it's still OnRenderImage() in Sleek Postprocess.

 

Sleek Render initially used OnPostRender with a custom target texture (to accomodate for future "main render downscaler" feature), but that implementation made it incompatible with other image effects placed on the same camera - Sleek Render users kept using other effects on the same camera, which is not really good in terms of performance, but user's desicions are out of my hands.
This is why I have "fallen back" to OnRenderImage after I've done quite a lot of profiling (both in terms of CPU usage and natively using some GPU-specific profilers like PerfHUD ES, Adreno Profiler, PVRTrace etc.) - turned out that OnRenderImage doesn't have any CPU pixel copies, nor does it have additional "identity" GPU blits "before every OnRenderImage" as people sometimes tend to say on these forums (you can easily check that yourself using some native mobile GPU profilers). In the end, this OnRenderImage approach turned out to be the same in terms of performance as the OnPostRender as the underlying processes for one package with a custom way of combining effects (which Sleek Render is) are completely the same.
OnPostRender approach is essential if you want to make a 3D master downscale (so 3D scene is rendered at a fraction of the native screen resolution, leaving overlay UI unaffected), but it has nothing to do with how OnRenderImage works internally.
In general, there's nothing internally slow in OnRenderImage, it's just that common approach to chaining effects using OnRenderImage instead of some custom pipeline, as well as inability to make a downscaled 3D scene "view" that can lead to worse performance.

 

Hello, I just bought your package, but it seems that it doesn't support HDR. I need the bloom effect to be on the object where I added HDR. I works with Unity's post process stack but not your package, is there something I can change for it to work? the code you previsouly posted for getTapAndLumaFrom is it enabling HDR?
Thanks.

 

@madgreg I strongly discourage you from using HDR on mobile. Not only it's buggy (device-specific black screens on certain GPUs due to graphics driver bugs and tonemapping implementation), it increases overall bandwidth by an incredible amount, nullifying all of the optimizations, making it slow as hell.
If you need to mask your blooming areas, there are a ton of other ways to do it without using HDR.
You can surely change the Sleek Render code by changing intermediate texture formats to some HDR type that your target devices might support and changing the shaders to work with HDR tonemapped values instead of normalized gamma.
But one can as well just use Unity's Post Processing Stack with this setup because most of the stuff won't even be supported on low-end devices anyway, and using Sleek Render with it would be like trying to close a breach on a Titanic hull with a finger.

 

Thanks for the advice @Kumo-Kairo, it's a shame, HDR allows so many good visual effects. I want to achieve an effect like the temporary highlights of the poker cards in this screenshot: https://www.cheatorhackgames.co/wp-content/uploads/2018/08/scatter-holdem-poker-cheat-codes.jpeg (for the record I do not use this website and cheat it's just the result of my google image search)
I think in this game they're using HDR and bloom to achieve this. How would you achieve an effect like this without using HDR?

 

That doesn't look like bloom to me, it looks like a simple sprite used for the glow. It's not the most efficient technique, but on a canvas you could replicate that effect by simply having a dark transparent quad covering the whole screen, with the well lit items simply being in front of it.

 

I don't think it's just a sprite, it is at least a shader effect on the cards. You can probably see better on that video:

Yes I thought I could also do it with a whole screen dark quad but I thought they did this effect by changing the whole scene brightness and boost hdr on the cards to highlight them.

 

@madgreg, @Adam-Bailey is right - it's just a visual effect based on particles (with possible flipbook animation, but it depends on FXer's skills). Whole screen dim is best done in a per-object tint where we only darken the non-interesting things without any masks. But making it layer-based rendering with a fullscreen gray quad followed by highlighted objects would also work OK, but it's much more fillrate-heavy (bad for mobile), and you are usually using some kind of tint on sprite anyways (to allow for alpha blending).
Using HDR here is an overkill. You'd be surprised how many effetcs in mobile are done without any post processing whatsoever. It's usually harder to implement that using some generic approaches (like HDR for masking), but if you want performance - there's just no way around (no one said gamedev is easy).

You have actually almost cracked one possible scenario. But why do you think it's easy to "decrease the whole scene brightness", but hard to "make certain objects have initial brightness"? What is brightness here? I guess everything on the scene is some kind of unlit sprite, so "decreasing the whole scene brightness" us just simple tinting of all sprites to darker gray, leaving some of them untouched.

 

This is, as already pointed out, a mix of sprites + additive and alpha-blended shader and particles on a spline + additive shader. Or even some spritesheet (either pulled off with a particle system or not).

I guess not even the creator of that game would even consider a fullscreen FX for highlighting just a few details. Probably he's not even using any composite shader for the cards.

If the FX you're looking for requires sharp, clear angles, you would at least need to render those sprites separately on an FX camera, or have a plugin that lets you filter out some layers.

Such crisp, almost pixel perfect, glow is definitely something heavier to pull out with a postFX rather than using a few old-school tricks, especially on mobile, where downscaling is a frequent choice.

Think of a 4K display running a 4K glow with multiple passes on a mobile. Sure, now you can rescale the resolution to have fixed dpi, but that's just running around the problem.

While I love SleekRender and hope more speed-oriented postFX like this existed, as soon you begin adding some features like hi-resolution rendering to it, it may eventually backfire making everything slower.
So, well, probably is technically possible, but making a copy of the SleekRender shader and working from there.

Speaking from personal experience, applying a post-fx to the whole scene just to highlight a few objects is very prone to getting the unexpected to glow, I'd suggest you to take another route

 

Yes, I knew that using PostProcess was overkill, I used the Unity PostProcess stack to do this in my prototype because it was easier to achieve the same visual result so I can see if it looks good in my game. Now I'm in the process of finding a way to do this while keeping good performance. That's why I wanted to try SleekRender to see how it improves the perf of the post process. But yeah it might not be the way to go.
I already tried with additive but the result doesn't look as "burned" as I wanted. But maybe there's something I missed, I'm going to try again and maybe tweak my additive texture.
Thanks for your inputs.

 

Hi there!

I'm not sure if I've already asked about this, but just in case:

Since Sleek Render is definitely the one and only asset caring about performance and mobile, is there any chance to have some basic sunshafts?
It's been a life that I'm looking for "parallel" sunshafts on the whole store, but found nothing ready out of the box. Would be some sort of 1) grabbing the shiniest mask representing the lights 2) Bleeding on a direction until it either fades out or "hits" something in the Zbuffer 3) uses the appropriate direction of a directional light.
I know it could be faked with some particles or static objects, but it's not always possible to do that.
I've seen a similar effect on an action game in the LoTR series, and looked pretty nice.

Best,
Alessandro

 

Hi, @NeatWolf
The first thing that comes to mind is the original Infinity Blade release, they even have a paper on rendering somewhere, but I can't find it anymore. They have used simple non-depth-tested shafts with simple downscaled blur.

The problem with depth-tested post processing sun shafts is that it's insanely heavy to use depth buffer tests on the "soft" side (shader code) on all tile-based GPUs (Adrenos / Malis) and tile-based-deferred (PowerVRs - basically all iOS devices, even the newest ones that have different markings are the same PowerVRs).
Depth buffer is used internally on hardware, usually needed only for hardware depth testing and doesn't leave Tile Memory at all. The only way to get depth buffer values is to either write it in alpha as "one over depth", or render the scene twice using a different shader that outputs that use the same one-over-depth way.
First way requires customizing all used shaders in the game (which usually has to be done anyway), and sometimes not available for usage because things like Unity Terrain seem to be already using alpha channel for some internal data.
Second way increases bandwidth pressure considerably, incurring an additional resolve between the two passes. It's also will be heavy if the geometry is relatively dense (it's similar to forward rendering shadows where we always have an additional "depth-only" pass from the Light's point of view to get depth values for "soft" comparison)

This is usually the way to go on mobile, I would personally do it just as you've said - making the effects art-based rather than relying on generic post processing effects. It surely depends on a case, but usually it's worth the hassle - it won't incur any additional resolves, doesn't require customizing alpha-write of all in-game shaders and is generally more flexible in setup.

If you'll be able to write the name of the game and point to places in a game where this effect occurs, I will be able to reverse engineer it and post here about the ways they handle sun shafts, some performance considerations and the possibility of adding it to Sleek Render.

Cheers

 

Thanks for the in-depth reply.
I actually have "Disable Depth and Stencil" checked out in my Android project Player settings

Yes, using the depth buffer was just an idea from someone (me) who really loves postFXs, has got quite some insight on how they work or on a high abstraction level, I enjoy looking and reading docs and videos from SIGGRAPH but never got to the point of writing one full time (and for some basic things I should probably do).
So I was missing some parts of the knowledge and experience you disclosed, thanks for sharing

Found it! It is LoTR - War in The North.

Now, let's just focus on the FX, one of the things I remember the game for

It's very subtle, but looks really nice (IMO) against forests, castle walls and open areas:

In the video it's a bit hard to see, since the player wasn't just staring at the sky and at the postFX like I was

Here in the picture it is a little bit more evident.
It could either use an angle relative to the camera and the parallel light source (so, facing the light source the bleeding goes stright down at maximum intensity, and disappears when facing the opposite way), or just have a fixed, slanted angle.
To me, at the time, looked pretty good, since most solutions were definitely heavier and had some banding.
This approach is definitely not physically accurate, but it should be (relatively) fast and smooth, since it's basically bleeding the z-buffer mask diagonally in screen space.
Not sure if it can be achieved using a threshold luma value, or a specific color range/hue (it even worked smoothly with clouds IIRC, being effectively god-rays) to get a texture/mask, bump its brightness a bit and actually starting from there to create the effect.


One naive approach I used when developing with GameMaker "back in the days" was to create an actual god rays fx was to store the mask once, and blend it multiple times according some steps in a number calculated according the current fps, scaling them proportionally to give some sense of perspective.
Yup, shaders still weren't available so everything ran on software, but on a limited screen resolution (320x240).
I guess that creating a shader like the above may involve a similar process.

Spoiler: For the curious ones:

More evident here:

Cheers,
Alessandro

 

Wait what? PC HD? You surely know that PC and Mobile usually have different approaches due to different GPU rendering architectures, right?
I will take a look at the game though. PC reverse-engineering is not as insightful, but I think I'll be able to get some general info.
Can you point out a few other places where this effect can be seen? And the minimal graphics settings it's visible on? I'm not sure if I'll be able to invest much time in it, so it would be helpful to get some directions.

 

Sure
"PC HD" was just the postfix of the youtube video... from 2011. That is, about 4 mobile generations ago
At the moment I can't remember of other games using it.
Nevermind, it was simply in my wishlist, I don't need it at the moment, feel free to focus on the asset, I'll eventually give it a go as a personal experiment, as soon as I have some spare time

Thanks for your continuous support on the asset
Best,
Alex

 

You would be surprised to know that even new mobile phones still use graphics chips from 2008, and they are pretty common nowadays (up to 50% on global Android mobile market - check Mali 400 / Adreno 305 / 306 etc.), not to mention the different rendering architecture of PC which makes it possible to use certain techniques on much older hardware efficiently (immediate mode, not optimized for lower power consumption).

What's even worse - old graphics chips are used on higher density screens - same chips that worked relatively OK on 800x480 are used on modern 2100x1280 screens which have 7 times more pixels in total, which also has negative impact on performance and higher development pressure on addressing those high-res screens.

 

I'm not really surprised since I develop/profile/optimize for mobile, and you know that some of the points you mentioned can be circumvented with basically no perceivable loss.
No need to get into details or debates, we're both busy with work, I was merely expressing a wish about a shader I'd had loved to see implemented.

I'm a proud Sleek Render user, for a reason - I value your skills and background
Best,
Alex

 

Hello! Thank you for a great asset!
I have one question. Is it normal that menu settings dosen't show on inspector? Unity 2018.3.0f2

 

@RockSPb yes, you seem to be using default settings that are in-memory and not serialized (so Sleek Render has something to work with until a User has overridden that value). You should replace them with your custom ones by drag-and-dropping a Settings Asset into that field and tweak the values in that asset instead (it's clearly written in the ReadMe file, but I guess I should put a warning into the inspector itself so it's more apparent). Custom settings are created from the Right-Click -> Create menu in the project window.

 

Oh, this was a bad screenshot. This behavior happens with custom settings.

 

@RockSPb - click on the New Sleek Render Settings and a new Inspector Window would open allowing you to tweak those settings. It works the same as the Unity's Post Processing settings where everything is tweaked on another screen, not in the component on your Game Object.

 

Sorry, I thought something went wrong)
Maybe it's better to modify this line to prevent dark spots when brightness is less than 1?

Code (CSharp):

1. vignetteAlpha *= 1.0h - rawBloomIntencity ;
2.  
3. //to
4.  
5. vignetteAlpha *= 1.0h - rawBloomIntencity * min(_BloomIntencity, 1.0h);
6.  
7.  

 

This is a good example of things that can (and should) be kept out of the shader.
1. It's totally OK to check the value at edit time before even starting to render things.
2. Sometimes users mean to use that lower intensity values (in cases of low-key scenes for example)
3. Adding this little min call to the post processing shader adds at least one clock cycle to the GPU (it depends on hardware, but in this case it will take at least one additional cycle) which results in hundreds of thousands of completely wasted GPU clock cycles that can be eliminated at edit time. Keep in mind that even downscaled post processing passes usually take quite a lot of shaded fragments.
This is why Sleek Render is fast (at least it tries to be) - because every single clock cycle is counted.

If you need that input validation, add it either to the settings inspector as a lowest possible value, or validate it when changing (on the C# / CPU side once per value change). Put things where they belong.

 

I know how GPU work) but it's not just a clamping of overall brightness, this multiplying fix dark spots when intensity is low, overall bloom intensity is still less then 1. But I agree, it should be more optimal way. In my case 1 gives too much bloom, so I need some sort of fix.