Unfortunately the curve in there loose too much range, so specular reflections get really dimmed and the bloom loose in intensity.

So I tried out this instead: https://gpuopen.com/learn/optimized-reversible-tonemapper-for-resolve/

Wasn't enough either alone, so I applied the same trick did for my LUTs to compress further the range and it seems to be working.

The fog gradient doesn't seem to suffer (it was a good indication of the precision loss previously) and edges are still anti-aliased !

Alright, got it working at both end, depending on a switch. So I was able to compare.

On regular geometry edges, visually almost no differences.

BUT, doing FXAA as the last step end produce noticeable differences because it misses aliasing that has been exaggerated by some effects.

Example with my chromatic aberration effect:

Yesterday I tried once again to optimize my SSAO pass in compute, and still failed. A fragment shader still performs quite a lot better.

So today I decided to play again with my bloom and lens-flare to tinker with other ideas. Like anamorphic shapes.

Not necessarily a success, but I got interesting results just by playing with some buffers size or UVs:

Back on Ombre... and I decided to play again with lens-flares (I know 🤪 ).

This time I wanted to try out the little radial projection trick from John Chapman article (https://john-chapman.github.io/2017/11/05/pseudo-lens-flare.html) to create fake streaks. It's a good start, but I will need to think about how to refine that effect. It looks nice already !

Been tweaking my lens-flare again for the past few days and now reaching a point where I want to try some kind of anamorphic bloom.

Right now I went with a hack where I modify one of the downsample texture when it is fed for the upsample pass. It is giving me a rough idea of what to expect, but it's not good enough yet (not sharp enough, and some flickering issue to manage still).

Will likely need to do a proper downsample/upsample process too.

#gamedev #shader #postprocess #bloom

I tweaked a bit more and properly integrated my bloom streak pass in the engine.

Combined with the regular bloom and the lens-flare this is all coming together well ! :)

I couldn't stop at two bloom passes, so I added a third one to fake atmospheric scattering.

So... how much humidity do you want in the air ? 😄

It is based on: https://github.com/OCASM/SSMS
(But I'm planning on improving some things.)

#gamedev #shader #fog

This morning I also quickly tried to add some fake halation effect (light bleeding into darker areas).

It's basically a highpass filter using the bloom downsamples and the current scene color texture, and then isolating the bright parts to make them bleed into the dark areas.

Currently it's an additive blend done with the HDR color, so it adds light. It low enough to no matter too much. Maybe I should use a lerp too to be more energy preserving ?

Woops, I had a Saturate() in there when setting up the highpass. Now I get why my halation edges where so sharp ! 🙃

Also switched to a combination of mix/lerp for blending and it works as good as before. So no additional energy yeay !

I didn't notice it until today, because I decided to draw a texture straight to the screen for a temporary loading screen.

All fixed, so it looks like this now:

My current struggle.

I'm already doing the firefly attenuation based on Jimenez slides.

I'm trying to think about possible solutions:
- Clamping max brightness ?
- Reducing emissive intensity based on distance ?
- Doing some temporal stabilization (like TAA but only for bloom/fog downsample) ?

I'm open to suggestions.

I gave a try at clamping (like @EeroMutka suggested) but as I expected, because I use a non-thresholded and energy preserving bloom method, clamping kills off the HDR range and bloom becomes non-existent.

Here is with and without clamping:

First of all, this is very framerate dependent when using a fixed blend value.

Secondly, you need to weight the previous a lot to make the flicker not visible/disturbing, favoring a lot of ghosting.

Right now it's a stupid blend, so I wonder if re-projection would help a lot now. 🤔

Previous frame reprojection seems to be doing the trick !
(Combined with color clamping to hide disocclusion.)

Here is a comparison with off (blend at 1) and on (blend at 0.1). Flickering is almost gone and no ghosting seems to be visible.

It's basically TAA but on a blurry and half-resolution buffer.

So preserving details doesn't really matter. I don't even bother with jittering.

Transparency/emissive surface not writing into the depth buffer don't seem to suffer either. That's really cool because I was afraid of that !

This week I continued with my fog stuff and added local volumes of analytical fog.

It's going to be quite useful to make moody effects in scenes.

So far I got Sphere and Box shape working, but I'm thinking about doing cones (for spotlights) and maybe cylinders (for dirty liquids container or holograms).

#gamedev #screenshotsaturday #shader #fog

Combined with the screen space fog blur it can give some really neat results:

#gamedev #screenshotsaturday #fog #shader

The past few days I have been looking into optimizing the bloom downsamples, see if I could merge down into one texture and do it in one pass.

Writing compute shader is hard, I made some progress but I haven't reached my goal yet.

I'm shelving the idea for now and will go back to it at some point.

Instead I decided to finally look into rendering cubemaps.

Currently I'm not writing any code much, I'm trying to evaluate all my needs to properly build the architecture.

So far I only renderer a single point of view: the main camera. Cubemap introduce additional ones, and later I will have Portals too. So there are some rework needed in how I manage my rendering loop.

Quite a few days later and the refactoring is almost done. The engine is rendering again and this time in a more contained way, so I should be able to render cubemaps soon ! :D

I even made a neat image of my engine layout now:

With the post-process chain now working again, I thought I could try to add a depth of fieldpass as well, re-using some of the recent bokeh shader I used for my lens-flares.

It didn't go as planned, but it made some nice colors at least ! :D

I was able to get this far... using a separable filter (with Brisebois2011 method).

However I can't seem to find a good way to avoid foreground pixels to bleed into the background even when only computing the background blur.

So I decided to switch towards another method instead. That's really too bad because I really liked the simplicity of it.

Here is an example of the bleeding. I used pre-multiplied CoC but it's not enough and any kind of pixel rejection breaks the separable nature of the blur.

Here the bright lights are visible behind the limit of the character silhouette, showing the bleed into the foreground.

I'm currently looking at the Scatter & Gather approach, but I wonder if anybody tried an hybrid method. Like using S&G for small bokeh and sprites for large bokeh ? Or maybe using S&G for far DOF and sprites for near DOF ?

I wonder at which points sprites could help performance, but because large ones cause overdraw. 🤔

Progress !

Got Crytek kernel computation working, very fun to tweak on the fly ! (Generated CPU side then sent to the shader as a buffer of sampling positions.)

Focus range isn't yet working, that's the nest step.

I didn't make a lot of progress the pas few days, thx to Helldivers 2.

I managed to try out some optimization tricks this week however to improve my shadow volumes. One worked, the other didn't.

I tried to use a custom projection matrix with different clip planes to constrain the rendering to the light volume.

I even went with masking the depth buffer by the light radius to help discarding triangles/fragments via the depth test.

It didn't improve performance, it even made things slower on my old laptop. 😩

Like when I used the depth bounds extension at the time, this tricks had almost no impact and I presume the extra cost was coming from the depth buffer copy stuff.

So this is making me think that performance improvement will only come with smarter geometry setup.

I think I need to look in ways to subdivide the geometry but in a less taking way during the compute pass.

The optimization that actually worked meanwhile was the fact I was launching threads during my compute dispatch just to discard them afterward in the shader code.

Now instead I launch exactly the number I need and compute a better index for processing my geometry.

So just helping the GPU schedule things better gave me 0.04ms saving on around 140K meshes (went from 0.1ms to 0.065ms). That's on my beefy GPU, I presume on my old laptop this will be even better.