wireframe debug mode doesnt work

[Gibbz]

Wireframe debug doesnt work on 32d8b99 get_viewport().set_debug_draw(Viewport.DEBUG_DRAW_WIREFRAME);

[ghost]

Yes it's not working on : Godot 3.0 Beta x64

get_viewport().debug_draw = get_viewport().DEBUG_DRAW_WIREFRAME;

[brainsick]

If you manually call VisualServer.set_debug_generate_wireframes(true) it works.

Example

``` todd@todd-ab28d3:~/repos/remote/brainsick-godot-tests/tests/qa$ cat issues/15149-3d.gd extends SceneTree func _initialize(): var viewport = get_root() viewport.debug_draw = Viewport.DEBUG_DRAW_WIREFRAME VisualServer.set_debug_generate_wireframes(true) # this var camera = Camera.new() var mesh_instance = MeshInstance.new() mesh_instance.mesh = CubeMesh.new() mesh_instance.transform.origin.z = -5 camera.add_child(mesh_instance) viewport.add_child(camera) # main test body func _iteration(delta): test_viewport_wireframe() quit() func test_viewport_wireframe(): # how could we test this? before/after image? assert(true) todd@todd-ab28d3:~/repos/remote/brainsick-godot-tests/tests/qa$ time ~/Downloads/Godot3.0Beta2/Godot_v3.0-beta2_x11.64 -s issues/15149-3d.gd No touch devices found OpenGL ES 3.0 Renderer: AMD Radeon (TM) R9 Fury Series (AMD FIJI / DRM 3.18.0 / 4.13.0-21-generic, LLVM 5.0.0) GLES3: max ubo light: 409 GLES3: max ubo reflections: 455, ubo size: 144 ARVR: Registered interface: Native mobile real 0m1.108s user 0m0.166s sys 0m0.025s ``` 

Updated test here.

[profan]

This is definitely still an issue in Godot 3.0.2 x64, moreover not having any luck with the workaround by @brainsick now either.

Although the specific test attached by @brainsick curiously does seem to work, will test more.

[profan]

So I looked into this a bit further and realised that all the code in the GLES3 backend relating to this debug draw mode is ifdef DEBUG'd out

Some examples of the above: [1] rasterizer_scene_gles3.cpp#L1293-L1296 [2] rasterizer_scene_gles3.cpp#L1307-L1312 [3] rasterizer_scene_gles3.cpp#L1449-L1456

Personally I'd love to have access to the wireframe rendering mode even outside of explicit debug builds, I'm sure others would too and other issues like #11392 (admittedly a few months old now) show that I think I might not be the only one who wants this :P

[reduz]

This is not a bug, wireframe only works on editor because it generates special line geometry for triangle models. During the game, this is not supported because it's extra bloat.

This is because OpenGL no longer supports wireframe rendering.

Closing as this is not a bug.

[kb173]

As of 3.0.x and the 3.1 alpha, the Debug Draw mode 'Wireframe' is still there in the Viewport node's properties, but non-functional. However, even in 3.1, @brainsick's workaround using VisualServer.set_debug_generate_wireframes(true) works.

Since this issue is closed, I'm wondering: Is this the intended functionality, and will this be supported in future releases?

[Zylann]

I wish this could work when running the game using an editor build. It is just as useful as debug collision shapes. Thanks for the workaround @kb173 :)

[Calinou]

I don't see an issue with exposing the wireframe mode to release builds either, as long as it doesn't cause the binary size to increase significantly (which it probably won't).

[clayjohn]

It requires the engine to generate wireframe models for every mesh on load. Which would be a pretty significant issue for any project.

[Zylann]

@clayjohn generating meshes to see every collision shape is also a significant load, but that's really not the point I was making. The point is the ability to switch to wireframe mode while you are debugging your game from the editor.

[kb173]

I agree, why not just leave the VisualServer.set_debug_generate_wireframes(true) functionality as it is, but document it properly? I think a performance hit like that is only an issue when the user isn't aware of it. Perhaps it could be disabled for non-debug-builds?

In our project, having wireframes in the debug run of our game was a huge help. We work with a lot of GIS data which is procedurally fetched and updated while the game is running, so visualizing what's actually going on there at runtime (especially with the terrain) was great. Before finding this 'hidden' option, we were even thinking of manually writing a wireframe renderer.