screenspace decals

DJM

ive found "DecalCo" on the godot asset packs site however the shaders dont compile in godot 3.4 is there an alternative? now im using the simple way of spawning a quad with a transparent texture

Megalomaniak

There was some updates to shaders and shader lang in 3.3 IIRC so one would likely have to simply update the shaders.

DJM

@Megalomaniak said: There was some updates to shaders and shader lang in 3.3 IIRC so one would likely have to simply update the shaders.

i have no idea on how to update those shaders, thats why i asked

TwistedTwigleg

I have some (limited) experience with decals. I'll see if later today (or worse case tomorrow) if I can get it working with Godot 3.4

DJM

@TwistedTwigleg said: I have some (limited) experience with decals. I'll see if later today (or worse case tomorrow) if I can get it working with Godot 3.4

oh , that would be great to get decalCo working again, tnx or another shader based projections decals

TwistedTwigleg

Okay, I found out what the issue is with the DecalCo shader. It works in GLES3, but in GLES2 it doesn't work because the shader uses dFdx and dFdy, both of which require GLES3 in Godot. I haven't found a replacement solution for the functions yet though, but I will keep an eye out. Once that is fixed though, it should be pretty simple to get it working.

I did test the decal shader I posted on the Godot Shaders website and it works though! It is a pretty simple shader though. I have a slightly more complicated Shader setup on GitHub, but it requires an additional Viewport to render all the normals and isn't very flexible (more of a demo than anything).

There's also a screenspace decal system here on GitHub that looks interesting, though I haven't tried it in Godot 3.4.

cybereality

Funny, I had to implement dFdx and dFdy to get my render scaler working in GLES2. Here is the code:

vec2 deriv_x(vec2 pos, vec4 frag, vec2 pixel) {
	vec2 offset = vec2(pixel.x, 0.0);
	vec2 pos_plus = pos + offset;
	vec2 pos_minus = pos - offset;
	int coord = int(frag.x) / 2;
	bool even = int(coord * 2) == int(frag.x);
	return even ? (pos_plus - pos) : (pos - pos_minus);
}

vec2 deriv_y(vec2 pos, vec4 frag, vec2 pixel) {
	vec2 offset = vec2(0.0, pixel.y);
	vec2 pos_plus = pos + offset;
	vec2 pos_minus = pos - offset;
	int coord = int(frag.y) / 2;
	bool even = int(coord * 2) == int(frag.y);
	return even ? (pos_plus - pos) : (pos - pos_minus);
}

And you pass in UV, FRAGCOORD, and 1.0 / VIEWPORT_SIZE

DJM

@TwistedTwigleg said: Okay, I found out what the issue is with the DecalCo shader. It works in GLES3, but in GLES2 it doesn't work because the shader uses dFdx and dFdy, both of which require GLES3 in Godot. I haven't found a replacement solution for the functions yet though, but I will keep an eye out. Once that is fixed though, it should be pretty simple to get it working.

I did test the decal shader I posted on the Godot Shaders website and it works though! It is a pretty simple shader though. I have a slightly more complicated Shader setup on GitHub, but it requires an additional Viewport to render all the normals and isn't very flexible (more of a demo than anything).

There's also a screenspace decal system here on GitHub that looks interesting, though I haven't tried it in Godot 3.4.

decalco looked promising as it supports normal maps, i dont really need screenspace decals( my decals dont need to be animated or move.

TwistedTwigleg

Okay, I got it sort of working thanks to @cybereality's functions! It now renders as a decal on the screen and has normal map support, but something with the view angle/direction isn't totally working:

I think it's probably just something small that is slightly off, as it seems mostly right sometimes. I needed the dFdx and dFxy functions to work with Vector3's as well, so I made a function for it as well, but it's possible that maybe that's where the issue is with the normal map? I'm not totally sure but I'll try to take another look at it soon to see if I can figure it out.

I also had to remove the animation part of the shader though, as in GLES2 it was causing the shader to render everything as completely white. The code is still there, but it's commented out. I also noticed that in GLES2 the glow environment effect doesn't work very well because of of the lack of HDR.

I've attached the project with the progress I've made currently.

DJM

awesome! will try it out many tnx!

cybereality

It might be VIEWPORT_SIZE. Though that should work, I just pass in the resolution as a uniform in my shader.

Megalomaniak

@TwistedTwigleg said: I needed the dFdx and dFxy functions to work with Vector3's as well

Did you mean dFdy by any chance?

DJM

works great. i dont really see the normal map issue.

DJM

ah there does seem to be a normal map issue depending on the view angle

TwistedTwigleg

@cybereality said: It might be VIEWPORT_SIZE. Though that should work, I just pass in the resolution as a uniform in my shader.

Ah okay. I'll give it a try and see if passing it as a uniform works better

@Megalomaniak said:

@TwistedTwigleg said: I needed the dFdx and dFxy functions to work with Vector3's as well

Did you mean dFdy by any chance?

Yeah, my bad! :sweat_smile:

@DJM said: ah there does seem to be a normal map issue depending on the view angle

Yeah, it works okay sometimes, but it isn't consistent for all angles. That's why I think it's probably something minor that is causing the issue.

Calinou

I also noticed that in GLES2 the glow environment effect doesn't work very well because of of the lack of HDR.

Glow will work if you decrease Hdr Threshold in Environment to a value below 1.0, as described in the class reference.

cybereality

If you are using the collision normal to show the decal that may be why. AFAIK the collision normal in Godot is totally wrong and never worked (at least since I've been using it). The work around I found is to use look_at with the collision point (as the collision position is accurate).

DJM

@cybereality said: If you are using the collision normal to show the decal that may be why. AFAIK the collision normal in Godot is totally wrong and never worked (at least since I've been using it). The work around I found is to use look_at with the collision point (as the collision position is accurate).

yes collision normal doesnt appear to give correct results, maybe thats the issue

DJM

@TwistedTwigleg did u found some time to look at the normal map issue?

TwistedTwigleg

@DJM said: @TwistedTwigleg did u found some time to look at the normal map issue?

Not yet, sorry! The week was unexpectedly extra busy and I completely spaced it in the chaos. I’ll take another look today :+1: