MovingBlocks / Terasology

Terasology - open source voxel world
http://terasology.org
Apache License 2.0
3.69k stars 1.34k forks source link

Light Shafts Improvements #3064

Open emanuele3d opened 7 years ago

emanuele3d commented 7 years ago

Introduction

It appears that the current implementation of the Light Shafts (also known as God Rays or more scientifically Crepuscular rays) basically takes the image resulting from the pre-postProcessing nodes and scales it up and progressively fades it out, repeatedly, blending the iterations together into a specific FBO. The result is then added on top of the existing rendering.

This creates a nicely convincing effect in most areas of the image, i.e. in the distance, but is deficient in a number of aspects:

  1. held-in-hand objects, i.e. torches but even non-light emitting items, produce their own light shafts projecting away from the main light
  2. when the main light goes beyond the a hill, the landscape itself "casts" light shafts of colors matching the landscape (see image below, i.e. the "shadows shafts" cast by the dark face of the sand blocks)
  3. even when the main light goes under the horizon light shafts are cast generated (Now fixed)
  4. light shafts are also generated in a cave - i.e. dig in a hill toward the main light

terasology-170813233028-1152x720

The Solution

Problems 1, 2 and 4 (probably) can be solved by generating light shafts using the same algorithm but a different starting point. Specifically, rather than use a full rendering of the environment around the player we can use the sky (inclusive of main light) masked out by everything else being rendered in black. This would make sure only the silhouette of the environment generates the light shafts.

From a realism perspective however, close objects (i.e. hand-held items) shouldn't generate light shafts. The method above wouldn't address this as a hand-held object would still create (in some circumstances) a black silhouette against the sky.

For this reason the black rendering of the environment around the player should be mediated by the depth information: far away surfaces beyond some threshold should be rendered fully opaque, while nearer surfaces would progressively become more transparent, eventually becoming completely invisible near the player. In this scenario, far away hills would generate light shafts, middle-distance trees would generate thinner light shafts, while the hand-held item would generate no light shaft.

Warning: the solution described above is meant to address the above-water light shafts. Underwater light shafts will require some additional thinking and special handling.

Problem 3 can be solved by fading out the whole light shaft effect as the sun goes beyond some threshold angle under the horizon. Notice that in real life light shaft may still be visible for a while even when the sun moves under the horizon, due to Earth's curvature. (Fixed)

Furthermore, the shallower the angle of the light rays with the Earth surface, the more visible the light shafts are, as they go through up to 40 times more atmosphere then they do when the sun is overhead. Conversely, when the sun is at the Zenith, lights shafts would be visible only if the atmosphere is dense with particles, i.e. smoke or high humidity.

(That been said, fog beyond some density threshold scatters the light so efficiently that light shafts should disappear anyway and everything becomes just a blur).

Going the Extra Mile

Light shafts in real life are generated by particles in the air scattering light toward the viewpoint. If the particles are bigger, i.e. when there are many water droplets suspended in the atmosphere, the scattering is more efficient and the light shafts are more visible. If the air is cleaner, the light shafts are less visible.

For this reason we should also tie the transparency of the light shafts to some biome-based airTransparency parameter. Steamy biomes, i.e. a tropical jungle, would be characterized by a low transparency value, resulting in more visible light shafts, even when the main light is overhead. On the other hand, mountain biomes known for their crisp air would be characterized by a high airTransparency value, resulting in thin light shafts when the sun is just over the horizon and invisible light shafts when the sun is overhead.

In this context it should be noticed that the airTransparency could be part of a single RGBA "airTint" biome parameter, the alpha channel representing the transparency discussed so far.

Going the Extra Light-Year

The current algorithm works for a single light source, when the camera is pointing in the source's general direction. Light shafts may be visible even when the camera is pointing away though - currently they fade out in that circumstance.

Furthermore, multiple lights might be generating light shafts - imagine lanterns going through some misty forest at night. The current algorithm can't handle that unless we use it repeatedly for each light source, but what if there are dozens of torches around the player?

And eventually we might have projected lights, which would generate light shafts only in the direction of the light cone but not necessarily toward the camera.

Tackling these last problems would be a big bonus.

brylie commented 5 years ago

Here are a few more screenshots of the light shafts, from recent play testing.

Shafts underground in Dwarf Hall really bright white from floor tiles screenshot from 2019-02-03 13-37-12

Shafts from stone in a mine, causing the stone to look like it is emitting light: screenshot from 2019-02-02 21-16-10

Shafts from flowers and other objects at night: screenshot from 2019-02-02 19-44-46

jdrueckert commented 5 years ago

Hi, I perceived that the light shafts of torches planted on the ground only shine into one direction. On all other sides it stays rather "dark":

Dark side: 🍪 190408_Torch-Issue_dark-side

Bright side: 🐍 190408_Torch-Issue_bright-side

Furthermore, it seems as if the light shafts don't shine in the direction that I face when planting a torch, but always the same direction.

Torches planted looking in different directions: 190408_Torch-Issue_light-shaft-side

If you check the direction of the light shafts over the pass of one day, you can see that the direction changes as the sun does.

brylie commented 5 years ago

The game Equilinox has a Devlog video where the main developer explains how they implemented light shafts. https://youtu.be/Qk22EpwAJZQ?t=89

It boils down to a couple of things:

  1. render the scene in black and white
  2. render a directional blur outwards from the Sun's position

Equilinox does have day/night cycle, so this might serve as a good example of how to achieve this effect.

In order to toggle the effect at night, it might be as simple as checking the game clock and disabling the effect during certain game hours.

syntaxi commented 5 years ago

This is half fixed as of #3682. They no longer emit from the sun when that is underground. This fixes a large chunk of the visible issues with the shafts, but doesn't tackle points 1,2 or 4. Those are still open for fixes.

brylie commented 5 years ago

Here is how the CRYENGINE implements sun shafts: https://github.com/CRYTEK/CRYENGINE/blob/main/Engine/Shaders/HWScripts/CryFX/Sunshafts.cfx

brylie commented 4 years ago

I just tried out the 4.0.0 release. The light shafts are still very intense and emanate almost everywhere including the center of trees

Screenshot from 2020-09-20 23-10-10

The effect is so overpowering it somewhat detracts from the game.

What about disabling this feature until the implementation is improved? What are some considerations with regards to using volumetric lighting for these rays?

brylie commented 4 years ago

@Cervator would this be a good issue to put on the board for Hacktoberfest?

brylie commented 4 years ago

From what I can tell, volumetric fog is probably the best way to produce these light shafts.

brylie commented 4 years ago

For an example of an open-source game engine written in Java, the Oreon Engine has atmospheric scattering as well as light scattering/lens flare.

Oreon Engine atmospheric scattering

light scattering / lens flare

Cervator commented 4 years ago

@brylie I guess it might be a good Hacktoberfest issue if we mark it as not necessarily easy - somebody would probably need some degree of rendering familiarity to have a chance at it. Our rendering setup with DAG and such should be more stable now, so no more overhauling likely to disrupt everything else again soon. Although I'm a little less sure about the state of shaders.

brylie commented 4 years ago

Here are links to some relevant code in the Oreon Engine:

pollend commented 4 years ago

I would love a replacement to how god rays works in the game. we have some really bad cases of overexposure where where everything is pretty much washed out in a bright haze. would be nice to either remove some of this or use a different default configuration.