Post-processing - full screen quad performance problem

mlange-42

Trying to add outlines via full screen quad prost-processing as described in the official Advanced post-processing tutorial chapter.

However, when playing fullscreen or with a large window, FPS goes down to around 50 and there is noticable shutter in irregular intervals, when moving the camera. This happens even with an extremely simple shader like this:

shader_type spatial;
render_mode vertex_lighting, depth_test_disable, blend_mul;

void vertex() {
	POSITION = vec4(VERTEX, 1.0);
}

void fragment() {
	float x = SCREEN_UV.x;
	ALBEDO = vec3(x, x, x);
}

Shutter is noticable primarily in medium-distance camera positions. When moved far in or out, the problem mostly disappears.

Can anyone give advice for some settings or something else I may have missed? Or is it just that my laptop graphics card (Intel UHD 520) is too weak?

Many thanks for any advice!

BTW, this is how the post-processed rendering looks like.

See this post for more information on the project.

cybereality

So the top part of the shader should be like this, it might help:

shader_type spatial;
render_mode skip_vertex_transform, depth_test_disable,
	unshaded, shadows_disabled, ambient_light_disabled;

Otherwise, what is the resolution of your screen? The UHD 520 is kind of weak, but should be enough to run a simple shader. I got Ella running on an HD 500, granted at around 24 fps, but it's a super high end demo. And the UHD 520 is a bit better than that. Also note that fullscreen performance is typically better than a large window. So you should also test in fullscreen to see if that is any better.

mlange-42

@cybereality Many thanks for your advice!

The shader change suggested helps quite a bit with the simple shader above, in fullscreen. With the outline shader, it is still quite bad, no matter if fullscreen or in a large window. So it is probably too demanding for this device.

My resolution is 1920x1080.

Here is the shader code for everyone to experiment...

shader_type spatial;
render_mode skip_vertex_transform, depth_test_disable,
        unshaded, shadows_disabled, ambient_light_disabled, blend_mul;

uniform float threshold: hint_range(0, 1) = 0.025;
uniform float width: hint_range(1, 5) = 1.0;
uniform float alpha: hint_range(0, 1) = 0.7;

uniform float camera_near;
uniform float camera_far;

float lin_depth(sampler2D depth_tex, vec2 screen_uv) {
	float depth = texture(depth_tex, screen_uv).x;
	float z_n = 2.0 * depth - 1.0;
    return 2.0 * camera_near * camera_far / (camera_far + camera_near - z_n * (camera_far - camera_near));
}

float simple_edge(sampler2D depth_tex, vec2 uv, vec2 rad, float thresh) {
	float d = lin_depth(depth_tex, uv);
	float t = d * thresh;
	float diff = 0.0;
	float dx = 0.0;
	float dy = 0.0;
	float d2 = 0.0;
	for (int i = -1; i <= 1; i++) {
		dx = rad.x * float(i);
		for (int j = -1; j <= 1; j++) {
			dy = rad.y * float(j);
			d2 = lin_depth(depth_tex, uv + vec2(dx, dy));
			diff += float(abs(d2 - d) > t);
		}
	}
	return diff / 4.0;
}

void vertex() {
	POSITION = vec4(VERTEX, 1.0);
}

void fragment() {
	vec2 pixel_size = 1.0 / vec2(textureSize(DEPTH_TEXTURE, 0));
	float is_edge = simple_edge(DEPTH_TEXTURE, SCREEN_UV, width * pixel_size, threshold);
	
	if(is_edge > 0.15) {
		float v = 1.0 - clamp(2.0 * is_edge * alpha, 0.0, alpha);
		ALBEDO = vec3(v, v, v);
	} else {
		ALBEDO = vec3(1.0, 1.0, 1.0);
	}
}

cybereality

It is because of this:

blend_mul

This uses the transparent pipeline which is too slow. You have to use the settings like I posted above.

Then instead of white, you sample the screen:

    if(is_edge > 0.15) {
        float v = 1.0 - clamp(2.0 * is_edge * alpha, 0.0, alpha);
        ALBEDO = vec3(v, v, v);
    } else {
        ALBEDO = texture(SCREEN_TEXTURE, SCREEN_UV)
    }

mlange-42

I was not aware that blend_mul requires the transparent pipeline, but now it seems completely logical. Actually, I used mul instead of transparency to avoid that. :lol:

But it does not seem to change anything performance-wise. Just all transparent object are invisible now, of course.

What I found is that disabing MSAA makes it run completely shutter-free (with degraded quality...). But it does not seem to simply add up frame time to hit the limit:

|      | Outline |         |  Diff   |
| MSAA |   off   |    on   |         |
|  off |   6.7   |   9.1   |   2.4   |
|  on  |  10.4   |  13.7   |   3.3   |
| Diff |   3.7   |   4.6   |         |

(Frame times calculates from FPS with VSync disabled, window size 1280x720)

So if either is on, the other one requires more frame time. But my understanding of render pipelines is quite limited.

cybereality

There is a render priority on the full screen quad. I think if you set it to like 1 or 2, it will render after the transparent objects, but you might have to tweak the numbers.

cybereality

The shader doesn't look all that complex. The only problem I see is this line:

vec2 pixel_size = 1.0 / vec2(textureSize(DEPTH_TEXTURE, 0));

That should be in the vertex shader as a varying, or simply passed into the shader as a uniform (not calculated for every pixel). That should help slightly but I'm not sure that's the main issue. It sounds like it might be transparency related. What are you using transparency for? If it is for cut out textures like grass, you should disable transparency and use the alpha scissor, which is substantially faster.

mlange-42

Thanks again, but the change seems to have a negligable effect, also combinded with not using blend_mul (I also read accessing SCREEN_TEXTURE is fairly expensive due to mip map generation).

There is not much transparency, only the range indicators and city labels in the image below. Disabling them (turning off their layer in the camera) does also have no effect. But I should probably still use alpha scissor for the labels.

mlange-42

There is a render priority on the full screen quad. I think if you set it to like 1 or 2, it will render after the transparent objects, but you might have to tweak the numbers.

This worked to get back the transparent objects :+1:

cybereality

Maybe just disable MSAA and use FXAA.

mlange-42

For now, I added outlines, MSAA and FXAA as in-game options, so players can choose depending on their machine. Many thanks for your time spent on this!

cybereality

I still don't think it should be slow, though. That scene looks fairly simple.

mlange-42

Yeah, I don't know... There are also other weird performance issues for me, particularly very high CPU usage when verbose debug printing is turned off. I should probably make a bug report in the Godot repository for this.

Meanwhile, I got also some nice results using inverse hull outlines, with custom "normals" (using Blender's smooth normals and a script to write them to vertex colors):

Here is the Python script. It must be run in Blender, with the Godot export plugin installed, and the object to edit as active object. It also exports the scene, next to the blend file.

import sys
import bpy
from mathutils import Vector

def gamma_inverse(color):
    return Vector(tuple([x ** (2.2) for x in color]))

if __name__ == "__main__":
    current_obj = bpy.context.active_object 
    mesh = current_obj.data
    
    if not mesh.vertex_colors:
        mesh.vertex_colors.new()
    
    mesh.update()
    
    for loop_index, loop in enumerate(mesh.loops):
        loop_vert_index = loop.vertex_index
        
        norm = mesh.vertices[loop_vert_index].normal
        tnorm = Vector((norm.x, norm.z, -norm.y))
        color = gamma_inverse((tnorm * 0.5) + Vector((0.5, 0.5, 0.5)))
        color.resize_4d()
        
        mesh.vertex_colors.active.data[loop_index].color = color
    
    mesh.update()
    
    assert bpy.data.is_saved, "File needs to be saved first"
    
    path = bpy.data.filepath[:bpy.data.filepath.rindex(".blend")] + ".escn"
    print("Saving to", path)
    
    addons = bpy.utils.user_resource('SCRIPTS', path="addons")
    print("Addons", addons)
    sys.path.insert(0, addons)
    import io_scene_godot
    
    overrides = {
        "object_types": { "EMPTY", "GEOMETRY" },
        "use_included_in_render": True,
        "animation_modes": "SCENE_ANIMATION",
        "material_mode": "SPATIAL",
        "material_search_paths": "PROJECT_DIR",
        "use_beta_features": False,
        "use_visible_objects": True,
        "use_export_selected": False,
        "use_mesh_modifiers": False,
        "use_export_shape_key": True,
        "use_export_animation": True,
        "use_stashed_action": True,
    }
    io_scene_godot.export(path, overrides)
    
    print("Done")

cybereality

Yeah, that looks better than the Godot default reverse hull (which I think looks seriously dated). Also, you might want to consider using OpenGL ES2 for your game, performance should be a lot better and it doesn't look like your graphics are using any ES3 exclusive features.

cybereality

Are you using a lot of print statements in your game? Cause that can seriously destroy performance. You should either only add prints when necessary for debugging (and remove them when the bug is fixed) or add an on-screen Label console to print output, which will be super fast.

mlange-42

Thanks for the ES2 hint, will give it a try.

No, I do not use any print statements. It must be some Godot bug. When running the game without "Verbose stdout" ticked, I get around 28% CPU usage (i.e. full 2 of 8 cores), although nothing is habbening CPU-wise, as it is a turn-based game. With "Verbose stdout" ticked, the game is at 2-5% CPU usage.

Calinou

Yeah, that looks better than the Godot default reverse hull (which I think looks seriously dated).

Reverse hull will look good if your mesh uses only smooth shading (and uses weighted face normals for sharp edges). It's not possible for it to create proper sharp outline edges otherwise. See this article for an explanation.

Screen-space outlines are useful in many cases, but they also bring problems of their own (such as difficult antialiasing and sometimes not appearing when they logically should).

mlange-42

Reverse hull will look good if your mesh uses only smooth shading (and uses weighted face normals for sharp edges)

I think the Blender script is a fairly good workaround. No smooth shading, very sharp edges, but still looking ok I think. This is because I use the smooth/weighted normals from Blender, not the sharp ones you get after importing.

An issue remaining is when looking at faces at a very sharp angle, so one views through between the original and the inverted face.

mlange-42

Successfully migrated down to GLES2, and it is indeed significantly less resource demanding now. Had to do some shader modifications, but is worked well.

Will stick with the custom inverse hull solution for now.

Many thanks to @cybereality all the advice!

cybereality

@Calinou said: Reverse hull will look good if your mesh uses only smooth shading (and uses weighted face normals for sharp edges). It's not possible for it to create proper sharp outline edges otherwise. See this article for an explanation.

Very interesting article, thanks for the link @Calinou . However, it was more about post-processing outlines, not so much using meshes, but still a good read.

Anyway, I did some line rendering myself when I was starting with Godot. Ended up not needing it in the end, it was more of an experiment, but it was almost finished. Here is the post processing Sobel filter:

And here is the other method that uses Barycentric coordinates. It is just a wireframe render with customizable line thickness. However, I never could figure out how to restrict it to only the outline (and not inner edges) but it was basically working, and very fast.