Does not correctly set the z value for particle rendering

[kpence]

This plugin, according to StarArawn who wrote bevy_ecs_tilemap, doesn't correctly set the z value for particle rendering: https://github.com/djeedai/bevy_hanabi/blob/main/src/render/mod.rs#L1606 .

This results in problems where the particles appear randomly below or in front of any of the sprites or tiles from bevy_ecs_tilemap.

I first mention this bug here: https://github.com/StarArawn/bevy_ecs_tilemap/issues/188#

[djeedai]

Yes @StarArawn is absolutely right, we're not setting the Z value. The issue is, I'm not sure which value makes sense here. We're making a single draw call for the entire particles, so a single Z value shared by all of them, which obviously doesn't play nice with other rendering elements if you truly want sorting. But maybe just a constant Z value corresponding to the depth of the layer where the particles are rendered is what we need here? I'm happy to hear about suggestions and/or take contributions for that; I just didn't look into it yet and don't have much time to do so from scratch without pointers.

[djeedai]

Note:

the particles appear randomly below or in front of any of the sprites or tiles from bevy_ecs_tilemap.

I don't think they appear "randomly"; I think the particles appear exactly at Z=0, no? And so it depends on the Z value of the tiles too, if some use Z<0 and others use Z>0. That is, considering you're using a "planar" effect and not one spawning particles in a 3D direction. Maybe we need some specific 2D emitters and/or constrained 2D Euler motion integration too, not sure.

[StarArawn]

Yes @StarArawn is absolutely right, we're not setting the Z value. The issue is, I'm not sure which value makes sense here. We're making a single draw call for the entire particles, so a single Z value shared by all of them, which obviously doesn't play nice with other rendering elements if you truly want sorting. But maybe just a constant Z value corresponding to the depth of the layer where the particles are rendered is what we need here? I'm happy to hear about suggestions and/or take contributions for that; I just didn't look into it yet and don't have much time to do so from scratch without pointers.

I believe it should be user dictated. Ideally bevy would allow mixed z-sorting between meshes in draw calls but right now 2D doesn't have a depth buffer.

[sharkdp]

We ran into the same issue. I can confirm that particles appear at exactly z=0. Unfortunately, I didn't find a workaround for our use case (I want the particles to appear on top of everything else). I tried to set the z-layer of all other components to something negative, but then bevy doesn't render them anymore. I tried choosing a different translation for the orthographic camera, but that didn't work either.

I can't speak for everyone obviously, but having the option to set one fixed z-layer for the particles would definitely help in our case.

[djeedai]

I think that with the recent Bevy camera rework we should be able to detect the camera type, and for 2D cameras (the only case this makes sense) allow the user to set a fixed Z value. That would partially mitigate the issue so long as you use "2D" modifiers and we don't move particles outside that plane, which I'm not sure is the case.

[djeedai]

This should be fixed now, with one global per-asset value, and one optional per-instance value allowing to override the asset value. I tested only against a simple MaterialMesh2dBundle but I can indeed move the particle in front and behind it; see the updated 2d.rs example for this (you can tweak the value of z_layer_2d in the egui inspector).