Closed BielBdeLuna closed 3 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?
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 .
@RobertBeckebans Nice, can't wait to see it, quite fond of the technicolor effect.
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 .
@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.
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 .
@RobertBeckebans It was in fullscreen with anti-aliasing off. No rush though, I can look at the added changes at a later date.
@RobertBeckebans Glitch noise when running AA in fullscreen under Linux. Works great when AA is disabled.
@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.
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
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)
Also... for whatever reason, the flares only show up after at least one explosion for me. O.o
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?
But why does the glare effect start working only after an explosion happens?
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.
@BielBdeLuna Thanks! I'll pull that and recompile.
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
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 .
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)
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.
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
Well, yes. But of course. I'm just doing my part and reporting bugs.
you're doing a great job, sorry if I sounded rude :)
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.
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?
@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?
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.
@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?
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?
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.
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.
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.
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.
BTW my current build works perfectly in all scenes. Indoor/Outdoor and it keeps the colors quite clear.
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
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
@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:
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 .
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?
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.
how can I get the X and Y resolution being played for the shader?
Those values could be passed in using the rpWindowCoord uniform. SetFragmentParm( RENDERPARM_WINDOWCOORD, windowCoordParm ); // rpWindowCoord
ok
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?
With the current master, whenever I disable HDR using r_useHDR 0, I get the following:
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?