Image-Based Lighting for PBR.

[Deperture]

So, we've got a BRDF, we have HDR, materials are being worked on...

Is Image Based Lighting planned before PBR? Or is it already there?

I'm assuming this is a required step for PBR, so I'll put a document if anyone needs reading material.

Image Based Lighting

[BielBdeLuna]

Image Based Lightning, do you mean Probe Based Lightning, where every probe is a cube-map rendering of the environment surrounding it?

[Deperture]

Possibly? I've only really seen it referred to as Image Based Lighting, but searching Probe Based Lighting only gave me results for IBL.

[nbohr1more]

Image based lighting is either a cubemap or a spherical harmonic reduction of 1 or more cubemaps. It is not required for a PBR workflow but is often seen as part of one or associated with one. Anything that is based on the way that light "Physically" works counts as "Physical Based Rendering" which sorta means that even the original Doom 3 is PBR (or at least closer to it than it's contemporaries).

[BielBdeLuna]

it could be seen as an elaborated diffuse light from infinity or form the sky, and using a lot of probes can be used for GI or for static reflections a la Remember Me

[samzanemesis]

Fox Engine actually uses a pretty clever way to dynamically place cubemap light probes around the map which could be applied to the Doom 3 engine without much (or at all) mapper's consent, they've made a talk in GDC 2013 talking about it

https://www.youtube.com/watch?v=FQMbxzTUuSg

Getting this to work and resampling it a few times as faux GI passes (not every frame obviously, but only when needing computation) could give an entire new look to the Doom 3 engine :+1:

[BielBdeLuna]

from that video I think the most interesting idea is the view dependant roughness. the probe based lightning is what everyone is doing now, and I think some automatic processing for mapping could be developed, first to reduce the number of places to put a probe (the less probes the more real time it can be I guess) and since probes can be of different sized we could exploit that fact. An automation just like how AAS creates appropriate ai meshes but for lightning probes.

But this would bring a static GI what about moving lights? or pulsating lights? for pulsating lights (and since light in the real worlds is additive) we could have two light probes, one for the light off (that is the space when it's not illuminated by that light in specific, but might be illuminated by other light sin the scene) and another with the effect of the specific light at 100% brightness (and all other lights remain off), then multiply this 100% probe by the current light value, and add the resulting probe to the first probe.

for moving lights (that is lights that either rotate, change size, or change position) the only solution I could think is a mesh of small probes relegated to the space under the influence of the moving lights, limit this mesh of small probes to the absolute space those lights affect and which remain inside "habitable" space (not inside walls), in order to limit the processing of such effects. like a voxelized space. where every voxel is a light probe

[RobertBeckebans]

@samzanemesis thanks for the video. It is very interesting but there isn't too much information about the envprobe placing itself. I already digged into the subject because I implemented PBR into another engine. The technique I want to implement here is http://gdcvault.com/play/1015312/Light-Probe-Interpolation-Using-Tetrahedral

[samzanemesis]

@RobertBeckebans @BielBdeLuna I had thought about it for a few days, we could place probes in a 1³, 2³ or even a 3³ array for each area of a visleaf depending on the settings the mapper or the player put when generating them, then they can be stored in the filesystem to avoid reprocessing them (Or even set some probes to be re-rendered dynamically)

To avoid much shader complexity when applying the result we could simply store two results, one unblurred and one blurred (As for diffuse and reflective surfaces), the blending would still be believable for a 50% glossed surface, both textures can be fairly low res (64²x6)

I'm having a read on the technique in your link and it seems very similar to what HL2 and Overgrowth do, while it doesn't allow for dynamic shiny surfaces it'd be probably be better to implement

[BielBdeLuna]

I wonder if all the probes affecting the player could be stored in an atlas texture, just the 3 or 4 probes affecting the player, and have this probes be re-rendered at half-speed or real time speed. Unfortunately the cube-map renderer I added some time ago, wasn't fast at all, but then again it was my code porting from Dhewm3, and I'm no coder at all, we might have to find a way to re-render stuff more quickly. (!) In OpenGL 3.1 there is GL_ARB_draw_instanced, maybe with this could some form of instantiation be applied in order to render the same scene, from the same center of view (but different directions of view, like in the probes/cube-map), or even speed up the re-rendering done by shadow-mapping, maybe like saving all the static models (like the whole level) and repeated models ( at least those that are not skinned ) into instances?

[RobertBeckebans]

I think there is no atlas texture needed and also no rerendering of the objects. You simply fetch the 3 nearest cubemaps on a per object or per vertex level and interpolate between them using barycentric coordinates. All cubemaps in a level could be stored into a samplerCubeArray similar I used for the shadow mapping. I already prepared a branch that allows spawning of environment probes and flooding them through the BSP portals. Only the cubemap capturing and BRDF integration is missing.

https://github.com/RobertBeckebans/RBDOOM-3-BFG/compare/master...RobertBeckebans:IBL-environment-probes

[BielBdeLuna]

Robert is it useful the skybox gen that I pullrequested some time ago? it was slow but it created the cubemap around the player.

[ghost]

Is it the same as the cubemap generation for reflections found in ioQuake3?

[BielBdeLuna]

it generates the cubemap around the player, disabling the HUD, and the weapon, and rotating the player 90º in every direction, readjusting the resolution of the renderer to the resolution of the texture, to end up taking a screenshot for every direction.

[ghost]

So it creates a 360º cubemap reflection real-time?

[BielBdeLuna]

no, a cubemap, whether if you use it on a reflection or whatever is up to you (I think you have to reverse it for reflections), and it's definitively not real-time, but maybe if you do tiny cubemaps like 8x8 pixels or 3x3 pixels textures just for the ambient light, then maybe is speedier?

[ghost]

tiny textures could work well to fake dynamic lights. There is a mod for vanilla doom 3 which adds dynamic lights to the weapons, which looks good when firing the plasma rifle or BFG but hits the FPS hard when too many shots are fired after one another. Could maybe have a probe following the player to create a reflection of the character on high gloss surfaces.

[BielBdeLuna]

atm I guess it's normal that the branch is un-compilable due the missing code:

CMakeFiles/RBDoom3BFG.dir/d3xp/Light.cpp.o:(.rodata._ZTV10idGameEdit[ZTV10idGameEdit]+0x30): undefined reference to `idGameEdit::ParseSpawnArgsToRenderEnvprobe(idDict const, renderEnvironmentProbet)'

[RobertBeckebans]

No you only need to run CMake again

[Methelina]

If i understand right there are a lack of radiance information of the direct reflection. I see the GGXImportanceSampling on the place but no code for the second sum of the specular-reflection propagation, to save the space here I suggest a part from my whitepaper about it, may be it will help to implement full IBL

Torrance-Sparrow Microfacet BRDF. High optimised specular model with none-conventional Fresnel term (Horner expression term via Spherical Gaussian resolve) https://docs.google.com/document/d/1LOMEdVQSiS_KKjWlpdo_icXQpMZ99ePgveAopMPGZwo/edit#heading=h.qexmw37cg0fn

---

And btw, if we talk about GI solution. The best way not to use a voxel cone tracing as was suggested above. Its quite inefficient and huge, when i was in the Crytek we implement different fast and very efficient and stable method for real time GI know as CLPV - cascaded light propagation volume, its a surfel/RSM based solution invented by our R&D chef Anton Kaplanyan. If you interested i can share the code samples of this technique.

[RobertBeckebans]

Actually I resumed my work and I'm upgrading RBDOOM-3-BFG to PBR this year. I will make a bigger blog post about the implementation but I took some screenshots of the IBL & PBR progress: https://imgur.com/a/rWSPmD4