Simple Emboss Shader

and I suppose bridges also reflect sky even if it is facing ground??
or reflective concrete??

Not complains, just saying my observation from demo pic. I'm trying to be more constructive then plain " How amazing" reply.
bumpmap or not, screen space reflection is always doable, problem is where to apply them.
you can probably flag the reflective surface by constrains or conditions.

I love debug-ish screens. They are for debug, no?

Well the one side has to reflect sky but the down facing side, I agree. I only restricted the reflections from printing close objects onto far ones but not vice versa. It doesn't gather its color in 3D space but merely 2D, that's how this effect works. See ENB, its bumpmapping works the same. But I added something 2 days ago that simulates fresnel effect so a surface with this angle to the camera won't receive much reflections anyways, this minimizes artifacts. In case you want to try to put it into full 3D space, add raymarching and all that stuff needed for physical almost-correctness, I can send you the code.

Just amazing! Way beyond what I had asked for but I was targeting OpenGL games and not GTA SA!

I guess we can spin this thread into another one for further EBM shader development?

Going to test the Emboss code soon.

A ReShade powered shader works on OpenGL, too, I just use GTASA as testing ground. Is there a free version of Doom I can get for testing (no pirated content please, legit copy)?

Marty McFly wrote: A ReShade powered shader works on OpenGL, too, I just use GTASA as testing ground. Is there a free version of Doom I can get for testing (no pirated content please, legit copy)?

Well, there's lots of options (Not only for Doom):
Quake (Shareware) + Darkplaces sourceport (I use this one + Quake Epsilon).
Freedoom, Chex Quest or Action Doom 2 + GZDoom or Skulltag
Open Arena or World of Padman (ioquake3 engine)

Marty McFly wrote: A ReShade powered shader works on OpenGL, too, I just use GTASA as testing ground. Is there a free version of Doom I can get for testing (no pirated content please, legit copy)?

Yes there is. There are two opengl engines you can also test it on:

This one is the last version that runs off OGL 2.0x and what I use for QEffectsGL since it is 2.0x based:

www.moddb.com/games/doom/downloads/gzdoom-19-pre828

The Dev builds here are OpenGL 3.0x based. Usually get the latest one which I have used with ReShade (reshade does not work with OpenGL 2.x):

devbuilds.drdteam.org/gzdoom/

Lastly, download the FreeDoom wad from here and rename it to doom.wad and doom2.wad respectively:

www.moddb.com/games/freedoom/downloads/freedoom-v09

Place it into the same directory as GZdoom.exe.

It is a base wad made with free community assets that is ~ 90+% compatible with other user made content. No copyright stuff in it. It is good enough to for testing.

I would have advise Zandronum (multiplayer opengl executable) but its OGL renderer is mainly a subset or derived from GZdoom but not 100% complete yet. Its a still many builds older than the latest GZdoom.

I'm going to test Half-Life and other older OGL/DX9 games soon too.

I added the tweakable variables to MasterEffect.h and the actual code to ReShade.fx and it appears to not be working.It does say its loading the effects but kind of sits there.

MasterEffects

I did recheck against QEffectsGL to make sure it works.

QEffectsGL

It is most noticable on the green texture parts. You can also see bloom enabled in the QEffectsGL picture. I did take a picture with no OpenGL loader and it looks the same as the ME screenshot. No effects are taking place.

@marty

I'll be testing some thoughts in enb first.

the basic idea is to use FOV and current coordinate to get outgoing ray, reflect it with normal, then sample along reflected direction and do depth check to see if reflected ray intersect with other stuff. then return the color when that happened.

kingeric1992 wrote: the basic idea is to use FOV and current coordinate to get outgoing ray, reflect it with normal, then sample along reflected direction and do depth check to see if reflected ray intersect with other stuff. then return the color when that happened.

Yes, that's how raymarching works. But it will be hella slow. And essentially Screen Space Reflections and no Bumpmapping. And the artifacts of wrongly reflected stuff will maybe be gone but you will run into another issue:

