Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Fixing saturation with additive blending by faking HDR  (Read 293 times)
0 Members and 1 Guest are viewing this topic.
Offline theagentd
« Posted 2014-05-13 15:50:21 »

Pixels on the screen can have colors between 0 and 1. It's common when rendering particles with additive blending that the result of the addition is over 1.0, in which case the value is simply clamped to 1. This looks really bad.

Here's a picture of a glowy circle being rendered on top of a gray background. The background has the color (0.5, 0.5, 0.5) while the circle has the color (1, 1, 1) at the center and fades out to (0, 0, 0) at the edges. The circle is rendered with additive blending (
glBlendFunc(GL_ONE, GL_ONE)
= simply add the color on the screen together with the color we're rendering).

You'd have to be blind to not notice the big white circle in the middle where the color was clamped to 1.0. In fact, the center is actually (1.5, 1.5, 1.5) after the additive blending!


Many 3D games use high dynamic range rendering to solve this. They essentially render to a render target that can hold values over 1.0, and then run the final color through a tone mapping function to convert it to a value between 0.0 and 1.0 again. The main goal of this is to convey the difference in brightness to the user better. Currently, the player sees the whole clamped area as 1.0 when the middle part is actually 50% brighter than the edge of the clamped area. The simplest tone mapping function is f(x) = x / (x+1), which has this graph:

As you can see, the value goes towards 1.0, but it never actually reaches it. That means that regardless of how bright a pixel is, there's always a brighter color available (theoretically at least). That allows us to represent values that are brighter than 1.0, allowing us to differ between a somewhat bright pixel with an intensity of 1.0 and looking into the sun which has an intensity in the hundreds.



Unless we start meddling with frame buffer objects, HDR textures and tone mapping shaders, we can't do this the right way. What we can do is mess with the blending function in an attempt to get a behavior similar to the above function. Here's the exact same scene as above, but this time I'm using
glBlendFunc(GL_ONE_MINUS_DST_COLOR, GL_ONE)
instead.


This blend mode works a bit differently. Instead of simply adding together the incoming colors, we don't let them go over 1.0. This is achieved by scaling the circle's color with how much we have left until we reach 1.0 which is (1 - destination color). Here's an image displaying the process:


With this blend mode, if we were to repeatedly blend in 0.5 onto the screen we'd end up with the following colors after X iterations:
0: 0.0
1: 0.5
2: 0.75
3: 0.875
4: 0.9375

Our screen can no longer be saturated to 1.0 unless we explicitly write 1.0 to the screen!

Here's a comparison between
glBlendFunc(GL_ONE, GL_ONE)
and
glBlendFunc(GL_ONE_MINUS_DST_COLOR, GL_ONE)
when rendering 5 of the above circles on top of each other.

glBlendFunc(GL_ONE, GL_ONE)
:


glBlendFunc(GL_ONE_MINUS_DST_COLOR, GL_ONE)
:



Although the normal additive blending actually is brighter on the screen since most of the pixels are (1, 1, 1), using GL_ONE_MINUS_DST_COLOR better conveys the fact that those superbright pixels have very different intensities.


EDIT:

Here's a more interesting example where the center of the circle has the color (1.0, 0.5, 0.25) and 10 circles stacked together:
glBlendFunc(GL_ONE, GL_ONE)
:


glBlendFunc(GL_ONE_MINUS_DST_COLOR, GL_ONE)
:

Myomyomyo.
Pages: [1]
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (16 views)
2014-08-28 18:26:30

CopyableCougar4 (25 views)
2014-08-22 19:31:30

atombrot (38 views)
2014-08-19 09:29:53

Tekkerue (34 views)
2014-08-16 06:45:27

Tekkerue (32 views)
2014-08-16 06:22:17

Tekkerue (20 views)
2014-08-16 06:20:21

Tekkerue (30 views)
2014-08-16 06:12:11

Rayexar (66 views)
2014-08-11 02:49:23

BurntPizza (43 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!