MasterEffect ReBorn official thread

^
As Marty said.

The log depth has a much wider range of distance in a much smaller range of values. Still that unformation has to be stored in the same 8bit value range. Retrieving the log depth is not enough to mimic the same DOF effects. We need to stretch the values to cover the entire 8 bit but having only a small fraction of 8 bit available from the log source leads to huge banding which is visible if you would use it for the linear DoF effect. So I had to use CJ dither algorithm on the banded linear log depth result and store values in 32bit instead. This process is more expensive but should not be noticeable due to only few samples. The entire process could of course most likely be improved as this is still the first implementation

LuciferHawk, I'm usually just using the DOF settings. all the options are super beneficial though. Especially with older games like The Witcher or Saboteur. SO much to apply. AmbientLight is useful. I think the framework is fine. tbh as you said the first implementation, so Ill have to let you guys do your thing. Its solid so far, never had problems. Just with V, Im not using anything other than MatsoDOF. Any explanations why Magic DOF gives me a fully white screen? like I get bloomed into complete white when I enable. EDIT--- It started to work after I relaunched the game once again.

earlier comments about performance, I had done some more testing. me being an idiot not realizing I had not taken out an old version of scripthookV with JulionNIB jc2 mods scripthookdotnet.dll which was conflicting and bogging out my games perf. Reshade had nothing to do with it. My Bad fellas.

anywho thanks for the info on the logarithmic detection. Crazy, you guys did a stellar job. first implementation I gotta remember that, I shouldn't be complaining. The framework was a brilliant Idea. Choosing options isn't hard, when you know what the game needs. not a concern for me, but the statistics logger seems real smart to check what you guys don't need. I personally use DOF mainly, but when called for, I could be using multiple shaders from each of your packs(Sweetfx/MER/GemFX) ambientlighting bloom lensdirt, DOF, and the rest to boost my colours and sharpen the image, maybe some grain. Motionblur is great for Dirt3.

The DOF did take me a while to get used to, but I did manage. I want to get something like this for all weapons naturally, can only get pistols to work, and a couple other weapons with scopes or big iron sights to function within the parameters given.

Marty McFly wrote: As I said before, I don't support keys officially until we can make key combinations.

By the way ..... Key combinations with Ctrl/Shift/Alt are supported since a few versions ago now

crosire wrote:

Marty McFly wrote: As I said before, I don't support keys officially until we can make key combinations.

By the way ..... Key combinations with Ctrl/Shift/Alt are supported since a few versions ago now

Good that I know that

Marty McFly wrote:

crosire wrote:

Marty McFly wrote: As I said before, I don't support keys officially until we can make key combinations.

By the way ..... Key combinations with Ctrl/Shift/Alt are supported since a few versions ago now

Good that I know that

This reminds me of my question a few months ago. ^^

Mhhmm... do I smell the sweet scent of progress for this topic?

Yes and no. I do have a bunch of things that I'd like to implement as separate shaders so porting them is 10 mins work but I see nothing substantial that is missing in MasterEffect. 3D LUT is planned, I have DLAA ported, some kind of LED shader, SSAA, NFAA (both shitty AA methods, way inferior to FXAA).

Oh, to finally answer why I keep insisting that lowering bit depth of textures isn't a "fix" but more of a "downgrade":

That's how AO looks when using RGBA32F. No artifacts.


That's how AO looks when using RGBA16F. Little Z fighting because of areas with "same" depth.


That's how AO looks like with RGBA8. Extreme Z fighting because bit depth is by far not sufficient.



EDIT: cleaned up first post. It was shaming how it looked before

EDIT2: picture of new improved chromatic abberation for my DOF:

Marty McFly wrote: Yes and no. I do have a bunch of things that I'd like to implement as separate shaders so porting them is 10 mins work but I see nothing substantial that is missing in MasterEffect. 3D LUT is planned, I have DLAA ported, some kind of LED shader, SSAA, NFAA (both shitty AA methods, way inferior to FXAA).

15-06-0623-281fumn.png[/img][/url]

idk if the code differs but i found someone that ported it to unity engine and said they added some things to improve NFAA , reshade.me/forum/shader-suggestions/511-can-someone-port-these idk if this would imrpove upon what you already have but if your planing on putting it in a pack hopefully that new code if its new helps improve it

