Bug [RESOLVED] Z Layer Ordering Issue with URP Unlit Transparent Shader

I'm working on an experimental project while learning the ropes of the DOTS stack. The project was converted from an existing 2D GameObject project I had, and for the most part I have everything working (minus the 2D packages - see this thread)

The main problem I've been noticing is that no matter what I do, SOME of my textured quads are drawing in front of others when they are clearly behind them. The interesting thing is this only affects some of the entities at one time, not every one of them, which leads me to believe it's something to do with the under-the-hood bath rendering, but that's just a guess.

Some examples:

1) I have entities' z layer dynamically adjusted based on their position which is what I was doing with the GameObjects previously


2) Red circles are examples of incorrect overlap, green are correct


3) My material


4) My texture


5) The entity itself looks like the following: The parent entity has all the physics properties and is constrained to a 2D plane so everything is at Z 0. The child object has the renderer data, and is offset from the parent as seen in the screenshots above.


Things I've tried:

• Setting variations of custom axes for the pipeline
• Using different shaders - I can't find another transparent one that the hybrid renderer supports though
• Using different meshes (planes or cubes instead of quads)
• Putting more distance between the entities
• Using alpha cutoff to make it behave more like a cutout shader
• Using the latest entities package and Unity version possible (0.51 and 2021)
• Setting the material sorting property to -1 to allow the shader to handle it

I may be forgetting something, but that's the gist. I know plenty about C#/OOP/etc, but next to nothing about shaders. Does this seem like something I can fix with a custom shader, or is this a bug with the hybrid renderer I'll have to wait for a fix for?

 

*** UPDATE/TEMPORARY FIX ***

Well I don't like this since it prevents me from using ANY transparency in my entities (I think), but in the meantime, my workaround was to cut out a plane in Blender and change the material to use an opaque shader, so the model itself is the cutout instead of projecting a transparent image onto a rectangle.





For now, it works. But there is almost certainly a bug with using transparent shaders (at least while using textures) with the hybrid renderer. I'll keep an eye on updates and see if it is resolved in the future.

 

@JussiKnuuttila For the entity conversion, I'm using Resource.Load() on a prefab that is marked for conversion (plus a couple authoring scripts), storing the prefab on a spawner component using IDeclareReferencedPrefabs on the spawner authoring script, then using EntityManager.Instantiate() on N entities. So other than adding a few custom components, I'm letting it convert everything under the hood.

I double checked the DOTS hierarchy window, and the quads do have HybridBatchPartition components attached, along with the other typical components:



That's an interesting thing to know about my workaround being more performant though, thanks.

 

Interesting! I checked through a few of the entities and they all seem to have the same partition value, even on multiple scene reloads. That must be the cause. Is it something to do with all these entities coming from the same prefab? What would I have to change to make sure a unique hash is calculated for each entity?

Edit: Manually updating one of the entities' partition value did fix the z layer ordering, at least for that entity. Is it safe to just set them all myself to a self managed ID?

 

Manually setting the partition value for each entity worked, thanks for your help!



I will note that I still have to place them about 0.5 z units apart from each other or I still get some bleed through, but that placing isn't a problem in my project.

Now, that does add a couple milliseconds of processing because, well, they are obviously no longer processing in batches. So from here I may look into grouping them by similar z levels, but that's another topic. I'll mark this as resolved.