Delivering physically correct lighting computations (it is real!)

Talk about anything related to Unvanquished.
User avatar
illwieckz
Project Head
Posts: 777
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Delivering physically correct lighting computations (it is real!)

Post by illwieckz »

Yes that was a mistake of mine, I misclicked the button to edit and quote. The phpBB UI is confusing as both admin buttons and non-admin buttons have same shape and color and the edit button is actually more accessible (most centered) than the edit button (the most off-center). Sorry for that.

I'm not sure I reverted 100% of your message, but I remember having quoted and responded to everything you said, so if something is missing it's very minor words linking two sentences together.

This comment is licensed under cc ​​by 4 and antecedent. The Crunch tool is awesome!

User avatar
killing time
Programmer
Posts: 180
Joined: Wed Jul 04, 2012 7:55 am UTC

Re: Delivering physically correct lighting computations (it is real!)

Post by killing time »

illwieckz, we have been talking about totally different groups of shaders. The ones I'm concerned about are ones that use blending in some way. These would include any multi-stage shader (unless it's just multiplying the lightmap) and any translucent shader. Shaders that use blending are the ones that have the potential to look massively different depending on the rendering pipeline. The ones you have shown here are single-stage opaque shaders, but with use of multi-texturing: normal, specular and glow maps. These can look slightly better or worse, but generally I assume that they will still be acceptable in both rendering pipelines. Indeed, the translucent medistation cross shader's appearance differs most between the rendering pipelines.

Here's a couple of translucent shader examples that are definitely wrong with linear blending. We have glass that is too dark on Vega, and the atcshd forcefield looking wrong. The plat23 forcefield is bad too.

unvanquished-vega-water-plants.jpg
unvanquished-vega-water-plants.jpg
unvanquished-atcshd-forcefield.jpg
unvanquished-atcshd-forcefield.jpg

I hope we won't release sRGB-aware map builds with a bunch of shaders that are broken because they haven't been migrated to the new color space. The linear colorspace is a very nice technical achievement, but players will see it as a bad thing if we ship defective assets.

User avatar
illwieckz
Project Head
Posts: 777
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Delivering physically correct lighting computations (it is real!)

Post by illwieckz »

No one disagrees on the fact those blending shaders look wrong this way.

The fact they look wrong is part of why I suggest to do a minor release shipping the new pipeline in engine so more people can actually test maps on some test servers, so we can polish assets for the linear pipeline experience for the major release.

This comment is licensed under cc ​​by 4 and antecedent. The Crunch tool is awesome!

User avatar
killing time
Programmer
Posts: 180
Joined: Wed Jul 04, 2012 7:55 am UTC

Re: Delivering physically correct lighting computations (it is real!)

Post by killing time »

With the atcshd Armoury example, I was curious about whether the differences are more due to the different precomputed lighting, or changes in how models are rendered. So I made a screenshot using the naive rendering pipeline, but with the sRGB-aware map build:

unvanquished-atcshd-human-base.jpg

So it seems to me that the less shiny armory and telenode are mostly due to specular maps being weaker in the linear pipeline. I don't know if that's better or worse; depends what materials they're supposed to be made out of. At some point we may want to add a colorspace-dependent fudge factor to the specular maps so that stuff can look more equal between renderer modes.

Regarding the human model, his skin certainly does look better in linear mode! The armor seems a bit worse though. The leather-like and metallic materials probably should be a little shiny. The yellow armor looks dull and flat in the linear screenshots.

User avatar
cu-kai
Web Crew
Posts: 79
Joined: Fri Jan 02, 2015 1:29 am UTC
Clan: CU

Re: Delivering physically correct lighting computations (it is real!)

Post by cu-kai »

killing time wrote: Wed Jul 30, 2025 12:24 am UTC

Image

illwieckz wrote: Sun Jul 27, 2025 5:11 pm UTC

Image

Where have the shadows gone here? (and these two are just the most obvious ones IMO)

Web Raccoon

User avatar
illwieckz
Project Head
Posts: 777
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Delivering physically correct lighting computations (it is real!)

Post by illwieckz »

cu-kai wrote: Wed Jul 30, 2025 12:59 pm UTC

Where have the shadows gone here? (and these two are just the most obvious ones IMO)

