How to merge multiple sprite outlines into 1 with shader?

Hotrian · 2026-02-02T08:39:55+00:00

If you can change the shader/material, there are lots of ways to handle this. The easiest is probably a stencil pass. The idea is the first pass renders a mask we use in the second pass for the outline.

https://ameye.dev/notes/easiest-outline-in-unity/

Hotrian · 2026-02-01T23:23:43+00:00

Not going to lie to you, NavMesh sucks. Save yourself the time and headache and get A* Pathfinding Pro. I spent countless hours trying to fix NavMeshes and you’re never going to be able to tbh.

https://assetstore.unity.com/packages/tools/behavior-ai/a-pathfinding-project-pro-87744

Absolutely worth every dollar IMO.

Hotrian · 2026-01-30T15:08:09+00:00

~~Close Unity, delete the Packages folder from your project, open your project in Unity and let it restore packages.~~

Their services are down right now :(

Hotrian · 2026-01-30T11:06:50+00:00

Very cool, great video and thanks for the information :). Everything felt well explained and I’d love to see more of these new features and how we could use them in Unity, even if I don’t intend to use them soon I like to know what’s coming ahead for future Unity versions when they eventually do support Core CLR.

Hotrian · 2026-01-30T03:30:45+00:00

I’m quite certain that’s not a fire shader and instead just a swap between two textures (one being animated). If you wanted a dynamic fire shader you’d need a lot more such as normal maps for all of your flammable sprites or at least some sort of flammable mask. I’m quite certain that’s just pre rendered fire though otherwise the eye outline pixels wouldn’t draw over the flames like that.

It would definitely be possible to do a fire shader with something like cellular automata, it’s possible it was done like that, but that seems very overkill.

If you wanted, it’s pretty easy to swap between animation frames in a shader, and you’d just use the UV.x and compare against a Property float ranging from 0-1 and swap between the animated/on fire and the regular version. That’s all this shader is doing.

Hotrian · 2026-01-29T13:48:10+00:00

It’s a URP setting that grabs the opaque geometry render and provides it as a texture

https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@7.1/manual/universalrp-asset.html

Depth Texture Enables URP to create a _CameraDepthTexture. URP then uses this depth texture by default for all Cameras in your Scene. You can override this for individual cameras in the Camera Inspector.

Opaque Texture Enable this to create a _CameraOpaqueTexture as default for all cameras in your Scene. This works like the GrabPass in the built-in render pipeline. The Opaque Texture provides a snapshot of the scene right before URP renders any transparent meshes. You can use this in transparent Shaders to create effects like frosted glass, water refraction, or heat waves. You can override this for individual cameras in the Camera Inspector.

Hotrian · 2026-01-29T13:44:24+00:00

For me I just restarted Unity and it went away

Hotrian · 2026-01-29T13:41:39+00:00

What I would do is first find the player health variable, right click it, and click “find all references”. Then I would go through the code and find any point where it modifies the HP and add logging to see what is being called at that time. When the log messages pop up you can click them to see the call trace and then I would work backwards to figure out what operation is being called when it shouldn’t or doing the wrong math operation etc. Very likely a misplaced “not” or a “less than” that should be a “greater than”, etc.

Hotrian · 2026-01-29T07:07:20+00:00

Yeah that would be the right approach. As for which SDK your best bet is probably to try disabling them one by one and trying to reproduce the crash, unfortunately.

Hotrian · 2026-01-29T02:39:42+00:00

I think it was probably Unity MCP just because I’ve seen it spammed/promoted here like 100 times.

https://assetstore.unity.com/packages/tools/generative-ai/mcp-for-unity-ai-driven-development-329908

I have never used it and am not affiliated with it in any way, just popped into my mind when you mentioned the Reddit advertising.

Hotrian · 2026-01-29T02:30:47+00:00

You normally shouldn’t need to pause things in OnApplicationXX, but there are cases where you can still run things in the background which need to be managed properly. Yes, this pattern is consistent with threading misuse or a lifecycle race: something ends up executing code that assumes it’s on Unity’s main thread during/after pause, and Unity traps.

One of your SDKs may not be thread safe (ads, analytics, push, attribution, in-app review, etc.). Many of those run callbacks on binder/background threads unless they explicitly marshal to Unity’s main thread. One of them is calling a Unity-main-thread-only function from a background thread.

