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 !

Screen Space Lens Flare

A few years ago I wrote a blog post describing a screen space process for rendering lens flares. I had first read about this idea on Matt Pettineo’s blog (1)...

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

GitHub - OCASM/SSMS: Screen space multiple scattering for Unity.

Screen space multiple scattering for Unity. Contribute to OCASM/SSMS development by creating an account on GitHub.

GitHub
I tweaked a bit further that fog blur and plugged in my fog function in it.
This way I can also use it to emulate height fog with it too. :)

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 !

Turns out the Love framework had a bug for a few months and wasn't loading sRGB texture properly.
Got fixed today after my report, so now colors match properly:

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:

The current idea I wanna try is doing a copy of the first downsample (full or smaller res) and blend it into the next frame downsample. Just to see if it helps with the spatial/temporal aliasing.
Will figure out ghosting issues afterward if it becomes promising.
Weeeee !

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.

A few days have passed and I finally got most of the DOF post-process working !
My hexagonal bokeh works well and is relatively cheap. I even got some nice additional effects like chromatic aberration on the bokeh itself.
The effect is done at half-resolution, I haven't figured out yet a good way to blend in back to the main image so there is a slight bleed of colors.
Example of the chromatic aberration on the bokeh:
The last detail I'm trying to figure out is how to properly fade the center of the bokeh pattern to make "holes" in the shape.
I have already something working, but it's not perfect yet:
Bonus: for fun I'm trying to do an heart shaped bokeh.
First results are quite funny, but not really useful. 😅
(I currently rethinking how I should distributes the sample to fill the shape.)
I got an heart-like bokeh shape working ! 😄

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.

Confirmed: went from 0.6 to 0.22ms on my laptop in the same scenario ! :D
Back on my DOF, because I'm not happy with this upscale pass. 💀

Ha, figured out the issue ! I was actually expanding the alpha radius during my fill pass, which created those gaps.

So it's mostly working okay now, trying to adjust how I tweak the focus range to make it easier to play with (I like the idea of a start/stop positions).

Finally !

Weeks (if not even months) or rework and I can finally render cubemaps.

Pretty happy about it, especially since the cubemap generation side of things took less than a day to write. My refactor worked out really well. :)

#gamedev #opengl #shader

"Ho yeah, I will just use cmgen from Filament to prefilter my cubemap for Radiance"

This was me two days ago.
But cmgen only output either a single ktx file or all the individual mips of a cubemap as separate files.

So now the fun part is figuring out how to stitch everything together to get a working dds file.

The even funnier part: my framework cannot load dds cubemap file, only individual faces.

This means I need a tool allows me to write a dds with custom mips, so that I produce one file per face, with support for hdr files as input.

I found none. So I'm considering building something myself via my framework, but the best format I can see myself using is RG11B10.

Ideally I should use BC6h, but for that I need an encoder that allows custom mip and HDR files as input.

I have been banging my head quite a bit the past two days.

I know I'm in corner case, but I'm once again astonished at the lack of good tooling out there for writing in this kind of format.

I would really like avoid writing my own DDS encoder, because I feel it's one of those rabbit holes it will be difficult to get out of. But it's starting to feel like I won't have a lot of options.

Last silly idea I got: storing my RG11B10 cubemaps in RGBA8 with RGBM compression instead. That will require some on the fly decoding but that's might be tolerable.
Went with RG11B10 as expected to store my cubemap. Each mip as an individual file stored as a binary blob into a common zip file per probe.
Not the prettiest but it does the job for now. I don't have to deal with RGBM at least.
Mipmap transitions are really nice now ! :D
I also had to do the pbr balls test !
No that I only take care of radiance here. There is no IBL irradiance. I will see if I do something for it or not via cubemaps.
here is what it looks like in my usual scene with the probe pushed in the back. Everything looks grayish because of the neon light in the background.

I need to rethink how I manage my lights (once again) because right now the light casting shadows are rendered as additive light, which means the IBL contributions is applied several times.

Until now I didn't have a notion of "ambient" lighting.

Working on my cubemap generation pipeline I was still puzzled on why the IBL would be so strong compared to the actual lights.

I decided to verify that my PBR wasn't broken by using red PBR balls this time and well...

Took me a day to figure out what was happening.
After checking my code a few times I isolated it out on being related to the DFG LUT.

Inverting its value (one minus) was somehow fixing the shading and brightness issue. This was very confusing.

Then I extracted the LUT from Filament and compared it from Learn OpenGL and mine.

Here is what they look like in Designer:

Notice what's wrong ?

Filament LUT use swapped Red and Green channels in its LUT.
My initial one minus trick was just a lucky fix. I'm glad I took the time to figure out what was happening.

In their doc, Filament doesn't mention that swap: https://google.github.io/filament/Filament.md.html#table_texturedfg

Anyway, once I figured this out, the fix was immediate and my shiny balls were now looking great:

So once that was working, I quickly hacked in parallax correction for the cubemap and overriden Sponza floor to be mirror-like.

It now looks really great ! Time to clean up the code and expose everything on the editor side. :D

