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:
Projecting points has its limitation, since the mesh may not be accurate enough.
Here for example the screen bounds (gray rectangle) miss some edges of the spot light bounds (in orange).
Trying to expand the light radius or angle to create some padding doesn't work, there are always angles where the mesh doesn't cover enough the actual spot light.
I know it's a partial/sliced sphere, but I have no idea how to analytically compute it (especially since I'm quite bad at math).

I think my next step will be to look into map building and most importantly occlusion culling and scene cell/portal splitting.

For that I started playing with TrenchBroom to build some map. I'm trying to see how I could build a pipeline around it to build meshes and import that in my engine.

Been a while, so here are some news.

I made some decent progress with Trenchbroom, I figured how to parse the map file format and output objs from it. Still have some details to iron out, but it's promising.

I also started testing custom textures and meshes:

Next I wanted to fix a bug I wasn't aware of until it was mentioned on the Graphic programming Discord: did you know that when computing the bitangent in your vertex shader you had to multiply it by an handness factor ? I didn't.

In order to fix this, I had to rework how I was writing some data in my mesh format. Took the time to split the regular geometry from the shadow volume one into separate files. (In anticipation of the geometry coming from TrenchBroom).

Fiddling around with my mesh format, I took the occasion to build a "missing mesh" warning... which is a fallback mesh for when another one will be missing. :D

And finally tonight I fixed that bitangent stuff and the result are night an day. Here is a before vs after on one of my test mesh.

#gamedev #shader

Today I finally got the TrenchBroom mesh conversion working and even a first in-engine ! :)

I also did a quick test with a non-closed mesh to see how far it was working well (or not). Notably I was thinking about how to cast shadows with meshes like fences.
...And one sided geometry actually works well !

I will have to think about a trick to make it work as two sided, but that doesn't seem impossible.

Little update:
- I'm now able to load meshes with different materials.
- Mesh are properly shifted and scaled during pre-processing, so that allows in-engine transformation more easily.
- I also added a "missing" material instead of crashing. 😄

During pre-processing I also discard some materials, which allows to get rid of hidden faces.

I have been trying out more complex stuff to see if it was working well.

Another update: I got auto-reloading or the scene and meshes working.
(It works by simply monitoring the scene source file on the engine side.)

This means I can edit my scene in TrenchBroom and get live updates in-engine on the side.

I also took this opportunity to implement a framerate limiter, this way I can save on performance while the engine is out of focus.

Okay, it's really, really fun to have this auto-update. I need to expose more stuff (like lights and cubemaps) now ! :D

So two days ago I decided to look into Open Dynamic Engine (ODE), mostly to evaluate how much works it would represent to integrate.
I was wondering how much work was needed to compile it.

Well... Compiling it was very straightforward on Linux actually. So I spent the saved time into integrating.

So now I have a bouncing ball in my engine. 😍

As for why I choose ODE and not something else is mostly because I wanted an easy to build and use C API.

Bullet is starting to be a bit outdated and I haven't found a C wrapper. Jolt wrappers aren't super up to date nor complete so far.

ODE worked out of the box, so that should be good enough for now. Hopefully performance will follow for my use-case.

Well... Guess what ? ODE is gone. ODE is fine, but requires too much work to get good performance out of it. The price of its flexibility I guess.

I switched to Jolt instead, and while the C API versions out there aren't perfect, they do the job. Getting great performance out of it with minimal tweaking.

I even got cubes working. :)

Decided to get back on cubemaps and finally tackle the blending of several of them.

I'm using a brush in TrenchBroom as the bounds of the parallax correction. The advantage is that I can share the same brush across several cubemap capture points.

Also toying around a bit to support more stuff coming from TrenchBroom map parsing.
Now I have cubemaps and point light as type of entities supported.

Okay I got the volume bounds working and even added fading so that the reflection is not visible when outside.

Now I have to think about blending between cubemaps and reflection proxies.

(I also need to do something about the octahedral seams.)

I got cubemap blending working now that octahedral cubemaps are stored in a single texture array.
It's very basic, as there is no advanced sorting yet, but it helps test things out. :)

Here for example I blend between 3 cubemaps.

#gamedev #opengl

Octahedral cubemaps can be very low quality, so I also tried out using blue noise to jitter the reflection vector to hide a bit artifacts.

Not very happy with the results however. You need a high level of jitter to hide issues and that may bias the reflections in unforeseen ways (but they are low quality anyway).

Also the jitter is static in screenspace, animating it make the original artifacts visible again because of the visual persistance. 😩

Overall, those cubemaps are really helping the lighting. I feel that my engine is starting to look really nice.
Quite happy about it ! :)

#gamedev #opengl

Did some tweak to add some padding on the octahedral textures, now the seams are (almost) all gone.
I can enjoy very shiny balls. :)

(I also added a quick reinhard tonemap to the debug preview of the cubemap since they are rendered too late in the pipeline for the editor stuff.)

So a trick I thought about today when talking with colleagues regarding my recent octahedral stuff, is to adjust the blue noise intensity used during the cubemap sampling based on the roughness value.

Also I forgot I had FXAA running, with sort of clean up the blue noise. 🤔

I noticed I haven't posted an update in a while. So where are we ?

I mostly spent September working on cubemap blending and physics.

Regarding physics, with the new wrapper I added, I got basic detection/trigger volumes working.

I also worked on converting my meshes to static collision in my levels. Then I added some refresh to ensure that moving static objects would interact well with simulated stuff (only for the editor side of things).

Quick demo below.

#opengl #physics #gamedev

Currently in the middle of a refactor for the physics handling code. Now that I have an idea of what I can do and how, it's a good opportunity to do a cleanup.

Once this will be settled (I wanna experiment a trigger volume + door opening) I will take a look at Steam Audio I think.

Demos like this makes me want to try sound related stuff: https://www.youtube.com/watch?v=hEqqzqDnuV8

Steam Audio - Ue4 basic Test

YouTube
@froyok Steam Audio is super cool. I did this test a few years ago:
@apq Woaaa ! Okay, I definitely need to try it out ! :D