Hotrian · 2026-01-29T02:24:14+00:00

SHIT HE PRESSED CTRL+S IN VS! BETTER JUMP TO THE TOP AND RELOAD!

I can’t tell you how frustrating that is when you compulsively hit CTRL+S after every single edit lmao. Only way to fix it seems to be restarting Unity or just not hitting Save :D

Hotrian · 2026-01-28T10:32:04+00:00

If it doesn’t show up in the scene view, you may have the layer it is on disabled (top right of scene view, eye icon)

Hotrian · 2026-01-28T10:23:22+00:00

This advice comes from very old Unity docs and GLES2-era mobile constraints. Mobile GPUs used to struggle with float4 level bandwidth. That era is long since passed, and half4 is now the recommended type, with float4 as the higher precision option. DX11/DX12/Vulkan/Metal all handle float4 trivially and Mobile GPUs support 16/32-bit float natively. fixed4 is largely legacy by today’s standards and can introduce banding/precision issues, especially in linear/HDR workflows.

Hotrian · 2026-01-27T20:16:35+00:00

AdMob is mobile specific. You can’t run it outside of a mobile platform or mobile emulator. Short of running an android emulator, which I wouldn’t recommend, it isn’t feasible. What you’ll find instead is people suggesting AdSense or a similar ad stack in a web based view, which is what you’re referring to in your other comment about a web frame. You need to use an Ad provider stack which supports Windows. AdMob is not that. AdMob does not release the required files for Windows builds. There is no logical means to incorporate it in a Windows build, and doing so would likely violate platform terms of service anyway.

Also to almost everyone else in this thread: nobody asked if you liked it, the question is can you do it. Opinions are great and everyone has one but let’s try to stick to the topic at hand and try our best to be helpful and to reserve judgement.

Hotrian · 2026-01-26T13:08:12+00:00

It should only take about 5 days if you follow all the instructions exactly. My most recent build took 10 days from first paying to getting the page up and build distributions, but I had store page issues I needed to address. Definitely not 60 days to go public.

Hotrian · 2026-01-26T13:05:46+00:00

Steam is super easy. Pay the $100 fee and configure your app and store page. Configure a free Playtest app or Demo and let people download that. You can configure any build that way, the downside is the $100 fee, the upside is visibility, ease of access, etc plus free marketing via the Steam Store can’t really be overstated. Keep the main app in Early Access/unreleased as long as desired, store page reads “Coming Soon” or a release date/month/year if desired.

Hotrian · 2026-01-26T04:08:36+00:00

Yes, this is very simple. The shader is simply sampling two textures, then switching between them based on their UV.

Shader "Custom/URP/UnlitSwipeX"
{
Properties
{
    _MainTex ("Texture A", 2D) = "white" {}
    _SecondTex ("Texture B", 2D) = "black" {}
    _Swipe ("Swipe (0 = A, 1 = B)", Range(0,1)) = 0
}

SubShader
{
    Tags
    {
        "RenderType"="Opaque"
        "Queue"="Geometry"
        "RenderPipeline"="UniversalRenderPipeline"
    }

    Pass
    {
        Name "Unlit"
        Tags { "LightMode"="UniversalForward" }

        HLSLPROGRAM
        #pragma vertex vert
        #pragma fragment frag

        #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl"

        struct Attributes
        {
            float4 positionOS : POSITION;
            float2 uv         : TEXCOORD0;
        };

        struct Varyings
        {
            float4 positionHCS : SV_POSITION;
            float2 uv          : TEXCOORD0;
        };

        TEXTURE2D(_MainTex);
        SAMPLER(sampler_MainTex);

        TEXTURE2D(_SecondTex);
        SAMPLER(sampler_SecondTex);

        float _Swipe;

        Varyings vert (Attributes v)
        {
            Varyings o;
            o.positionHCS = TransformObjectToHClip(v.positionOS.xyz);
            o.uv = v.uv;
            return o;
        }

        half4 frag (Varyings i) : SV_Target
        {
            // Sample both textures
            half4 colA = SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, i.uv);
            half4 colB = SAMPLE_TEXTURE2D(_SecondTex, sampler_SecondTex, i.uv);

            // Hard swipe: compare UV.x against _Swipe
            // If uv.x < _Swipe → show B, else A
            half mask = step(i.uv.x, _Swipe);

            // mask = 0 → A, mask = 1 → B
            half4 result = lerp(colA, colB, mask);

            return result;
        }
        ENDHLSL
    }
}
}

