Overlay: Edit Mesh: Add anti-alising on normal lines #119146

sac.aiden · 2024-03-07T09:19:29+01:00

sac.aiden commented

2024-03-07 09:19:29 +01:00

First-time contributor

Related issue: #107534

Now normals display with anti-alising

This is how it looks now:

I use almost the same shader as gpu_shader_3D_polyline_geom.glsl, which transforms a line to two triangles making up a square, and do some necessary modifications to fit the overlay_edit_mesh_normal.

Related issue: https://projects.blender.org/blender/blender/issues/107534 Now normals display with anti-alising This is how it looks now: ![image](/attachments/15e9d581-b22b-4908-8f67-76c11f8558f0) I use almost the same shader as `gpu_shader_3D_polyline_geom.glsl`, which transforms a line to two triangles making up a square, and do some necessary modifications to fit the `overlay_edit_mesh_normal`.

image.png

647 KiB

👍 1 ❤️ 3

sac.aiden added 1 commit 2024-03-07 09:19:37 +01:00

57e103e1c1 add anti-alising on normal lines

Iliya Katushenock added this to the EEVEE & Viewport project 2024-03-07 09:29:50 +01:00

Jeroen Bakker commented

2024-03-07 10:17:26 +01:00

Hi,

the trick is that geometry shaders aren't supported on Metal and would require a similar work-around. I expect that this change will crash on macOs currently. Will ask the Michael to help you out with this.

Hi, the trick is that geometry shaders aren't supported on Metal and would require a similar work-around. I expect that this change will crash on macOs currently. Will ask the Michael to help you out with this.

Michael Parkin-White commented

2024-03-07 10:31:06 +01:00

First-time contributor

Yes, as Jeroen has highlighted, unfortunately geometry shaders are unsupported by the Metal backend. Instead, an alternative implementation is required utilizing a vertex-pull solution. The same pattern already exists for a number of shaders e.g. 3D polyline.

The general idea is that the fragment shader and vertex interface can remain exactly the same, but instead, multiple instances of the vertex shader are invoked per input vertex to allow a greater number of outputs. The backend implementation here effectively binds the source vertex/index buffers as SSBOs with full range access, and then invokes the vertex shader with a vertex count which is expected to match the total maximum output.

The shader implementation itself can then use vertex-pull to read the required data to output the required primitives.

One such example which is perhaps similar is: source/blender/draw/engines/overlay/shaders/overlay_armature_shape_outline_vert_no_geom.glsl

Metal will require an implementation of this which utilises a non-geometry shader vertex pass. I am happy to look into implementing this, but to prevent crashing, the shader system will need a fall back which avoids the geometry shader path, while keeping the interface consistent.

To make this fallback seamless, we currently define GPUShaderCreateInfo overrides in gpu_shader_create_info_init.

e.g: For 3D polyline, we override the geometry shader variants of the create info with ones which do not use geometry shaders.

/* 3D polyline. */
    gpu_shader_3D_polyline_uniform_color = gpu_shader_3D_polyline_uniform_color_no_geom;
    gpu_shader_3D_polyline_flat_color = gpu_shader_3D_polyline_flat_color_no_geom;
    gpu_shader_3D_polyline_smooth_color = gpu_shader_3D_polyline_smooth_color_no_geom;
    gpu_shader_3D_polyline_uniform_color_clipped =
        gpu_shader_3D_polyline_uniform_color_clipped_no_geom;

Thanks!

Yes, as Jeroen has highlighted, unfortunately geometry shaders are unsupported by the Metal backend. Instead, an alternative implementation is required utilizing a vertex-pull solution. The same pattern already exists for a number of shaders e.g. 3D polyline. The general idea is that the fragment shader and vertex interface can remain exactly the same, but instead, multiple instances of the vertex shader are invoked per input vertex to allow a greater number of outputs. The backend implementation here effectively binds the source vertex/index buffers as SSBOs with full range access, and then invokes the vertex shader with a vertex count which is expected to match the total maximum output. The shader implementation itself can then use vertex-pull to read the required data to output the required primitives. One such example which is perhaps similar is: `source/blender/draw/engines/overlay/shaders/overlay_armature_shape_outline_vert_no_geom.glsl` Metal will require an implementation of this which utilises a non-geometry shader vertex pass. I am happy to look into implementing this, but to prevent crashing, the shader system will need a fall back which avoids the geometry shader path, while keeping the interface consistent. To make this fallback seamless, we currently define GPUShaderCreateInfo overrides in `gpu_shader_create_info_init`. e.g: For 3D polyline, we override the geometry shader variants of the create info with ones which do not use geometry shaders. ``` /* 3D polyline. */ gpu_shader_3D_polyline_uniform_color = gpu_shader_3D_polyline_uniform_color_no_geom; gpu_shader_3D_polyline_flat_color = gpu_shader_3D_polyline_flat_color_no_geom; gpu_shader_3D_polyline_smooth_color = gpu_shader_3D_polyline_smooth_color_no_geom; gpu_shader_3D_polyline_uniform_color_clipped = gpu_shader_3D_polyline_uniform_color_clipped_no_geom; ``` Thanks!

Clément Foucault added the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Overlay: Edit Mesh: Add anti-alising on normal lines #119146

Checkout