First Shader (Ghetto HDR/Bloom/Color Correction)

Unity Engine
1

It’s pretty rough, only worked on it for two days, and getting used to shader stuff, but figured some of you guys might find this useful (and I’m likely not gonna add anything to it for a while). Anyways, it does a different style glow than the one built into unity, and does an exposure adjustment for light levels. There’s really not enough information in the source data (8-bit per channel texture) to do this well, but it turned out better than I thought it would, and I was generally happy with how easy Unity was to work with. There’s also several color correction features that might be useful without enabling the exposure adjustment, if you like the style of the glow. It should be relatively fast, but I really haven’t tested it much, it looked ok on the island demo.

There’s no tone-mapping, or anything fancy with the ‘HDR’ portion of it, and I really don’t think the exposure adjustment is good enough for use in a real project, but if you’re using a low variation of light it can yield a subtle, acceptable effect. Definitely has me excited about what can be done if/when Unity gets the deferred shading stuff in there, though. They’re very close to supplying what’s needed for developers to have no excuse for making a top-notch looking game, IMO.

Currently, it requires SM3, but there’s no good reason for that (according to other posts, looks like a Cg bug), I’ll likely eventually change the downsampler and fix it so it’d work in SM2, but I’m in no hurry to do that unless someone else wants it. Code’s not cleaned up either, but I’m tired and wanna go watch The Hangover :).

Note, on the color correction values, you can use the alpha channel to adjust how much influence the color has vs. the default. Also requires Unity pro, since it uses a render target for the exposure adjustment thing.

Here’s a web demo of the Unity island level.

Note, made a few more fixes and update the island demo (I had to clear my cache to get it to load new one)

240919–8646–$robspostprocessor_118.unitypackage (11.5 KB)

2

Looks great! Thanks for putting the work in to it. :slight_smile:

3

What does ‘ghetto’ mean in this context?

4

Well, the high dynamic range doesn’t really do a very high range, since it’s working with 8-bits per channel (pretty much). So, you likely have a range of about 100% higher than normal visible range, so it’s just not very ‘high range’. In practice, it just means that you can’t adjust the exposure much before noticing it and maximum brightness colors are displayed as less than maximum brightness. You also can’t react to exceptionally bright areas, like the sun flares, so looking into the sun won’t look natural with regard to blooms or iris adjustment.

Ultimately it means you just can’t throw any content or settings at it, visually it’ll break pretty quickly if you stray much from the defaults because of the low range of the source pixels. Still, it’s a bit more promising than I’d expected, and there’s a few things Unity could do to make it look really good. The best solution is to just let things render to a 16-bit per channel texture, and allow you to set a lighting multiplier. Then, for instance, you could render with a multiplier of .1, and then your final post processor multiplies it by 10, then you could have effects and lighting that could go 10 times higher than they do now. Supplying a lighting multiplier along with ability to read a render texture (at least get an average color, which is all I need here, I just need to read one pixel) would even allow the 8-bit renderer to have a decent amount more perceived dynamic range. With that I could adjust the exposure each frame, so the renderer could adjust to high ranges, even though it doesn’t ‘see’ them each frame.

Short end is that it can look considerably better than that, but I think that’s pretty close to the best I can do right now. I just wouldn’t call it HDR because compared to other renderer’s HDR, or what Unity could do, it’s gonna fall real short. My personal preference is still a deferred shading renderer with the bells and whistles, but the above improvements would allow for excellent visual improvement without much work, good bang for the buck, IMO.

I think right now, the smoother bloom and wealth of parametric settings for color correction are what’d make this post processor useful to most people.

5

Also, just remembered, although this should work on SM2 cards, I believe some of the older Radeon SM2 cards did not support 16-bit texture filtering (can’t recall for sure which ones, think 9500-9800). This means that it might work on some cards, but your blooms would look very pixelated.

6

It’s American slang which used to be equated to; place where Black people live, the same way “barrio” used to mean - Hispanic and “suburbs” used to mean - “we don’t want your kind here in our nice neighborhood”. :wink:

