Next pass shader renders differently in editor and debug mode

Godot Version

v4.5.stable.mono.official [876b29033]

Question

I tried the next pass shader feature by having one shader which sets the materials albedo to red and another to green. I expect the latest color in the next pass chain to be the one shown - this is indeed so in the editor but not in debug, where the first color is instead shown, as if there was no next pass. Is this a bug in Godot or am i missing something? (See attached gif)
next_pass

Some development: Upon restarting the editor, next pass now does nothing in the editor - that is, in both editor and debug, only the first pass color matters. Is this the expected behavior? I would have expected the last pass to render last and thus overwrite previous colors.

Try incrementing the render priority of the next pass.

Problem was related to vertices being identical, displacing e.g. the green plane shows both colors.


Found the answer in this post: Next pass in StandardMaterial3D is not working · Issue #76537 · godotengine/godot · GitHub

I was expecting a second render pass to not care about what happened in the previous pass, but seems like there is some sort of parallel render queue going on: Standard Material 3D and ORM Material 3D — Godot Engine (stable) documentation in English

This should sometime work, if the problem is with opaque queue: Standard Material 3D and ORM Material 3D — Godot Engine (stable) documentation in English. In my case it was duplicated vertex coordinates. GPU land is a strange and magical place :mage:

Umm, increasing the priority of the next pass should work without any vertex displacement, if neither of shaders messes with vertices or alters the depth write.

Should it? The docs for render priority explicitly state “Priority alone cannot force opaque objects to be drawn over each other”.

The shader for my original post was only

void fragment() {
	ALBEDO = vec3(0.0,1.0,0.0);
}

and indeed render priority had no effect on which color was rendered.

I find “Next pass” a confusing name as it is does not strictly mean “take the screen pixels from previous render and add the new render on top of it” but rather refers to a step in the opaque/transparent render queue:

Is this Jack Sparrow!!!
Sorry I can’t stop my self…

1 Like

It’s not objects though, it’s passes. You have only one object.

This is some strange behavior:
green_red_prio

Created new project, green/red fragment shader, MeshInstance3D with plane mesh, geometry override with first green then red shader in next pass, Camera3D for debug view

  • In debug the plane is always green, disregarding next pass prio 1 or -1
  • In editor the green shader first shows up as green, then turns red when adding a red next pass shader, also disregarding any combination of render prio.

Are we on the same version normalized? Looks like we do the same thing but get different results? Does your render prio affect Camera3D view in debug?

Hmm, I was trying with 4.3.

In 4.5 it behaves exactly as you describe. For the opaque passes I’d expect render priority to have no effect at all and that’s how I remember it working. I actually though it was strange it behaved the way I described in 4.3.

The expected behavior is what happens in 4.5 editor. Have no idea why it doesn’t do the same at runtime.

Will have to investigate this…

Seems that runtime tries to optimize by not rendering the next pass if it’s opaque. Would expect it to optimize away the bottom pass instead. If you add ALPHA = 1.0 to the top pass shader, forcing it to transparent pipeline - it will be rendered. The priority still won’t have any effect because the first pass is opaque. If both passes write to ALPHA then changing the priority works as expected as both are considered transparent passes.

This inconsistency between editor and runtime is strange though. The devs should say something about it.

The strange thing though is that even if the second pass is not shown (the plane appears green) at runtime, the monitors show 2 draw calls were issued which suggests 2 passes were indeed rendered. Hmm… something’s not right here.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.