screenspace decals

Question

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

Ionium

Answer 1

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

Empanel

Answer 2

@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

Ionium

Answer 3

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

Scutage

Answer 4

@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

Ionium

Answer 5

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.

Scutage

Answer 6

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

Wilscam

Answer 7

@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.

Ionium

Answer 8

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.

Scutage

Answer 9

awesome! will try it out many tnx!

Ionium

Answer 10

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

Wilscam

Answer 11

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

Did you mean dFdy by any chance?

Empanel

Answer 12

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

Ionium

Answer 13

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

Ionium

Answer 14

@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.

Scutage

Answer 15

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.

Dwanadwane

Answer 16

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).

Wilscam

Answer 17

@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

Ionium

Answer 18

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

Ionium

Answer 19

@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:

Scutage

Answer 20

Okay, I took a look again and, unfortunately, didn't get anywhere. The biggest issue seems to be how the specular lighting is calculated, but I cannot figure out at all how it's supposed to work, even after tweaking.

On an aside though, I did find that the GitHub repository for the DecalCo shader has a GLES2 shader included! It also has the normal map support, though they replaced dFdx and dFdy using a different method. They have it disabled though, as I do not think they could figure it out either.

There is likely a solution, but my guess is that it would involve passing more data to the shader, like the world normals for the scene or the camera transform through a uniform.

Scutage

Answer 21

@TwistedTwigleg said: Okay, I took a look again and, unfortunately, didn't get anywhere. The biggest issue seems to be how the specular lighting is calculated, but I cannot figure out at all how it's supposed to work, even after tweaking.

On an aside though, I did find that the GitHub repository for the DecalCo shader has a GLES2 shader included! It also has the normal map support, though they replaced dFdx and dFdy using a different method. They have it disabled though, as I do not think they could figure it out either.

There is likely a solution, but my guess is that it would involve passing more data to the shader, like the world normals for the scene or the camera transform through a uniform.

no problem tnx for your time

Ionium