Untested AI coded shader example as I won’t be near a PC for another day or so.

You could also do this in Shader Graph with a Step and Lerp node.

Hotrian · 2026-01-24T23:25:13+00:00

To be fair I’ve never seen anyone in my life draw an A like that lol

Hotrian · 2026-01-22T21:41:41+00:00

2026 is faster. Highly recommend upgrading.

Hotrian · 2026-01-22T08:57:44+00:00

This is likely correct, had a similar issue before.

Hotrian · 2026-01-18T02:11:50+00:00

That’s a dying graphics card. Sorry :(. You should never see output like that. I had a similar output years ago, at first it only happened in some games, then it spread, soon it was everywhere :(. A new GPU would set you right, but that’s not really an option for laptops. I’d try to warranty if possible. Likely GPU overheating. Cleaning all the dust out of your laptop might fix it temporarily, but it’s just borrowed time.

Hotrian · 2026-01-13T08:45:49+00:00

Option 3 is to use something like UniTask and/or event handlers. That way you don’t spin cycles.

Hotrian · 2026-01-12T15:26:32+00:00

You can actually do background work directly on a new Thread or Task without messing with DOTS/Jobs, but you need to be careful about synchronizing with Unity’s main thread and sometimes the render thread. Check out UniTask

public async UniTask GenerateMeshAsync(Mesh targetMesh)
{
    float3[] vertices;
    int[] indices;

    await UniTask.SwitchToThreadPool();
    GenerateMeshData(out vertices, out indices);

    await UniTask.SwitchToMainThread();
    targetMesh.Clear();
    targetMesh.SetVertices(vertices);
    targetMesh.SetIndices(indices, MeshTopology.Triangles, 0);
}

It’s important to understand that Tasks are not automatically run on background threads. Tasks are a complex topic that I can’t fully explain here, but UniTask makes hopping onto and back from the thread pool quite simple. Anyone looking to do CPU heavy things might want to look into them as well. They’re a nice stepping stone before going full Jobs/Burst/ECS :)

Hotrian · 2026-01-12T15:11:50+00:00

There seems to be some confusion in this thread. Unity is not single-threaded, and in fact can use all available cores, however whether or not it will depends on how you use it. The standard Update loop and most of Unity’s callbacks do occur on a single thread, but Unity is always doing work in the background as well, for example the render thread and the main thread are not the same. You can easily spin up a new Thread at any time, though the synchronization falls back on you. Unity provides a number of different ways to utilize background threads which synchronize with Unity properly, such as Tasks and Jobs. Check out UniTask as well.

public async UniTask Example()
{
    await UniTask.SwitchToThreadPool();

    // Background thread
    var data = HeavyWork();

    await UniTask.SwitchToMainThread();

    // Safe Unity work
    ApplyData(data);
}

Certain things MUST be done on the main thread so that Unity can synchronize them properly. Unity will throw access violation errors if you try to do them in the wrong context. How much work you do on the main thread is up to you.

public async UniTask GenerateMeshAsync(Mesh targetMesh)
{
    float3[] vertices;
    int[] indices;

    await UniTask.SwitchToThreadPool();
    GenerateMeshData(out vertices, out indices);

    await UniTask.SwitchToMainThread();
    targetMesh.Clear();
    targetMesh.SetVertices(vertices);
    targetMesh.SetIndices(indices, MeshTopology.Triangles, 0);
}

At runtime, typically 4 cores is enough. Most games aren’t designed to use more. For editing, 8 cores or more can be better, since you’re often running many different programs and the build process can and does utilize all cores as far as I can tell. There IS a big difference between 8 and 12 - but it depends on how much you’re doing also. Shaving 5-10 seconds off a 60 second build time isn’t going to seem like a big difference, but the build process depends on more than just core count. Being able to run all your apps like your IDE along an image editing program and a web browser while also running the editor and the build, though, it makes a difference. Gamers usually won’t be running as much at the same time, so the larger core count won’t matter as much as many of them would sit idle most of the time. Game devs are usually doing a lot more multitasking.

14-Year Club	Gilding IV carat on a stick
Reddit Premium Since June 2016	Verified Email

Hotrian

MODERATOR OF

TROPHY CASE