YouTube video by Acerola

Part of the "VR is Alive" Spotlight Series, Season Three

Part of the "VR is Alive" Spotlight Series, Season Three

klaas: > I would still say that your first approach to provide all the vertex data to your shader would kill your performance massively. OpenGL, Vulkan, and DirectX have Geometry Shaders, so the underlying API of Forward+ should be capable of doing this calculator with reasonable cost. As mentioned in this GitHub issue, Godot doesn’t plan to add support for GeometryShaders, and suggests to ComputeShaders instead. My current understanding is that to run ComputeShaders inside Rendering Pipeline I have to use Compositor API, which leads to my initial question of: How do I access geometry data inside of ComputeShader inside of Compositor (or Rendering Pipeline) ? The GPU already does the calculation of all the normals of all the visible triangles and pixels on the screen, so my estimation is that this wouldn’t take more time than rendering the same scene twice. I found this method, and I’m trying to understand what exactly is in these buffers, and if I can somehow get the geometry data from there ? As I mentioned above, I don’t know the performance implication yet, but I’d like to actually try it and measure it to decide if such shader is viable for my use case. klaas: > Also if you use bone deformation the vertex position wouldn’t be correct since deformation runs in a shader and not on the vertexbuffer itself. Simulating deformations by script would totaly dump your fps. That’s a very good point. I didn’t know how the animation affected vertex buffers. And I do agree that simulating deformations seems like an overkill. Would it be possible to access the geometry data after the deformations are performed ? klaas: > Let’s try a different approach: If you would write a fragment shader which information would you need in detail to get your result per pixel when rastering? > > Maybe an extra render pass can provide you with all the information you need. One idea I had is to use a custom discontinuity texture - essentially paint regions I want to separate with highlight lines with different colors, and then detect boundaries between these regions with edge detection algo. I guess since there are around 16M colors it would be sufficient for all game objects I’d potentially have in a scene (or in a game even). It’s a good suggestion. I’m going to also explore the idea of computing the custom discontinuity texture at asset import time and using it as an input to the Fragment shader. Related question: If I run Fragment Shader as 2nd pass on ShaderMaterial, is it somehow possible to know if it’s an “edge fragment” ? Meaning that there is no adjacent fragment belonging to the same geometry on the sides of this fragment ? (this however won’t solve the cavity issue, but I guess I could precompute additional cavity texture as process it inside of FragmentShader to highlight cavities as a solution for static object, still no idea how would I do this for animations) klaas: > Okay, i think i have a glimps of what you try to achive. I’ve managed to find this, which is vaguely similar to what I’m trying to achieve, and it seems like they were able to solve it to some degree. So I’m pretty sure there is a way of doing it. The main question is if there is a performant-enough way of running this kind of shader in the context of Godot engine. Just to add more context and clarify my intentions: I’m working on a shader that highlight certain edges in the mesh based on 2 criteria: 1. edge have only 1 visible adjacent triangle (the other triangle is either invisible because of culling, or non existent) - this is similar to Outline/Silhouette/Contour of an object 2. angle of adjacent triangles in a specified range - this is possibly similar to cavity map as you mentioned above