Rectangle with alpha channel

[TitanNano]

I attempted to build a small demo 2D scene using a tilemap and some rectangles but I'm running into an issue with the alpha channel of the rectangle textures:

The lamp is composed of two rectangles inside a pivot. The transparent pixels of the lamp rectangles always contain the tile map contents and cover the car sprite below it.

Hiding the background tile map, shows the background color and still covers the rectangle underneath.

Am I doing something wrong, or is this a bug?

[mrDIMAS]

Have you tried moving the lamp along Z axis? Will it solve the issue?

In general it looks like a sorting bug, but it might be fix-able using Z offset.

[mrDIMAS]

Yeah, I've reproduced it and know exactly why it happens. It happens because of how sprite batching works, it does not sort sprites back-to-front when they're added to the batch. The fix is not trivial and will take some time.

[TitanNano]

Batching happens in the RenderDataBundleStorage right? There might be a better solution but wouldn't it be enough to include the sort_index in the hash here, for now?

Fyrox/fyrox-impl/src/renderer/bundle.rs

Lines 1170 to 1174 in 26cbde5

	let mut hasher = FxHasher::default();
	hasher.write_u64(material.key());
	layout.hash(&mut hasher);
	hasher.write_u32(render_path as u32);
	let key = hasher.finish();

[mrDIMAS]

I thought about sorting triangles in dynamic surfaces in back-to-front order, but then realized that this won't work if there's another transparent object with some other material located somewhere in the middle of the final combined mesh. For example if there's a bunch of rectangles with blending with the same material, and they have different z coordinate they all will go to the same batch in the current approach. If there's another object with different material put somewhere in the middle of this mesh, then there will still be blending issues. I think your assumption is correct and should handle such cases easily. There's only one downside - different "layers" will be rendered using separate draw calls, which is sub-optimal.

[mrDIMAS]

I've submitted the fix, could you please check if it works?

[TitanNano]

yes the fix works. 👍

There's only one downside - different "layers" will be rendered using separate draw calls, which is sub-optimal.

I assumed as much. Maybe there is a way to optimize this in the future.