Actually the ones I ported are more complex than what I see in this suggestion thread, so they most likely are even more optimized.

First of all, thank you! your work is amazing.

Game is E.Y.E: Divine Cybermancy, made in Source engine.
It seems that Master Effect can't get access to depth buffer since AO and DoF don't work, the only effects that I notice are bloom and tone-mapping.
That's strange because ENB can get the depth buffer and its' DoF effect works(although it's wonky), I was wondering if there is a quick-fix for this, as this is the Source engine after all and not new alien technology.
before; original i.imgur.com/7l7ZUmU.png (1440p)

after; original i.imgur.com/Gj2upoz.png (1440p)


Edit: One other Issue I've had with AO in another game is that it takes a couple of seconds for Master Effect to generate the AO and when I move it starts generating a new layer, it's not real-time, I would frankly rather it dropped the frame-rate to 2fps and occluded real-time, at least that way I would know how much horse power I need to run at 60fps.

Edit: By the way, I think that this(Hybrid rendering, rasterized and ray-tracing) might interest you

Edit: After scrolling a bit I saw that reply from Ioxa about taking a greyscale, inverting, levels and blend with AO to get better occlusion.
I would definitely like to add that to one of my games, I only have no idea where to put that code he posted..

I also have an answer to you, you've said that bright areas should get as much shadows as dark ones.

First an example, I stand with the sun at my back, in front of a mountain, as the mountain is steep and full of crevices it occludes itself, the problem is the algorithm doesn't seem to take the sun into account.. and what happens more often then not is that areas that are fully lit by the sun and should on no account be occluded get dark shadows.

And now the answer itself, on games that already have a nice lighting system - the technique that Ioxa suggested would work brilliantly, that is because lit areas are already lit and vice versa, only sometimes the shadows aren't dark enough, this would work a bit like contrast but without affecting the lit areas, basically deepening the shadows.(about the same effect that is of more rays processed but without further load on the system)

If AO is delayed, the depth buffer itself is delayed (thst is why it needs time to build up, first few secs depth buffer is empty) there is nothing I can do about and it is not related to code but to the game itself.
ENB and ReShade use different approaches to find the depth buffer, one might fail where the other succeeds.

About the Occlusion stuff you wrote, well, that is what SSAO is, it is not physically correct by definition. And MasterEffect already has luminance consideration so there is nothing to implement.

Psychosis wrote: First of all, thank you! your work is amazing.
...
the problem is the algorithm doesn't seem to take the sun into account..

It is still a screen space post process, not engine hack, you can't get what is not on the screen.
Just consider it as a pre-programmed automatic photo editing

and AO stands for ambient occlusion, which by definition is to ignore direct lighting.
even with some AO mod like SSDO that take the direct lighting into account, it still require the info on the light source.

It is noted that reshade 0.14.0 should be used on half life 2, is it possible that the older version has depth buffer access and the new one does not?

If so, as ME is noted to not be compatible with versions older than 0.15.0, Is it possible to patch-in the depth buffer part from 0.14.0?

I didn't understand the part about luminance consideration(rather how it's solving that problem in the following screenshot for example)



Edit: What loxa proposed is taking the "baked" shadows, and enhancing them, that will only work on games that already have baked light and shadow maps, you can use it to remove shadows that your AO wrongfully creates, invert the lit areas, delete the lit inverted blackness from the Raymarch AO pass.

As you said, it require shadow map, or light map, which are both unavailable to Reshade as its current state.

To access those internal resource will require specific mod that probably not what Reshade aim for.

It seems that you have paid attention to the wrong part of my sentence.

The important part is here: "you can use it to remove shadows that your AO wrongfully creates, invert the lit areas, delete the lit inverted blackness from the Raymarch AO pass."

You don't need to access those internal resources.

1. turn frame to greyscale.
2. contrast + eliminate dark textures that may be perceived as shadows, shadows are generally smooth and not jagged so you can eliminate them that way.
3. RaymarchAO frame + frame of white lit areas (shadows that were wrongfully generated by Raymarch become erased).
4. return edited frame.

