{"id":240,"date":"2021-03-20T15:59:16","date_gmt":"2021-03-20T15:59:16","guid":{"rendered":"https:\/\/bronsonzgeb.com\/?p=240"},"modified":"2021-03-20T15:59:17","modified_gmt":"2021-03-20T15:59:17","slug":"pseudo-metaballs-with-scriptable-renderer-features-in-unitys-urp","status":"publish","type":"post","link":"https:\/\/bronsonzgeb.com\/index.php\/2021\/03\/20\/pseudo-metaballs-with-scriptable-renderer-features-in-unitys-urp\/","title":{"rendered":"Pseudo-metaballs with Scriptable Renderer Features in Unity’s URP"},"content":{"rendered":"\n

This article shows my approach to drawing Metaballs in an optimized way using Unity, the Universal Render Pipeline<\/em> (URP) and Scriptable Renderer Features<\/em>.<\/p>\n\n\n\n

So, the overall approach is to draw our Metaball objects to a RenderTexture<\/em>, blur them, apply a Smoothstep<\/em>, and draw them to the screen. The optimization is that our Metaball objects will be standard sphere meshes. I developed this technique while working on a Splatoon-like ink system for the Mix and Jam YouTube channel. That video describes the approach visually by using Photoshop, so I encourage you to check it out. The video is linked later in this post. To do all this, we’re going to use a Scriptable Renderer Feature<\/em>, so let me explain how they work.<\/p>\n\n\n\n

Scriptable Renderer Features<\/h2>\n\n\n\n

Scriptable Renderer Features are part of Unity’s Universal Render Pipeline. They allow you to augment the existing render pipeline with custom features. In this context, a feature is a collection of render passes. So every Scriptable Renderer Feature comes with at least one Scriptable Render Pass. I found this confusing at first, so I’ll repeat: Scriptable Renderer Features contain one or more Scriptable Render Passes.<\/p>\n\n\n\n

A Scriptable Render Feature has two main methods: Create<\/code> and AddRenderPasses<\/code>. Create<\/code> is where you initialize your Scriptable Render Passes, and AddRenderPasses<\/code> is where you add them to the render queue. Additionally, if you want to expose values in the Inspector, the Scriptable Renderer Feature is the place to do it. A stripped-down Scriptable Renderer Feature looks like this:<\/p>\n\n\n\n

CustomRenderPass m_ScriptablePass;\n\npublic override void Create()\n{\n    m_ScriptablePass = new CustomRenderPass();\n    m_ScriptablePass.renderPassEvent = RenderPassEvent.AfterRenderingOpaques;\n}\n\npublic override void AddRenderPasses(ScriptableRenderer renderer, ref RenderingData renderingData)\n{\n    renderer.EnqueuePass(m_ScriptablePass);\n}<\/code><\/pre>\n\n\n\n
It’s not a lot of code because the real meat is in the Scriptable Render Passes<\/em>. Scriptable Render Passes<\/em> are where you provide instructions to the Rendering Pipeline, so let’s look at that next.<\/p>\n\n\n\n
Scriptable Render Passes<\/h2>\n\n\n\n
A barebones Scriptable Render Pass contains three methods: OnCameraSetup<\/code>, Execute<\/code>, and OnCameraCleanup<\/code>. As you may have guessed, OnCameraSetup<\/code> is where you set up the render pass, Execute<\/code> contains the rendering logic, and OnCameraCleanup<\/code> is where you clean up any resources. In a simple example, you’d set up your render targets, draw into them, and release them at the end. We perform most of the work using Command Buffers<\/em>. A Command Buffer<\/em> is a Unity class that holds a list of rendering commands.<\/p>\n\n\n\n
Now I have to be honest, the documentation on Scriptable Render Passes is sparse. I examined URP’s code and example code to learn enough to write my solution, but there are still certain aspects I can’t explain. For example, the documentation recommends calling ConfigureTarget<\/code> on your render targets inside the Configure<\/code> function instead of using the Command Buffer command SetRenderTarget<\/code>. However, it doesn’t explain what to do if you have to ping pong between multiple render targets like you would when blurring. In the official UniversalRenderingExamples Github repository, there’s an example blur in which ConfigureTarget<\/code> is called twice: once for each temporary render target. Upon inspecting the ConfigureTarget<\/code> code, it looks like calling it a second time will invalidate any state changes made by calling it the first time. So is this the correct way to do it? Who knows. Then there’s the issue of resource clean-up. Calling ConfigureTarget<\/code> ensures that your render textures are automatically cleaned up. However, given that calling ConfigureTarget<\/code> a second time invalidates the reference to the first render target, I believe it’s safe to assume it won’t be able to clean it up either. Finally, there’s a Blit<\/code> function that also changes the current render target. However, it’s unclear whether this also invalidates the reference to the render target set through ConfigureTarget<\/code>. So my point is that I tried my best to reach a working solution. If you can provide answers or feedback, please do it. Seriously, I’m begging you.<\/p>\n\n\n\n
Anyway, let’s start on our pseudo-metaballs.<\/p>\n\n\n\n
Pseudo-Metaballs<\/h2>\n\n\n\n
As mentioned, the approach is:<\/p>\n\n\n\n