Gizmos aren't Z-sorted properly with transparent surfaces

[Zylann]

Godot 3.0 alpha1 official Windows 10 64 bits nVidia geforce 940M

It depends on the viewing angle, gizmos get randomly drawn behind or in front of transparent surfaces. In the screenshot, the blue plane is slightly transparent:

[bojidar-bg]

Happened similarly on 2.2, AFAIR.

[reduz]

seen this problem, needs to be fixed, thanks for opening the issue!

On Fri, Jul 28, 2017 at 9:16 AM, Bojidar Marinov notifications@github.com wrote:

Happened similarly on 2.2, AFAIR.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/9935#issuecomment-318636904, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z22QsdAGYMNcdMyodDcLD6QBl0tYlks5sSdEJgaJpZM4Ol-Dn .

[reduz]

actually judging by your bug, i have no idea what's going on. If you can make a very simple test scene (in case it was not fixed already) i will give it a check

[HummusSamurai]

Also I am not sure if this is the right place to mention this, but the gizmos are also hidden by fog which is inconvenient sometimes.

[reduz]

@Zylann This should be properly working now (just fixed it), but please reopen if you see something different @HummusSamurai This won't change. You can disable environment if you feel gizmos are inaccessible in the viewport menu.

[Zylann]

Looks like it's fixed:

[Zylann]

Sorry, I reopened the initial scene, the problem is not fixed... I shot a video to better explain what happens:

https://www.youtube.com/watch?v=16nTnP02JIw&feature=youtu.be

Turning environment off doesn't fix the issue:

Turning also shadows off doesn't fix it either:

My graphics card shown in the log: GL 3.3 contextOpenGL ES 3.0 Renderer: GeForce 940M/PCIe/SSE2

[reduz]

Did you set the floor material as "on top"?

On Aug 29, 2017 6:29 PM, "Rémi Verschelde" notifications@github.com wrote:

Reopened #9935 https://github.com/godotengine/godot/issues/9935.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/9935#event-1226522115, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z2-jTn0aysINxsWi17609ZD6Kqjv4ks5sdIKbgaJpZM4Ol-Dn .

[Zylann]

No, it's just a transparent quad

[reduz]

also if you can make a simple reproduction demo, that would be great

[Zylann]

Well, I tried earlier^^" but only repro in this project. I can try to simplify it

[Zylann]

GizmoDrawOrder.zip Simpler project

[Zylann]

Sorry to popup again, but... it's better now, however some rogue gizmos still don't sort consistently:

(light arrow and cube bounding box)

[toger5]

looking at the commit. there is probably just this missing for the light:

 -      gizmo_hl->set_flag(SpatialMaterial::FLAG_ONTOP, true);
 +      gizmo_hl->set_on_top_of_alpha();

(maybe)

[mss1451]

Here is a MeshInstance with transparency flag. Node specific gizmos don't appear on top of it unless the render_priority of the material is -128. As seen in the picture, transformation gizmos render just fine.

Here is a MeshInstance that has a screen-reading shader. Again, can't see gizmos regardless of the depth.

shader_type spatial;
void fragment()
{
    ALBEDO = texture(SCREEN_TEXTURE, SCREEN_UV).rgb;
}

[markusneg]

Sorry for digging up this old chestnut again, but the bug is still around in 4.0.3-stable. I also had it in 3.x. It's quite easily reproducible: just set transparency of a StandardMaterial3D to another value than TRANSPARENCY_DISABLED and observe gizmos disappearing. This is an example project featuring a CollisionShape3D gizmo disappearing in front of a box-shaped MeshInstance3D: gizmos_zordering_alpha.zip.

[Calinou]

This cannot be resolved as per the 3D rendering limitations around transparency sorting.

Some workarounds have been proposed such as https://github.com/godotengine/godot-proposals/issues/2138, but they come with downsides on their own. Order-independent transparency isn't something we can rely as a baseline feature for rendering the 3D editor, as it's very slow.

[clayjohn]

Testing locally, I actually can't reproduce the issue anyway. The gizmo appears to sort fine

[markusneg]

Testing locally, I actually can't reproduce the issue anyway. The gizmo appears to sort fine

In your second screenshot the CollisionShape3D gizmo isn't visible although being in front of the cube. I should have chosen a better albedo in my test project. Those red-blue-green "spatial manipulation gizmos" never disappeared in my case. The vanishing gizmos are actually much more noticeable when environmental meshes (like a huge floor) have transparency enabled because then all the gizmos disappear. This way it's very hard to inspect and manipulate e.g. collision shapes or lights.

This cannot be resolved as per the 3D rendering limitations around transparency sorting.

Some workarounds have been proposed such as godotengine/godot-proposals#2138, but they come with downsides on their own. Order-independent transparency isn't something we can rely as a baseline feature for rendering the 3D editor, as it's very slow.

Thanks for the information. Although I don't fully understand why the red/green/blue manipulator gizmos are ordered correctly.

[clayjohn]

I see. So what you want is for all the gizmos to always appear on top? Right now they are sorted in the transparent pipeline. So if they are behind an object, they won't be visible. Is it correct that you would like them to be visible all the time, regardless of whether they are in front or behind an object?

[markusneg]

I would expect them to be visible if they are in front of a geometry. I.e. if nothing is between the object/gizmo and the camera.

[clayjohn]

In my screenshot the physics shape is behind the cube and it is correctly sorted so only the portion sticking up above the cube is rendered.

So to clarify what you are reporting:

1. You are saying that gizmos (except the translate/scale/rotate) are always appearing behind transparent objects (even when they should be in rendered in front
2. You aren't suggesting that gizmos be always on top

Is that correct now?

[Calinou]

Note that if you actually desire this, you can already choose select node gizmos to appear always on top using the View > Gizmos menu at the top of the 3D editor viewport. Click on a gizmo in the list until it has a "half open" eye icon. This means it uses the X-ray visibility mode. This will effectively resolve transparency sorting issues by not performing any sorting for the transparent object in the first place.

The only other way to resolve the transparency sorting issue is making the gizmo materials opaque and using another form of transparency instead, such as alpha scissor with dithering. This could use a checkboard pattern to look better for thin lines compared to interleaved gradient noise. This can also improve performance slightly if you have large gizmos covering the viewport.

[markusneg]

On my machine the gizmo is disappearing, regardless of which side of the cube it's on: @clayjohn: ad 1) yes, ad 2) yes, I suggest them being visible if they are not hidden by geometries and (as I now learned) being visible even when hidden when the "half open" eye is active for X-ray visibility mode. @Calinou: the X-ray visibility mode of gizmos doesn't change the behavior in my gif

Edit: changed "ad 2)" to "yes" because I spotted clayjohns "aren't"