You will get samples that effectively hit the back side of an object that faces to the camera. But the depth check will return its front faced color. Or if you workaround that, nothing will get returned so you have missing data. For anything like SSDO or SSR you need 2 cameras.

for the performance, it only check local area, hence the name SSLR.
no use to check entire screen cause it still can't reflect what outside the screen.

the depth check is like this

The blue object will be reflected where the intersection point depth == sample depth,
and the black will not pass the depth check cause intersection depth = sample depth.

it is still a post process, no hidden geometry presented.

and for bumpmap, just add them to normals, it just like textured noise for normals. (noised normal == noised reflection)
or scaled it with depth so that it stick to the surface. ( did the texture overlay thing before when I'm trying to do crosshatching)

btw, ssdo does't use 2 camera, it pass coordinate of light source to postprocess, so that area under direct lighting won't get over compensated by AO.
pretty much like how enb sunsprite pass sun pos to shader.

on the other hand, ssdo do share the similarity with sslr on the 1-bump reflection.
ssdo gathers surrounding data and take the color into account if the sample point is visible to current point., while sslr only checks reflect direction.

kingeric1992 wrote: btw, ssdo does't use 2 camera, it pass coordinate of light source to postprocess, so that area under direct lighting won't get over compensated by AO.pretty much like how enb sunsprite pass sun pos to shader.

I know that depth check works like this but the ray I've drawn is the physically correct one, I also know that the screen space effect is only an approximation, just like any SSAO technique BUT for diffuse shading this approximation is way less important than it is for reflections where the slightest artifacts get obvious. But sure, go ahead, I'm exited to see me proven wrong. If that really works out, I can bury SSGI with no regrets.


And I remember icelaglace who really must know his shit telling me that correct SSDO needs two cameras. Confused me, too but that guy is part of the team who wrote Octane Render and Brigade so I trust every word of his.

...We assume that Lin (incoming radiance) can be efficiently computed from point lights or an environment map....

so a environment map(2nd cam) can work, but not necessary. extra sampling required to convert environment map to a matrix of directional light.

sslr is nothing new, most modern game had it implemented, and nor does it aim to replace GI.
it is just a cheap way to add reflection to game to make them looks even more fancier.

that's why I said better not doing it without proper flag on which surface to have reflection on, otherwise, it just brings more artifacts then visual improvements.
and most games restrict such effect on water or other reflective horizontal surface.

skyrim enb too features that, notably on silver cups or jars.
and as i recalled, minecraft also has custom shader for this on water.

Can we bump threads on here? Really hope this idea doesnt fizzle out..

Aelius Maximus wrote: Can we bump threads on here? Really hope this idea doesnt fizzle out..

Well I posted the ported code already a few pages back, what else is to do?

Marty McFly wrote:

Aelius Maximus wrote: Can we bump threads on here? Really hope this idea doesnt fizzle out..

Well I posted the ported code already a few pages back, what else is to do?

Add it to the framework!

Marty McFly wrote:

Aelius Maximus wrote: Can we bump threads on here? Really hope this idea doesnt fizzle out..

Well I posted the ported code already a few pages back, what else is to do?

I know, im terrible for skim reading threads, also the code was hidden in a spoiler flag. But great to see that it's been ported from QEffectsGL, it looks like a very small algorithm of code? Where do i put it to integrate it into the framework? I've tried to insert the code into the "custom.h" keeping the header and footer of necessary code in tact, then i copied and pasted the variables into "CustomFX_settings.cfg" I think everything is in place and I've tried to make everything correspond with each other, but its not working, obviously because im not well acquainted with importing shaders, how to make it work? Thanks in advance.

I don't really know what I'm doing either so what I do is just replace a shader already in the framework, like tiltshift or something. Just replace the code in the tiltshift.h (Or any other shader you dont use) file with the emboss code and it should work.

SirArthurStreebGreebling wrote: I don't really know what I'm doing either so what I do is just replace a shader already in the framework, like tiltshift or something. Just replace the code in the tiltshift.h (Or any other shader you dont use) file with the emboss code and it should work.

Nice. I've tried this with the custom shader but to no avail. Have you replaced another shader and implemented it yet? Does it work? I'm not fully sure what to replace because the header and footer of the shader file need to be retained i guess? Or do we just copy what marty's pasted into this thread directly into a shader file? Im supposing the variables and the shader code itself need to be separate at least. (which i've done)

Added the shader to the Framework, here is what you can use until the release:

Emboss.h in CustomFX suite folder
Add this line somewhere in EffectOrdering.cfg
Add this configuration section to CustomFX_settings.cfg
Enjoy

LuciferHawk wrote:
Added the shader to the Framework, here is what you can use until the release:

Emboss.h in CustomFX suite folder

NAMESPACE_ENTER(CFX)

#include CFX_SETTINGS_DEF

#if USE_EMBOSS

float4 PS_Emboss(float4 vpos : SV_Position, float2 texcoord : TEXCOORD) : SV_Target
{
	float4 res = 0;
	float4 origcolor = tex2D(RFX_backbufferColor, texcoord);

	float3 col1 = tex2D(RFX_backbufferColor, texcoord - RFX_PixelSize*fEmbossOffset).rgb;

	float3 col2 = origcolor.rgb;

	float3 col3 = tex2D(RFX_backbufferColor, texcoord + RFX_PixelSize*fEmbossOffset).rgb;

#if(bEmbossDoDepthCheck != 0)
	float depth1 = tex2D(RFX_depthColor,texcoord - RFX_PixelSize*fEmbossOffset).r;
	float depth2 = tex2D(RFX_depthColor,texcoord).r;
	float depth3 = tex2D(RFX_depthColor,texcoord + RFX_PixelSize*fEmbossOffset).r;
#endif
	
	float3 colEmboss = col1 * 2.0 - col2 - col3;

	float colDot = max(0,dot(colEmboss, 0.333))*fEmbossPower;

	float3 colFinal = col2 - colDot;

	float luminance = dot( col2, float3( 0.6, 0.2, 0.2 ) );

	res.xyz = lerp( colFinal, col2, luminance * luminance ).xyz;
#if(bEmbossDoDepthCheck != 0)
        if(max(abs(depth1-depth2),abs(depth3-depth2)) > fEmbossDepthCutoff) res = origcolor;
#endif
	return res;

}

technique Emboss_Tech <bool enabled = RFX_Start_Enabled; int toggle = Emboss_ToggleKey; >
{
	pass Emboss
	{
		VertexShader = RFX_VS_PostProcess;
		PixelShader = PS_Emboss;
	}
}

#endif

#include CFX_SETTINGS_UNDEF

NAMESPACE_LEAVE()

Add this line somewhere in EffectOrdering.cfg

#include EFFECT(CustomFX, Emboss)

Add this configuration section to CustomFX_settings.cfg

////----------//
///**EMBOSS**///
//----------////
#define USE_EMBOSS 1 //[Emboss] //-Gives the image a painty look

//>Emboss Settings<\\
#define bEmbossDoDepthCheck 1 //[0:1] //-EXPERIMENTAL! If enabled, shader compares emboss samples depth to avoid artifacts at object borders.
#define fEmbossDepthCutoff 0.0080 //[0.0001:0.0100] //-Preserves object edges from getting artifacts. If pixel depth difference of emboss samples is higher than that, pixel gets skipped. 
#define fEmbossPower 0.666 //[0.100:2.000] //-Amount of embossing.	
#define fEmbossOffset 2.0 //[0.5:5.0] //-Pixel offset for embossing.
#define Emboss_ToggleKey RFX_ToggleKey //[undef] //-

Enjoy

@LuciferHawk to the rescue This is fantastic, very nicely ordered, easy to copy and implement. Now i have everything copied into the corresponding files that you stated, it's kind of not compiling and throwing up a very specific line of code. \ReShade\CustomFX\Emboss.h (10, 54) : error X3004: undeclared identifier 'RFX_PixelSize'. Not sure what this means? Any additional help would be much appreciated