RobertBeckebans / RBDOOM-3-BFG

Doom 3 BFG Edition source port with updated DX12 / Vulkan renderer and modern game engine features
https://www.moddb.com/mods/rbdoom-3-bfg
GNU General Public License v3.0
1.38k stars 247 forks source link

HDR issues: we might need also a blue shift effect? #266

Closed BielBdeLuna closed 3 years ago

BielBdeLuna commented 8 years ago

the idea that to the darkest to which we adapt the less colour we see could make the effect more interesting. don't you think?

ghost commented 8 years ago

A Colour fade with distance as the environment becomes darker? Could be an interesting effect, especially for horror games.

Shadows and darkness has blue values, so it would be more realistic to add colour into the darkness, since nothing is pure black.

Will the desaturation/hue shift be based on the depth buffer on it's own render pass or a post process?

RobertBeckebans commented 8 years ago

I already added a blue shift effect yesterday by adding the Technicolor post process effect.

2015-12-24 13:43 GMT+01:00 Yetta1 notifications@github.com:

A Colour fade with distance as the environment becomes darker? Could be an interesting effect, especially for horror games.

Shadows and darkness has blue values, so it would be more realistic to add colour into the darkness, since nothing is pure black.

Will the desaturation/hue shift be based on the depth buffer on it's own render pass or a post process?

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/266#issuecomment-167105501 .

ghost commented 8 years ago

@RobertBeckebans Nice, can't wait to see it, quite fond of the technicolor effect.

RobertBeckebans commented 8 years ago

You can try a pre-release build: https://dl.dropboxusercontent.com/u/22890478/RBDOOM-3-BFG/RBDOOM-3-BFG-1.1.0-win32-20151224-git-5ed5b8.7z

2015-12-24 13:59 GMT+01:00 Yetta1 notifications@github.com:

@RobertBeckebans https://github.com/RobertBeckebans Nice, can't wait to see it, quite fond of the technicolor effect.

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/266#issuecomment-167106919 .

ghost commented 8 years ago

@RobertBeckebans Thank you for the build. Having issues installing VSE 2013, can't change directory after HDD failure. Might have to reinstall Windows for it...

Build runs, started new game, ended up with a black screen, only the gui shows and the game sounds. Tried disabling soft shadows to if it was the cause, did not help.

RobertBeckebans commented 8 years ago

There are still some bugs that I haven't sorted out. Avoid resizing the game when anti-aliasing is enabled.

2015-12-24 14:37 GMT+01:00 Yetta1 notifications@github.com:

@RobertBeckebans https://github.com/RobertBeckebans Thank you for the build. Having issues installing VSE 2013, can't change directory after HDD failure. Might have to reinstall Windows for it...

Build runs, started new game, ended up with a black screen, only the gui shows and the game sounds. Tried disabling soft shadows to if it was the cause, did not help.

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/266#issuecomment-167113760 .

ghost commented 8 years ago

@RobertBeckebans It was in fullscreen with anti-aliasing off. No rush though, I can look at the added changes at a later date.

aFoxNamedMorris commented 8 years ago

@RobertBeckebans Glitch noise when running AA in fullscreen under Linux. Works great when AA is disabled.

ghost commented 8 years ago

@RobertBeckebans removed old BFG installation and did a repair through steam. The game is running fine now, the tone mapping looks fantastic, the only problem is strong lighting sources which burns out texture details, I'm guessing that needs to be tweaked through the new hdr cvars.

aFoxNamedMorris commented 8 years ago

Why not just make a hue shift with changeable values? Like r_tintHue <0-255>, and r_tintValue <0.0-1.0>?

The hue would have 0 be blue and 255 be red. The value would be how much tinting to apply, 0.0 being none and 1.0 being full.

Ona a side note, the HDR flares need to get at least some of their color from the texture that the flare is emitting from. The color of the flares should probably be affected by the other CVARs I just proposed. I personally wouldn't mind a slightly blue color grade, but I would like the option of keeping 75% of the actual color. XD

BielBdeLuna commented 8 years ago