Now “ghetto” refers to; (adj.) jury-rigged, improvised, or home-made.

This message has been brought to you by the letter H and A and the number 7. :smile:

7

Kudos for a really awesome shader.

8

Thanks and thanks. Yea, it’s still got a few issues (the glow offsets are, well, off :)), and I wasn’t planning to fix it up proper till I was closer to releasing something with it, but if any of you guys are using it, let me know and I’ll push those changes up on my schedule. Also could post some best practices on getting good results from the iris adjustment, if anyone’s using it.

9

great work - yes me too looking forward to MRT and deferred lighting in Unity.

10

Yea, me too. Actually, after trying to dynamically light a scene, I have to take back much of my praise of Unity, their lighting system is fairly crippling, IMO. I’d forgotten how much of a difference it makes being able to, you know, add lights to a scene without having it trash my framerate :(.

11

Ahem! Just some off topic distraction for you guys, but the word “Ghetto” derives from the Venetian dialect “Ghéto” that literally means “Where metal is trown”. Basically, the part of Venice where the vast majority of foundries where located was also where the majority of jewish lived.
Because later int he 16th century Jews had to live in isolated zone of the city, basically to protect them (Venice) or to segregate them ( rest of the world), the word Ghetto was used to indicate these places

12

Heh, thats pretty much how i always understood the word ‘ghetto’. Which is why i was so confused when it was used to describe a shader :wink:

13

Hehe, apparently I shouldn’t have used that term, thought it was pretty commonly known, guess not. I’ll purge it from my lexicon :).

14

Nah, South Park has illustrated for us that the meaning of offensive words can evolve over time.

15

Hi,
I dropped a few objects into a scene (very quickly) with your shader applied. Thought you might enjoy seeing it. :slight_smile:

Scene has → 2 dynamic lights, SSAOEffect, Glow Effect, Robs Post Processor Effect

243683--8746--$screenshot_211.jpg
243683--8746--$screenshot_211.jpg750×1440 277 KB

16

Hope it helps in some way. FYI, you likely don’t want the unity glow effect, my post processor replaces it with a slightly different technique.

17

Good to know. Thank you.

18

It is perfectly possible to implement at least some deferred methods using Unity, such as light pre-pass, as it doesn’t require MRTs. You’re still stuck without real AA, and a lot of shaders need to be written/modified to work with it.

19

That wouldn’t fix the speed problem which is Unity redrawing entire meshes for each component of the lighting. You’d still need to draw the lights as primitives, all of which might be doable and efficient implemented by a source-codeless 3rd party, I don’t know Unity well enough now to say, but I’m not willing to be the guinea pig on that one. I personally still wouldn’t implement such a system, it’s not bad if all you want is simple lighting, but if you’re going through that trouble, I’d definitely do a standard material first deferred shader (since much of the work is the same anyways). With this lighting you’d lose specular quality, and lighting calculations would clamp ‘earlier’, since the texture wouldn’t be present in the calculation, so your lighting will look less natural in perhaps many cases (depending on textures). Also, some image based lighting techniques won’t work without material information, as well as likely much more can be done in terms of post processing when material information is available vs. lighting info. I think there’s good reason why deferred shading discusses writing material terms rather than lighting terms.

I think it’s perfectly reasonable to say that any deferred shading requires SM2+ hardware though, I don’t think requiring MRTs is a remotely limiting requirement for modern games (if it’s ugly in it’s fallback to 1.x shaders, those people should be quite used to it :)).

20

Point is, it is still possible to implement a lighting model that doesn’t have a huge impact on draw-calls per light in Unity’s current state. If it is of sufficient quality is a whole other matter :slight_smile: Personally, the lack of decent AA is the biggest problem. I can live with specularity being a bit off in overlapping areas.

I don’t really get this one - the overhead per light should be the same as with “traditional” deferred shading - what did I miss?