In the first screenshot in Vega, lights are all round the room, the only place where you can realistically expect shadows are between aquariums, and only light shadows because there is still direct lights coming in. There is just less light coming in, hence the shadow. If you get other shadows in that room, that's a bug:

Image

And in that Parpax screenshot, the shadows are everywhere they are expected, accurately expressing the lack of light intensity that doesn't come from where there is an obstacle.

Image

Actually this screenshot is a very good example of correctness, we see the projected light and the shadow on the pipe are physically accurate according to the direct light source position and the whole lighting of the room:

Image

I remind that shadows are not projected areas of darkness, shadows are lacks of projected light that don't contribute to the existing lighting.

Or minds have been deceived by 20 years of brokenness.

This comment is licensed under cc ​​by 4 and antecedent. The Crunch tool is awesome!

User avatar
illwieckz
Project Head
Posts: 777
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Delivering physically correct lighting computations (it is real!)

Post by illwieckz »

Here is the Tremulous build for the metro map. On that first screenshot (Tremulous build), the lack of light between the left side of the corridor (tank and trunks) and the right side of the corridor (shelves) is NOT a shadow, but the broken result of both a broken light attenuation, broken light baking, and broken light blending equations that accumulate brokenness together.

Also the lack of light between us and the horizontal neon on the corridor ceiling, on the background when the corridor reaches the staircase is not a shadow but a mix of four brokennesses: misuse of point light, broken light attenuation, broken light baking, broken light blending.

Image

Here is a local build of my current local branch for Unvanquished leveraging the most accurate things we have: nofast light attenuation, linear light baking, linear light blending, light emitting shaders).

On that second screenshot, the shadow is the lack of light projected from the right vertical neon that doesn't reach the floor because of the shelf pillar. That is a shadow. And the light on the corridor ceiling is correct.

Image

This comment is licensed under cc ​​by 4 and antecedent. The Crunch tool is awesome!

User avatar
Sweet
Dretch
Posts: 59
Joined: Tue Dec 07, 2021 8:22 am UTC

Re: Delivering physically correct lighting computations (it is real!)

Post by Sweet »

idbeholdl

User avatar
illwieckz
Project Head
Posts: 777
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Delivering physically correct lighting computations (it is real!)

Post by illwieckz »

Another example with the metro map. On the Tremulous build (first), the almost-black darkness between the right spot lights on the round ceiling are not shadows. Shadows are the lack of lights behind the tubes and small pillars. On the maps built with the linear pipeline, there are shadows everywhere, but we sometime miss them because we look elsewhere when looking for shadows. We look elsewhere because our mind was deceived to expect random darkblotches that were not shadows and we forced ourselves to believe they were shadows to pretend the game looked nice.

Image

Image

This comment is licensed under cc ​​by 4 and antecedent. The Crunch tool is awesome!

User avatar
illwieckz
Project Head
Posts: 777
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: Delivering physically correct lighting computations (it is real!)

Post by illwieckz »

Here is another very good example from the Metro map. See on the first screenshot on the ceiling how the “shadow” looks like to be painted over the light? And what is that dark blotch on the right of the train ETA indicator panel? How the light even doesn't reach the bottom wall despite having massive light rails? We can also notice how hat ETA indicator panel is abnormally dark despite being very close to a massive light rail!

Image

Notice how in that second screenshot (yet again, using the best we have all the way down), how the light is much more natural and physically accurate, and shadows are much, much, much more accurate. For example the shadow behind the chairs are perfect! The lighting between the train platforms is physically accurate. The good thing with this map is that it is modeled from real places I can check physically and take photos from.

Image

There are two incorrect things remaining in that last screenshot though, because the light rail doesn't spawn directed-enough lights, the projected shadows on left and right from the opposite light rail is a bit too much, but that's the limitation of q3map2, we would need something like Blender Cycles to get something better here. The other incorrect thing is that the actual train tunnel is now a bit too bright, but this is not because we use a corrects equations, but because the mapper put there a rosary of neon lights within the tunnel itself. But that's not how metro tunnels are made. But this is how should look a tunnel with weak neon lights everywhere (I may have to weaken them a bit to keep that idea from the mapper while aiming for more accuracy). Notice that here, reaching realism is not anymore about using proper equations but about describing the world realistically.

This comment is licensed under cc ​​by 4 and antecedent. The Crunch tool is awesome!

Post Reply