technically their colour is derived by the sample in the spot, and gets multiplied by blue tones (generally blue tones but there are some reds too)

aFoxNamedMorris commented 8 years ago

Also... for whatever reason, the flares only show up after at least one explosion for me. O.o

BielBdeLuna commented 8 years ago

the "flares"? you mean the "glare" post process? the glare post process is made on top of the tonemapper I think, but I don't know what values are send to the glare fragment shader, apparently the fragment shader that does the glare can't paint higher than 1.0f values per channel (nor can detect higher than 1.0f values), so this means I can't produce specific glares for over 1.0f color values (per channel) which would be cool.

@RobertBeckebans can you explain the relation between the tonemapper, the HDR source rendered images, and the glare. As I see the glare at the moment it's just a classic bloom filter that doesn't have any of the benefits of the HDR-led bloom filters, isn't it?

aFoxNamedMorris commented 8 years ago

But why does the glare effect start working only after an explosion happens?

BielBdeLuna commented 8 years ago

It shouldn't, it should be on since he first frame! I modified the tonemapper to back to the original one Robert posted, maybe it has to do with the tonemapper, I modified it in order to get the adapting HDR back again.

aFoxNamedMorris commented 8 years ago

@BielBdeLuna Thanks! I'll pull that and recompile.

BielBdeLuna commented 8 years ago

no need to pull anything, you just need to deactivate a line in the tonemapper and activate a line that it's already there search for the lines I mentioned in https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/270

RobertBeckebans commented 8 years ago

Bloom and glares are the same and they are usually done after the tone mapping. I only need the HDR values and the relative luminance Yr to determine which pixels survive the bloom threshold value. Usually you need 2 bloom effects: one is very large scaled with a blue shift ( that is the one I implemented ) and it only affects the really bright spots and the other one is more a radial blur of the original color. If you look at it with r_hdrDebug 1 then you see the luminance as a heatmap. The white spots should cause the blue shift glare and the red ones the radial blur. The radial blur/bloom is still missing although it is also that kind of blur that I never liked. The current setup is more similar to the Bladerunner Movie.

2015-12-28 9:47 GMT+01:00 Biel Bestué de Luna notifications@github.com:

no need to pull anything, you just need to deactivate a line in the tonemapper and activate a line that it's already there search for the lines I mentioned in #270 https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/270

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/266#issuecomment-167515172 .

BielBdeLuna commented 8 years ago

I did the radial achromatic bloom, and modified yours so it should be a little bit more speedy, the radial one the way I did it is just plainly wrong, but it's a start, it should be done with a copy of the image at half res scaled at double scale for a more pleasant result instead of with multiple samples.

Robert the tonemap that you pushed last it's static, is it the way you intended?

should we deactivate the flares generated with the flare texture since we do it already per pixel with the bloom effect? could we have a simple bluring + original samples for foggy areas?

now I'll pull request my new round bloom and my modified tonemaper (it just a revert of the last change)

aFoxNamedMorris commented 8 years ago

Well, the uncommenting/recommenting worked. The glare now behaves as expected... But with either configuration, the outdoor areas of Erebus 6 are almost pitch darkness.

BielBdeLuna commented 8 years ago

wel you have to keep in mind that doom3 and roe were done without HDR in mind, so it is to be expected that adding new features to the engine breaks the original games somewhat

aFoxNamedMorris commented 8 years ago

Well, yes. But of course. I'm just doing my part and reporting bugs.

BielBdeLuna commented 8 years ago

you're doing a great job, sorry if I sounded rude :)

aFoxNamedMorris commented 8 years ago

Thanks! You're fine. We're cool. :3

EDIT: Well, folks setting 'r_hdrContrastOffset' to 4096 looks much better, as the flares are far more subtle whilst maintaining their intended aesthetic.

BielBdeLuna commented 8 years ago

I've made a pull request (https://github.com/RobertBeckebans/RBDOOM-3-BFG/pull/274) with my last Bloom changes (the round bloom and the blue streak), I made it showing up everywhere but not overblowing everything so it stays classy, it needs:

r_hdrContrastOffset = 0
r_hdrContrastThreshold = 8

do you guys like it?

aFoxNamedMorris commented 8 years ago

@BielBdeLuna Not seeing much of a difference. I used: 'git clone https://github.com/BielBdeLuna/RBDOOM-3-BFG D3BFGHDR-Biel --branch HDR_bloom' to get the initial pull from your repo.

Did I do this incorrectly?

BielBdeLuna commented 8 years ago

try:

git clone https://github.com/BielBdeLuna/RBDOOM-3-BFG.git --branch=HDR_bloom

so you get the files, in fact you only need this file: https://github.com/BielBdeLuna/RBDOOM-3-BFG/blob/HDR_bloom/base/renderprogs/hdr_glare_chromatic.pixel put in your base/renderprogs and you should see the difference right away when you start from scratch or reloadshaders if you're already on.

aFoxNamedMorris commented 8 years ago

@BielBdeLuna That did it, thanks! Looks MUCH better. However, setting 'r_hdrContrastOffset' to 100 looks slightly better IMHO.

EDIT: Hmm. It appears that the Contrast Offset value is better with different values, depending on the area. On a side note, the color grading looks kinda comical in Hell. Purple-tinted trippy lava. XD

EDIT2: So HDR tonemapping breaks while in (almost) any outdoor areas. Is there any way to compensate for this?

BielBdeLuna commented 8 years ago

again this is due doom3 not being made for HDR, the sun shines as much as a fluorescent, and the sky texture is as bright as a monitor, is a uphill battle, an unattainable one, this is a feature for mods and other games made with the engine not for the doom3 games.

r_hdrContrastOffset it's the brightness of the blooming, and r_hdrContrastThreshold is the point at which the blooming starts, isn't it?

now on technical side, this uses 9 samples for the blue streak and 9 * 4 = 36 samples for the achromatic round blur, I think this is highly inefficient, we should find a way to minimize those numbers, maybe the round filter could be done with a copy of the bloom image with it's resolution cut in half and scaled back again by two? this would make the effect less GPU wasteful but more GPU memory wasteful maybe?

aFoxNamedMorris commented 8 years ago

Hmm... That's a tough trade. I think the more important question is as follows: If the tonemapping/HDR cannot work outdoors at all ever, then the effect(s) should be abandoned, should they not?

I hope I have not misinterpreted your words, Biel.

BielBdeLuna commented 8 years ago

no, it's perfect for mods and new games made with the engine, it's only that doom3 isn't made with HDR in mind, HDR is the natural evolution to any 3d engine, it's a must.

it all goes around the idea what is this engine for? is it only to enhance doom3 or is it there to do something else? OTE shows that there is a will to use this engine for a greater good than just to enhance doom3 and ROE.

I myself have taught a boy how to do games with this engine, essentially mapping and scripting, and there is the potential for much further with this excellent engine.

aFoxNamedMorris commented 8 years ago

To be fair, back in the original Doom 3, Sikkmod managed HDR without making the outdoor areas dark. I think it's just a matter of figuring out why exactly it happens and patching it. After all, RBDoom3BFG is about being the Doom 3 that BFG Edition failed to be.

RobertBeckebans commented 8 years ago