I didn't mean that you need access to shadow maps, but that this method can only be used on games that already have shadows.

Marty McFly wrote: And MasterEffect already has luminance consideration so there is nothing to implement.

Marty, you have not answered the question, how is luminance consideration fixing this issue? the hill is clearly in shadow.

1. turn frame to greyscale.
2. contrast + eliminate dark textures that may be perceived as shadows, shadows are generally smooth and not jagged so you can eliminate them that way.
3. RaymarchAO frame + frame of white lit areas (shadows that were wrongfully generated by Raymarch become erased).
4. return edited frame.

that is roughly how luminance consideration works. I cannot eliminate shadows by "smoothness", that's not how this works, that's not how any of this works BUT I can lower the AO intensity the brighter the original image pixel is. That's what luminance consideration does. But there are some restrictions:

Just because you see something lit or not does not mean a shader can recognize it. The hill may be in shadow but lit dark objects may be darker than shadowed bright objects. There is just no way to find out if something is in shadow or not except by looking if occluded from light source which is not possible without knowing the light source position from inside the game engine. SSDO in PPFX fakes a light source so if it could retrieve the actual light source position, it would be what you are looking for but it can't.
So basically I can only use the raw brightness of a pixel as factor for AO intensity. And that's what luminance consideration does: checking how bright a pixel is and start lowering the AO intensity above a certain level down to 0 when a pixel is close to white.
That may sound cocky and arrogant but the chance that you have an idea I didn't have before is very low. I have insight in code, know exactly how things work and what can be realized and what not, while you haven't. You have no other option than to trust my word or prove me wrong with a piece of code that does what I consider impossible.

It reminds me the gold-white-blue-black dress...
without certain info, not even human brain can tell which part was shadowed and which wasn't.

And since AO isn't based on actual physics, the only reason it looks wonderful in modern AAA games is because some Art Director tweak the AO parameters "scene by scene" with coordination of direct lighting.

kingeric1992 wrote: And since AO isn't based on actual physics, the only reason it looks wonderful in modern AAA games is because some Art Director tweak the AO parameters "scene by scene" with coordination of direct lighting.

Or because the actually use SSDO with the actual light direction. But yes, can't agree more.

Basically what I'm asking Is to try out what loxa did.

I had a more sophisticated and hard to accomplish idea, but his way seems good enough without all the hard work.



His masked AO is what I need, I want to test and see if there are cases in which it prevents shadowing where shadows should be.

Is it possible for me to get his version?

Psychosis wrote: Basically what I'm asking Is to try out what loxa did.

I had a more sophisticated and hard to accomplish idea, but his way seems good enough without all the hard work.

Warning: Spoiler!

His masked AO is what I need, I want to test and see if there are cases in which it prevents shadowing where shadows should be.

Is it possible for me to get his version?

The AO luminance consideration should give the same results as what I did but give more control over where AO is and isn't applied. It's been awhile but I think the way I did it was take a gray scale of the original image and make it brighter so it covered up the AO in bright spots. I think the way Marty did it was take a gray scale of the original and use that to decide where AO is applied using smoothstep.

The way smoothstep works is it uses two values, in this case AO_LUMINANCE_LOWER and AO_LUMINANCE_UPPER, and compares them to a third value, in this case the gray scale image. Any parts of the gray scale image that are less than the AO_LUMINANCE_LOWER get full strength AO, any parts that are greater than AO_LUMINANCE_UPPER get no AO. And any parts of the image that are between AO_LUMINANCE_LOWER and AO_LUMINANCE_UPPER get a blend of AO and no AO with darker areas getting more and brighter areas getting less.

Hope that makes sense. Try experimenting with different values and see how it affects the AO. Just guessing I would think setting AO_LUMINANCE_LOWER to 0.0 and AO_LUMINANCE_UPPER to 0.8 or 0.9 would give very similar results to the screenshot I posted.

Implemented Raymarched HBAO as (hopefully) last occlusion technique (I might port SSDO of PPFX but I'm not sure since it uses fake data and is not realistic therefore) and added support for different color lookup table (16x256 ones).
Release soon after I fixed/added a few more things.