#gamedev #opengl #cubemap

I'm looking at ways to store my shadow volumes resulting binary mask in the form of a bit mask.

The goal is storing something like 32 shadows into an RGBA8 texture to sample it later when rendering object.

Doing so will allow me to render the lit object only once (while doing IBL + casting lights + other lights).

But today I played again with the idea of mesh based light shafts.
I asked a colleague for help and it got me some convincing results !
This is basic depth evaluation, no analytical formula yet.

#gamedev #opengl #shadows

Got my bitmask idea working !
The first few lights casting shadows are now stored in an RGBA8 texture.

I added a debug view mode to display them side by side which currently displays up to 16 lights (but 32 are possible in total).

#opengl #gamedev #shader

The bitmask stuff is working properly now, it's pretty cool to watch !

#gamedev #shadows

I also converted my cubemaps into octahedral projections to be able to store them in 2D arrays, with the goal of being able to sample multiple of them easily for blending.
That new format also allowed we to compress them into BC6H more easily.
However, I'm not sure I will dive into the cubemap blending just yet. I think I need a break and I wanna play with other stuff for a while.
I'm thinking about portal/cell culling, actual portal rendering and maybe a physics engine integration.
But first... I need to fix my lights. That shadow refactor broke a few things. Like my directional lights... 😅
I have been going slow on Ombre the past few days (mostly because I'm tired right now).
I got all my light masking working again, but for spot-lights I ended-up using once again my mesh vertices projection to compute the right bounds:
cheaty, but still cool. i also think that using bitmasks just makes it looks cooler
@froyok thats supor interesting. Great work!!

@froyok Unfortunately they don't keep the documentation super up to date but my understanding is that the correct way to use their LUT is listing 30. This is because they encode the multiple scattering compensation term in the LUT as well:
https://google.github.io/filament/Filament.md.html#listing_multiscatteriblevaluation

Listing 10 shows how to recover the multiple scattering coefficient.
https://google.github.io/filament/Filament.md.html#mjx-eqn-scaledEnergyCompensationLobe

@frguthmann That's the issue with scary math like that, I'm too afraid to read it properly. :p

@froyok I can relate to that. The only reason I know about it is because I was following closely when the changes were made. It's also super cheap and easy to integrate when someone ran the math for you :p.

TLDR: rough surfaces tend to be darker than they should be because masking and shadowing terms don't account for rays that escape the micro facets after a few bounces. A precomputed multiple scattering factor is stored in the LUT to compensate for that.

@froyok Just as another reference point, we've written an accurate analytic fit for the integrated FG term in MaterialX, allowing you to render energy-compensated GGX reflections without texture lookups.

Here's the analytic fit for the integrated FG term:
https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/pbrlib/genglsl/lib/mx_microfacet_specular.glsl#L108

And here's the method that leverages integrated FG to compute energy compensation for multi-scattered GGX reflections:

https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/pbrlib/genglsl/lib/mx_microfacet_specular.glsl#L195

MaterialX/libraries/pbrlib/genglsl/lib/mx_microfacet_specular.glsl at main · AcademySoftwareFoundation/MaterialX

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. - AcademySoftwareFoundation/MaterialX

GitHub
@SheriffStone @froyok Thanks for sharing Jonathan! I'm eager to try this version. We used an analytical fit in Filament for a while but that was ~8 years ago and I had to make too many sacrifices to accuracy to keep the computations cheap enough on mobile. We got a good increase in ALUs sincr but little to no extra bandwidth.
@froyok It's not mentioned because the swap was implemented later when we added energy compensation, sorry about that.
@froyok What about RGB9E5? I saw aras mention that a few days ago and thought it looked interesting
@nick It's pretty fresh and requires specific hardware I believe, it just got introduced in DX12 so I don't know about OpenGL and also my framework would need to support it too which isn't the case yet.
Anyway, BC6h is the ideal target here. :)
@froyok It's not the highest quality, as it was targeting real-time per frame encoding on prev gen consoles, but may still be better than RGBM like encoding: https://github.com/knarkowicz/GPURealTimeBC6H
GitHub - knarkowicz/GPURealTimeBC6H: Real-time BC6H compression on GPU

Real-time BC6H compression on GPU. Contribute to knarkowicz/GPURealTimeBC6H development by creating an account on GitHub.

GitHub
@k_narkowicz Hooo, thx, this looks promising !
@froyok We store R11G11B10 in RGBA8 but without rgbm encoding. Just spread the bits. 32 bits vs 32 bits. Works as PNG files for instance. No extra decoding required.
@froyok fascinating thread. I vote for make your own tooling, as if it doesn't exist, someone else would probably use it too (spoken as someone who has written many tools that I doubt anybody used)
@shram86 It will happen at some point, it's the second time that I end-up facing a wall, but I just don't want to spend the time on it right now unfortunately. Hence my frustration. 😅
@froyok DDS reading/writing is super simple, assuming you use 3rd party compression. I find https://github.com/richgel999 the best
richgel999 - Overview

richgel999 has 56 repositories available. Follow their code on GitHub.

GitHub