I tried your HDR_bloom branch and I had no bloom at all :(

I made a new preview build based on the SMAA branch https://dl.dropboxusercontent.com/u/22890478/RBDOOM-3-BFG/RBDOOM-3-BFG-1.1.0-preview1-win32-20151224-git-090fbf0.7z

I only imlemented SMAA 1x so far. It was necessary because real HDR with 16 bit floats and MSAA didn't work well with all those post process effects like heat haze. I went into many driver problems using MSAA. However the SMAA code is a very good starting point for the other modes like SMAA T2x which is essentially what UE4 does.

RobertBeckebans commented 8 years ago

BTW my current build works perfectly in all scenes. Indoor/Outdoor and it keeps the colors quite clear.

RobertBeckebans commented 8 years ago

And here are some screenshots how it should look like:

RBDOOM-3-BFG 1.1.0 lighting preview Deltalabs 1
RBDOOM-3-BFG 1.1.0 lighting preview Phobos 1
RobertBeckebans commented 8 years ago

Shit links are broken and another try

RBDOOM-3-BFG 1.1.0 lighting preview Deltalabs 1 http://imgur.com/a/E7MZ9

RBDOOM-3-BFG 1.1.0 lighting preview Phobos 1 http://imgur.com/a/VG3KO

BielBdeLuna commented 8 years ago

@RobertBeckebans if you want to see my bloom you just need to change this file: https://github.com/BielBdeLuna/RBDOOM-3-BFG/blob/HDR_bloom/base/renderprogs/hdr_glare_chromatic.pixel

and change those:

r_hdrContrastOffset = 0
r_hdrContrastThreshold = 8

I'm looking forward to the SMAA work! :+1:

RobertBeckebans commented 8 years ago

That is what I did.

2015-12-30 15:20 GMT+01:00 Biel Bestué de Luna notifications@github.com:

@RobertBeckebans https://github.com/RobertBeckebans if you want to see my bloom you just need to change this file: https://github.com/BielBdeLuna/RBDOOM-3-BFG/blob/HDR_bloom/base/renderprogs/hdr_glare_chromatic.pixel

and change those:

r_hdrContrastOffset = 0 r_hdrContrastThreshold = 8

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/266#issuecomment-168009295 .

BielBdeLuna commented 8 years ago

well I haven't changed anything else than your bloom, you don't see the bloom?

try to lower the r_hdrContrastThreshold = 0 this should overbloom the image, that's not how I intended it to be but it should show-up the bloom. Obviously this will need a "reloadshaders"

do you see any over-blooming with this?

BielBdeLuna commented 8 years ago

tried the effect in windows at 1920x1080 and it looks very different than what I see, and I bet this is due the resolution at which I usually work which is very low, that's the reason @aFoxNamedMorris saw my effects like they where overblown (I don't know why @RobertBeckebans can't see the effect at all, Robert I tried the effect in my windows machine an I see it perfectly)

the bloom is highly dependant of the resolution: the more overbrights pixels there is in the screen the more reinforced it is, so this means we should do the blur of the blooming with percentages of the screen-space, and try to control it's exposure taking into account the resolution at which the effect is being played.

BielBdeLuna commented 8 years ago

how can I get the X and Y resolution being played for the shader?

RobertBeckebans commented 8 years ago

Those values could be passed in using the rpWindowCoord uniform. SetFragmentParm( RENDERPARM_WINDOWCOORD, windowCoordParm ); // rpWindowCoord

BielBdeLuna commented 8 years ago

ok

BielBdeLuna commented 8 years ago

the line SetFragmentParm( RENDERPARM_WINDOWCOORD, windowCoordParm ); // rpWindowCoord Is already setup in the c++ code, isn't it? you already implemented it, isn't it?

to get the actual resolution you have to inverse the value given by the components X and Y of rpWindowCoord with: float2 window_resolution = float2( 1.0 / rpWindowCoord.x, 1.0 / rpWindowCoord.y );

so, if I have this sampled color:

float4 color = tex2D( samp0, fragment.texcoord0 + float2( float( i ), 0 ) * rpWindowCoord.xy * scale );

where this is the coords of the sample: float2 sampled_coords = fragment.texcoord0 + float2( float( i ), 0 ) * rpWindowCoord.xy * scale;

to invert the position of the calculated sample I think you need to do the following: inverted_coords = window_resolution - sampled_coords

but when I use the inverted_coords:

float4 color = tex2D( samp0, inverted_coords );

I only get a fixed bloom effect only on the upper right corner of the screen when a bright pixel touches that corner, I also tried this to no avail: inverted_coords = windowCoord - ( 1.0 / sampled_coords );

any idea how to get the inverse coords of the sampled coords?

romulus2k4 commented 8 years ago

With the current master, whenever I disable HDR using r_useHDR 0, I get the following:

http://pastebin.com/fhZ4TrfB