qUINT
- Marty McFly
- Topic Author
Please Log in or Create an account to join the conversation.
- brussell
Also with some combinations of curve, intensity and layer itensity I get inverted colors.
I'm about to release my own bloom based on your original ME bloom. It uses only two 1/4 backbuffer textures and H/V-GaussBllur10 + H/V-Gausslbur22 passes, and in my short test runs a bit faster than qInt-bloom. Though it's not really suitable for small lights.
Please Log in or Create an account to join the conversation.
- AssassinsDecree
pastebin.com/Ce4WKkgk
Tried to post the log here, got an error message the post was too long, lol. Hope Pastebin is ok, never used it before.
EDIT: ... ya know what, seems like it was because I had your old Lightroom installed while having the new one installed. Noticed one of the error messages said something about it using the same resouces as the new lightroom file or some other gopply goop I didn't understand. Anyway, deleted the old Lightroom from the shader library and lo, the error message went away (on Far Cry 5 at least, haven't tested beyond that yet).
Please Log in or Create an account to join the conversation.
- AssassinsDecree
Please Log in or Create an account to join the conversation.
- Tom Yum 72
- AssassinsDecree
Please Log in or Create an account to join the conversation.
- Marty McFly
- Topic Author
brussell wrote: Interesting bloom code . Though I wouldn't call that bloom what you can achieve with bloom layer 1-3. Imo layer 4-6 is sufficent to get a proper bloom effect.
Also with some combinations of curve, intensity and layer itensity I get inverted colors.
I'm about to release my own bloom based on your original ME bloom. It uses only two 1/4 backbuffer textures and H/V-GaussBllur10 + H/V-Gausslbur22 passes, and in my short test runs a bit faster than qInt-bloom. Though it's not really suitable for small lights.
Proper bloom is stacked blurs with variable width, using layers 4 to 6 is just personal taste and much too coarse for bloom as it's usually done. I'd suggest taking a look at how unreal engine does it. Of course, if you restrict your bloom to just one layer, you can get ahead of this bloom in terms of performance. This bloom is still under construction tho.
Please Log in or Create an account to join the conversation.
- Ryukou36
Please Log in or Create an account to join the conversation.
- moriz1
Marty McFly wrote: MXAO blur changed only, no modifications in IL. The "Auto" quality setting is new, and I decided to leave AO more blurry because you only see that in debug anyways.
i did a quick diff between the old and new versions of MXAO. and while nothing about IL changed between the two, the other changes must have some impact on how IL is calculated.
i loaded up GW2 and both shaders in debug mode. i used the exact same settings:
old MXAO:
new MXAO:
as you can see, there's a clear difference. the new MXAO doesn't have any IL applied at all. i have to crank "Indirect Lighting Amount" to ludicrously high levels for it to start appearing, and it tends to appear in completely wrong spots.
Please Log in or Create an account to join the conversation.
- Marty McFly
- Topic Author
Please Log in or Create an account to join the conversation.
- moriz1
the new MXAO's IL seems to be affected by dual layer AO: if it is enabled, IL is affected by the "Fine AO Scale" option. this wasn't the case for the older MXAO.
Please Log in or Create an account to join the conversation.
- Marty McFly
- Topic Author
And IL should be affected by the AO scale option, as 2 layer means large AO+IL and small AO+IL. I did drop the IL amount overall a bit (*4 in last pass vs *2 in qUINT) but that's all, I did this because in the main pass, the IL generation is a tiny bit different. An IL amount of 3-4 is reasonable. In my tests, the IL in the new version should even be a bit stronger than before.
Please Log in or Create an account to join the conversation.
- moriz1
Marty McFly wrote: Can't reproduce. With similar settings like yours, IL shows up just fine, tested it against latest github version with same settings as yours.
And IL should be affected by the AO scale option, as 2 layer means large AO+IL and small AO+IL. I did drop the IL amount overall a bit (*4 in last pass vs *2 in qUINT) but that's all, I did this because in the main pass, the IL generation is a tiny bit different. An IL amount of 3-4 is reasonable. In my tests, the IL in the new version should even be a bit stronger than before.
are you sure we're using the exact same version of MXAO? could it be that your copy is newer/different?
i just did a quick test: disabling two layer MXAO makes IL appear normally. with two layer enabled, IL is only applied on the fine layer.
EDIT: still doesn't appear correctly, at least compared to the older version. but definitely more noticeable, since IL is no longer confined to the thin lines that fine AO fills.
Please Log in or Create an account to join the conversation.
- rubyruby
qUINT_lightroom.fx's LUT overlay seems to differ from the neutral LUT distributed with LUT.fx though, is this the same for anyone else?
LUT.fx:
qUINT_lightroom.fx:
No other shaders were activated at the time, and all values for Lightroom were at their defaults, except for tile size and count.
Please Log in or Create an account to join the conversation.
- JBeckman
Lightroom in particular seems like it could be really useful, MXAO and the DOF one would be nice for some games too but probably going to need to toggle/remove the existing implementations to avoid overlaps if the game is recent enough to have AO or depth of field effects that is.
Bloom well perhaps, it can be a neat effect at least.
Also I noticed the included ReShade.fxh doesn't have the additions that the current version of the one in the shader repository does, probably doesn't matter too much though, something about width, height and aspect ratio from what little I can garner of it.
(And then there's something about width and height and buffer format in the Quint FXH file which I guess is for 8-bit and avoiding that HDR issue?)
Please Log in or Create an account to join the conversation.
- e371
Please Log in or Create an account to join the conversation.
- Marty McFly
- Topic Author
Can you show me screenshots from both your config tab and the tab with the preprocessor options and stuff?
The differences of the LUT: I believe that's due to rounding errors in the various CC settings. If I comment out the entire CC code, difference is 0. There's no way of avoiding this as RGB->HSL conversions are always error prone if done in float space. Image editing programs even go as far as to use lookup tables or store values as integers or use BCD math. After all, the LUT 100% maps to what happens to the image (generated LUT is 100% neutral, tiny CC changes are applied with everything set to default, it's just so small you don't see it in the regular image, only in the LUT) and you wouldn't use Lightroom anyways with default values that do nothing.
Please Log in or Create an account to join the conversation.
- rubyruby
Yeah I only noticed it because I tried to use the overlay to make a LUT from the shaders I was using previously, but I just used Ioxa's CreateLUT for that in the end instead.
It's been great otherwise, I've been having fun with it all day (: thanks again!
Please Log in or Create an account to join the conversation.
- brussell
Any reason for lerping in PS_Combine? It can lead to darkening in non-bloomed areas. Best method should be screen-add:
void PS_Combine(in float4 pos : SV_Position, in float2 uv : TEXCOORD0, out float4 color : SV_Target0)
{
...
//color.rgb = lerp(color.rgb, bloom.rgb * 128.0, 0.16 * saturate(BLOOM_INTENSITY));
color.rgb = 1 - (1 - color.rgb) * (1 - saturate(bloom.rgb * 20 * BLOOM_INTENSITY));
...
}
Please Log in or Create an account to join the conversation.
- Marty McFly
- Topic Author
Please Log in or Create an account to join the conversation.