MasterEffect ReBorn official thread

Okay, the screenspace reflection thing was a really good prank But, are there any plans to add any actual screenspace reflections?

EDIT: Also, about the autofocus-duration thing: Isn't there a variable that you could adjust per frame, as in:I dunno if this works like that in shaders. Just a programmer throwing in some ideas...

GERgta wrote: Isn't there a variable that you could adjust per frame

One cannot write to variables in shaders, since they are highly parallelized and run for each pixel. All uniforms are readonly.

crosire wrote: All uniforms are readonly

Okay, thanks for the info

Hi Marty , could it adjust "DOF_SCALE" in 1.1.205 MER ? I means MER 1.1.205 how to creat a “shiny shiny” DOF like MATSO in MER1.0.340 ?

like this

Matso DoF weightings etc didn't change, only focusing. Every visual result is 1:1 reproduceable with new and old algorithm.

@Marty McFlfy

i was just looking at this re: Tilt Shift
wiki.secondlife.com/wiki/Depth_of_field

i wonder if there's a DoF algorithm that could be implemented allowing for both DoF and Tiltshift in the same way? I don't think we necessarily have the same control with current DoFs? Although I guess a specific Tiltshift shader is probably more useful in the end

I know different Second Life viewers expose different DoF parameters


and sorry yes I also missed the DoF poll!

thanks
J

marty please have a solution for enb series + Reshade?

pleaseee

Marty, I have some more questions about ambient occlusion.

I decided to take a look at SSAO again. In the most current version of the framework, SSAO looks much nicer than it did before (post 1.1.111 update). It almost looks similar to the Alchemy SAO you showcased. Am I only imagining this, or did you actually change it?

The horizontal lines I mentioned last time I wrote are still a big issue. On my laptop, they are bearable during gameplay, but on my 30 inch monitor the flickering is horrendous. I know it's happening because of performance improvements you chose to keep. Thing is, they only appear if you use the AO_Sharpness value. Anything above 0 create these lines in all AO types. If you set it to 0 there are no visible artifacts, but AO doesn't look as nice in far areas since it's very blurry now.

huss93 wrote: marty please have a solution for enb series + Reshade?

pleaseee

Following the discussion, you do not need to load ENB -> SweetFX(old binaries) -> ReShade. The only thing you could need is ENB->ReShade cause you have the latest version of SweetFX already in ReShade available.

To use ReShade with other wrappers you need an injector which is either the ENB Injector (separate from the ENB wrapper for you ENB efffects) or the GEMFX Injector (which also can be chained into an ENB wrapper before injecting ReShade).

Tried ENBInjector with GTA4 and CryENB. Hooking/redirect fails though. I'll post the log shortly

Note: normally ENB loads dax.dll, dax.dll loads d3d9_SFX.dll

Tried all combinations with & without injector, leaving out SFX, but it bombs out.

I can use the vanilla ENB, but I think a fair few features stop working anyway. I think dax.dll is mainly just for AO, so maybe that can be left out.

Since ReShade detects the API by its own name, renaming it and loading it per proxy isn't possible like that. First ReShade and then ENB also not. I have a solution that actually works but it's kinda illegal. The game has a hardcoded string for the API dll to load, example "d3d9.dll". Hex editing the game exe to load something else like 1234.dll makes the game load a different dll name. Now rename ENBSeries to 1234.dll and load "d3d9.dll" (which is ignored by modded game exe) as proxy.
And these "lines" - set the bit depth of texOcclusion 1 and 2 to RGBA16F.

Marty McFly wrote: Since ReShade detects the API by its own name, renaming it and loading it per proxy isn't possible like that. First ReShade and then ENB also not.

That's not correct. ReShade detects the API by which one the game uses, it doesn't care how it's named. The hooking method is different though and wrapping (when the same name as the DLL) is less likely to cause issues with other injectors than the other way.

crosire wrote:

Marty McFly wrote: Since ReShade detects the API by its own name, renaming it and loading it per proxy isn't possible like that. First ReShade and then ENB also not.

That's not correct. ReShade detects the API by which one the game uses, it doesn't care how it's named. The hooking method is different though and wrapping (when the same name as the DLL is less likely to cause issues with other injectors then the other way).

So why then does loading ReShade per proxy not work like that? It only works when ReShade has the proper DLL name and that's only possible when doing the stuff above.

Marty McFly wrote: So why then does loading ReShade per proxy not work like that? It only works when ReShade has the proper DLL name and that's only possible when doing the stuff above.

Because ENB does nasty things I guess? Chaining proxies isn't necessarily straigt forward.
But there is a reason you can inject ReShade via an injector tool. It doesn't work the way "normal" wrappers like ENB do. Which is why the name of the DLL is not important to ReShade.

Marty McFly wrote:

crosire wrote:

Marty McFly wrote: Since ReShade detects the API by its own name, renaming it and loading it per proxy isn't possible like that. First ReShade and then ENB also not.

That's not correct. ReShade detects the API by which one the game uses, it doesn't care how it's named. The hooking method is different though and wrapping (when the same name as the DLL is less likely to cause issues with other injectors then the other way).

So why then does loading ReShade per proxy not work like that? It only works when ReShade has the proper DLL name and that's only possible when doing the stuff above.

Proxy with GEMFX works for example cause I forward all access to ReShade. However, the way I did it is different from chaining or injection and I am not sure how ENB's wrapper or injector is implemented.

Everyone, I might remove the bloom threshold parameter because it hampers me with other algorithms, like using bloom data for fog and stuff like that, is that OK? And no, creating optional legacy mode is no option.

Marty McFly wrote: Everyone, I might remove the bloom threshold parameter because it hampers me with other algorithms, like using bloom data for fog and stuff like that, is that OK? And no, creating optional legacy mode is no option.

Can't say I like the sound of that.

the framework has a different bloom with SweetFX doesn't it? maybe we could use that instead if we needed a threshold?

to me Bloom Threshold sounds like a good idea though. Couldn't you ignore the threshold if Fog is enabled instead (rather than have a Legacy mode)?

Marty McFly wrote: Everyone, I might remove the bloom threshold parameter because it hampers me with other algorithms, like using bloom data for fog and stuff like that, is that OK? And no, creating optional legacy mode is no option.

Will that significantly change the look of our bloom that we customize per preset? I am not sure I like the sound of it being removed since it affects the end result so much. How would we control which pixels the bloom shader uses without it? I know my settings change almost every game I use it in. Your bloom is some of the best bloom I have used. I don't really like SweetFX bloom.

Marty McFly wrote: Everyone, I might remove the bloom threshold parameter because it hampers me with other algorithms, like using bloom data for fog and stuff like that, is that OK? And no, creating optional legacy mode is no option.

I trust you Marty and have loved each new update you put out, but I gotta say, I like your bloom effect just the way it is.