Possible bug rendering sprites with "Red" in the file name

[srodrigo]

Bevy version

0.10.1

What you did

I'm just rendering different sprites which are effectively the same but in a different colour.

What went wrong

Sprites with Blue in the filename render correctly.
Sprites with Red in the filename do NOT render correctly.

The filenames look like this:

• Archer_Blue2.png
• Archer_Red2.png

Anyone would think this is an issue with the Red PNG. That's what I thought too. But then I tried the following:

🟢 Rename the red sprite to Archer_Blue2.png - it renders the sprite correctly
🔴 Rename the blue sprite to Archer_Red2.png - it does NOT render the sprite
🟢 Rename the red sprite to Archer_Redi2.png (basically add an i character so it's not just "Red") - it renders the sprite correctly

At this point, I think I'm either going insane or Bevy is doing something weird. I even thought that the sprite sheets were messed up and somehow being "fixed" when I copied them to give them a new name. But the Blue ones that work correctly stop working when I just rename it to have Red in the name.

I know there shouldn't be a reason for Bevy misbehaving, but I've proved that the Blue sprite that renders correctly stops working if I rename it to Red, and viceversa. This is a long shot, but any ideas?

Additional information

This issue happens on both Linux and Windows. I tried on both to make sure Linux wasn't doing anything doggy.

Source code that is having the issue https://github.com/srodrigo/strategy-game-rs/blob/ch02-wip/02-units/src/main.rs#L331
Assets are in assets folder as expected.

EDIT: I think the fact that just renaming the sprite sheet that works fine makes it not work kind of proves something is going on.
Just for extra checks, I've tried to render the Red one in MonoGame and Haxe Heaps. I know they work differently, and MonoGame does some asset processing, but I still wanted to try. I don't think there's anything wrong with the sprite sheets, but something Bevy doesn't like seeing "Red" in the file name.

[nicopap]

Hilarious! I can reproduce. I'm investigating. I'm so sorry you had to go through this really weird bug.

[srodrigo]

@nicopap haha no worries. Hilarious indeed... I thought I was loosing my mind, but good that you can reproduce it too.

[srodrigo]

It gets even more strange...

Similar issue with Archer_Green3 and Archer_Green2. Green3 works, Green2 doesn't.

I've tried the same rename trick and renamed Blue2 to Green3, and it works. But if I rename Blue2 to Green2, it doesn't!

At least there is some consistency in the weirdness... but not it seems numbers are involved too?

😵

[nicopap]

I found where the bug comes from. The archer is spawned regardless of the file name. What actually happens is that which sprite is rendered in front of another is more or less undefined. The issue is that the translation.z of both the archer and the terrain is the same. Which means sometimes the terrain renders on top, sometimes the archer renders on top. It probably depends on the order the images are loaded (which the file name might influence)

I found that other file names would trigger the behavior. For example, just naming the file d.png would cause the archer to not appear.

The solution is to give a distinct translation.z value to the archer and the terrain, this way it is always specified and defined which renders on top. (in your case that would be set 0.0 at line 267 for the terrain and set 1.0 at line 315 for the unit). With this, the units always show on top of the terrain, regardless of the file name.

There has been active discussion recently in bevy on how to cleanly handle this. You might be interested in the following discussions:

• Add Transform2d component #8268
• Ergonomic z-order layers for 2D graphics (and UI?) #1275

[srodrigo]

OMG interesting... So the filename might be playing its role.

I didn't thought of looking into the z index, as usually sprites rendered later appear on top of existing sprites, at least on most engines. But I'm happy with the z index, it's a good practice anyway (that I forgot about...).

Thanks a lot for helping out 🙏

If there's already a discussion going on, I'm happy for this issue to be closed. Up to you, whatever is more useful.

[nicopap]

This can be safely closed. But feel free to keep it open. It is a real issue, and the culprit is not you, but bevy: For not telling you what was happening, and not giving you the tools to figure it out.

I would recommend you consider using something like https://github.com/jakobhellermann/bevy-inspector-egui, it gives much more visibility on what is going on in the game. I think with it you would have immediately understood what was the issue and how to fix it.

[srodrigo]

Thanks for the tip! I'll give it a try :)

[alice-i-cecile]

Definitely want better tools to detect and warn about z-fighting! See #1275 :D Going to close this out though as I think that this issue isn't super clear for people trying to tackle it :)