How do I prevent texture batching in SRP?

I’m having a nightmare with the textures swapping over when playing multiple clips. I see that you can disable the SRP batcher to try to fix this but what do I need to do? I’m not using DK Studio or URP or HDRP.

I’ve read here that you can turn this off but the example is for URP.

I’ve read that you can stop them batching by adding a material to the shader. Anyone got a way to apply this to the Depthkit Core Photo Look Built In RP shader? (Sorry I don’t really understand shaders that well).

Or any other ways to prevent this happening using DK Core in Unity SRP…?

@Psicon_Lab Can you share the steps to reproduce this? Are you assembling your Depthkit objects from scratch or using the sample Depthkit Studio prefab?

hey @Psicon_Lab

The easiest way to do this is to create a custom material for each clip. That way the batcher will dispatch each clip separately since they don’t share a material. This is a better alternative than disabling the batcher wholesale, because when you do that you lose the performance benefit of batching elsewhere/

To configure clips with separate materials:

• Create a new Material
• Set the shader to on the new Material Depthkit/Core/Depthkit Core Photo Look Built-in RP
• Swap the default Material on your Clips’ Depthkit Core built-in Look ‘Look Material’ to the custom materials

See screenshot below for hints on setting this up

Inked2023-03-17 14_31_05-Material Test - SampleScene - Windows, Mac, Linux - Unity 2021.3.11f1 Personal_ _LI1920×1007 62.4 KB

Inked2023-03-17 14_31_26-Material Test - SampleScene - Windows, Mac, Linux - Unity 2021.3.11f1 Personal_ _LI1920×1039 86 KB

Super, thanks James! TBF I think my issues may well stem from Unity rendering stuff rather than DK but it’s useful to know the work arounds. I’ll give this a try 🙂 Ben

Didn’t fix my issue sadly - I found the textures were flipping constantly between each other. The more similar the 2 clips the more swapping occurred. Using Vulkan instead of OpenGLES3 solved most of the issues on most clips for me, but I found this particular pair of clips would only stop swapping textures when I downgraded from IL2CPP using Arm64 to use Armv7. Bizarrely this fixed it. (I’m building for the Quest 2 by the way).

@Psicon_Lab Bizarre. Glad you found a fix.

This seems to me like an issue with the video decoders as opposed to Depthkit.

Can you recreate the issue by bypassing Depthkit and just applying video texture to a quad?

Are you using AVPro for playback?

No I’m not using AVPro just the Unity video player…

Finally after a LOT of digging, found what some issues were. A combination of texture batching but made worse by an issue definitely related to the video decoding.

Setting the materials as you described may have helped - I ended up switching back to Armv64 and using Vulkan in the end, which really solved most of the texture batching issues anyway.

Just for the record I found that one clip that was causing lots of playback issues for me which, intermixed with the batching was giving me loads of trouble - it was recorded at 1584x1680 and would not playback smoothly, just kept staggering, even re-encoding using a number of different configs didn’t help, smooth playback was achieved by resizing it up to 1920x2160 (to match all the others) in the end. Not totally sure why it was a different dimension anyway 🤷

Looks like building for the Quest comes with a bunch of new video hardware/decoding issues!

Just following up on this issue… in a newer project that used URP…

I found that my Depthkit clips played back fine using the Unity Video Player, in the Editor, and as a development build for the Quest 2, but when built from Unity as a Release build the clips would start batching and swapping textures/position etc.

These were single camera depthclips, 9 of them playing at the same time all of them using custom additive shaders (here’s a link to the project if you want to see it on AppLab - Tableau Vivant).

Took me a long time to fix this one, but I eventually found that turning off Multithreaded Rendering (when using OpenGLES3) made the clips play back properly.

Thought I’d leave a comment here in the forum just in case it benefits anyone else 🙂

Ben

@Psicon_Lab Thanks for the information, and for sharing your project. Can’t wait to check it out!