You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal was to highlight the square tile map cell over which the mouse cursor is currently hovering with a simple shader. However, when switching the render engine from Forward+ to Compatibility or vice versa, the behavior of the shader changed unexpectedly.
The shader is of type canvas_item and looks as follows:
// ADAPTED FROM: https://www.youtube.com/watch?v=7nTQA_6CL6M
shader_type canvas_item;
uniform vec2 globalMousePosition; // DESCRIPTION: Input from GDScript
uniform vec2 tileSize; // DESCRIPTION: Input from GDScript
varying flat vec2 vertexPosition;
varying flat vec2 vertexRaw; // REMARK: Only for debugging purposes
void vertex() {
vertexPosition = (MODEL_MATRIX * vec4(VERTEX, 0.0, 1.0)).xy; // DESCRIPTION: Take transformations into account
vertexRaw = VERTEX; // REMARK: Only for debugging purposes
}
void fragment() {
float isWithinY = step(vertexPosition.y, globalMousePosition.y) * step(globalMousePosition.y, vertexPosition.y + tileSize.y);
float isWithinX = step(vertexPosition.x, globalMousePosition.x) * step(globalMousePosition.x, vertexPosition.x + tileSize.x);
float isWithin = isWithinY * isWithinX;
vec4 textureColor = texture(TEXTURE, UV);
COLOR = mix(textureColor, vec4(0.7,0.0,0.0,1), 0.7*isWithin);
/* DESCRIPTION: FOR DEBUGGING PURPOSES ONLY
// DESCRIPTION: Raw Vertex Color Data
COLOR = vec4(vertexRaw, 0.0, 1.0);
// DESCRIPTION: Normalized Vertex Color data;
// VALUES: number of horizontal tiles per screen = 20.0, tile width = 64.0 px,
// number of vertical tiles per screen = 8.0, tile height = 64.0 px
COLOR = vec4(vertexRaw/vec2(10.0*64.0, 8.0*64.0), 0.0, 1.0);
*/
}
During the debugging, I took a look at the raw vertex color in the tile set
as well as the raw vertex color of the complete screen
and the normalized vertex color of the complete screen
It is not only limited to the TileMapLayer Node used for the example. It could also be reproduced for e.g. Sprite2D
Vertex data (VERTEX) is presented in local space (pixel coordinates, relative to the Node2D's origin). If not written to, these values will not be modified and be passed through as they came. The user can disable the built-in model to world transform (world to screen and projection will still happen later)...
From this statement and the vertex color visualization, the expected behavior would be that shown by the Forward+ render engine.
Probable Cause
It cannot be related to the implementation of the step() function, since the issue also occurs when viewing the raw/normalized vertex colors. This points towards an inconsistency in handling VERTEX.y between the Compatibility and Forward+ render engines, probably occuring during the parsing of the GDShader to GLSL and Glslang/SPIR-V respectively.
Affected Nodes and Versions
Any Node2D (including Control Nodes) which can have a Shader Material attached to itself
So far, this behavior could be reproduced for all stable versions of Redot 4.x (including Redot 4.3 at the time of writing) and due to the nature of the issue should be platform independent (issue could be confirmed for/tested on Windows, Linux and Web).
The issue is inherited from Godot and there present in Godot 3.x as well as Godot 4.x. In Godot 3.x, the Open GLES 3.0 shows the same behavior as Compatibility in Godot 4.x (tested for Godot 3.5 and newer).
Steps to reproduce
Create a scene with Redot 4.3-stable (or any other version of Redot 4.x) with at least an object which has the above shader attached to it and forward the global mouse position to it. Alternatively: Download the example project attached to this issue (Remark: Example requires due to the usage of the TileMapLayer Node Redot 4.3-stable and newer!).
Two Options:
- Option 1: Swap the render engine each time between Compatibility or Forward+ and reload the project. Then run the project natively with F5/F6.
- Option 2: Set the render engine to Forward+ and run the project natively with F5/F6 for testing the behavior of Forward+. Run a Remote Debug Session in a browser to test the behavior of Compatibility (Remark: works due to the fact that in Redot 4.3-stable, the web export is not Vulkan based, but no matter what the default render engine is, will utilize Compatibility).
Tested versions
Tested with Redot 4.3-stable
Also affects:
System information
OS and hardware independent
Issue description
The goal was to highlight the square tile map cell over which the mouse cursor is currently hovering with a simple shader. However, when switching the render engine from
Forward+
toCompatibility
or vice versa, the behavior of the shader changed unexpectedly.The shader is of type
canvas_item
and looks as follows:During the debugging, I took a look at the raw vertex color in the tile set
as well as the raw vertex color of the complete screen
and the normalized vertex color of the complete screen
It is not only limited to the
TileMapLayer
Node used for the example. It could also be reproduced for e.g.Sprite2D
Expected Behavior
Independent of the render engine, the result should be the same, since the documentation documentation for
CanvasItem
shaders states:From this statement and the vertex color visualization, the expected behavior would be that shown by the
Forward+
render engine.Probable Cause
It cannot be related to the implementation of the
step()
function, since the issue also occurs when viewing the raw/normalized vertex colors. This points towards an inconsistency in handlingVERTEX.y
between theCompatibility
andForward+
render engines, probably occuring during the parsing of theGDShader
toGLSL
andGlslang
/SPIR-V
respectively.Affected Nodes and Versions
Node2D
(includingControl
Nodes) which can have aShader Material
attached to itselfWindows
,Linux
andWeb
).Open GLES 3.0
shows the same behavior asCompatibility
in Godot 4.x (tested for Godot 3.5 and newer).Steps to reproduce
Redot 4.3-stable
(or any other version of Redot 4.x) with at least an object which has the above shader attached to it and forward the global mouse position to it. Alternatively: Download the example project attached to this issue (Remark: Example requires due to the usage of theTileMapLayer
NodeRedot 4.3-stable
and newer!).- Option 1: Swap the render engine each time between
Compatibility
orForward+
and reload the project. Then run the project natively withF5
/F6
.- Option 2: Set the render engine to
Forward+
and run the project natively withF5
/F6
for testing the behavior ofForward+
. Run aRemote Debug
Session in a browser to test the behavior ofCompatibility
(Remark: works due to the fact that inRedot 4.3-stable
, the web export is not Vulkan based, but no matter what the default render engine is, will utilizeCompatibility
).Minimal reproduction project (MRP)
To obtain the vertex color output, simply comment in/out the respective lines in the shader
mrp_canvasItem_redot4-3_tileMapLayer.zip
The text was updated successfully, but these errors were encountered: