Fix visible entity sorting

[joboet]

What problem does this solve or what need does it fill?

The current algorithm can lead to missing transparency effects when using custom cameras.

Describe the solution would you like?

Changing
DepthCalculation::ZDifference => camera_position.z() - position.z()
to
DepthCalculation::ZDifference => (camera_position.z() - position.z()).abs()
would fix the error.

Describe the alternative(s) you've considered?

Using DepthCalculation::Distance resolves the issue, but leads to weird artifacts when entities are closely together.

Additional context

I use a custom pseudo-3d camera projection. As it increases the Y-coordinate with increasing Z-coordinates, it needs the camera to be at or close to the origin. This means that entities with positive Z-coordinates get assigned a negative ZDifference and thus are sorted incorrectly.

[cart]

I'm not sure using abs() here is the right call. Consider the following 1-dimensional case:

// A, B, C are drawn "things", X is a camera
A--B----X-----C

// Distances (signed)
A: 6
B: 4
C: -5


// Front-To-Back Draw Order (signed)
1. C (-5)
2. B (4)
3. A (6)

// Front-To-Back Draw Order (abs)
1. B (4)
2. C (5)
3. A (6)

With abs(), C is drawn "between" A and B, which doesn't make sense.

[joboet]

As far as I understand it, C should not be drawn anyway, as it is beyond the clipping range of the camera, but I‘ll check that…

[cart]

Depends on how big C is. Clipping happens to the individual triangles.

[joboet]

Right… I guess I'll have to work around the issue by placing the camera behind the scene, which works (and is the default for the orthographic camera), but feels really weird. Maybe OrthographicProjection should be changed to be more like PerspectiveProjection, which places the camera in front of the scene. Should I open another issue, or do you want to leave it as is?

Also, thinking about it, the artifacts I saw will also appear with the default Camera3dComponents. When two entities are closely together, one entity positioned in front of the other produces the expected result:

However, when the same entity is moved to the side a little, it now has a greater absolute distance from the camera and is drawn first, but has less depth as it is closer in the image, leading to missing transparency:

I don't really know how that can be fixed…

[cart]

Maybe OrthographicProjection should be changed to be more like PerspectiveProjection, which places the camera in front of the scene. Should I open another issue, or do you want to leave it as is?

I think I'd prefer to leave it as-is for now. Bevy uses a right handed y-up coordinate system for all projections, so x should be right, y should be up, and z should be "in to the screen".

I don't really know how that can be fixed…

Yeah thats just Camera3dComponents behaving as expected. I needs to use 3d distance to calculate depth (whereas 2d cameras can just use the z distance).

I think there are two "fixes" here.

1. 3d cameras use distance to "the center" of an entity. This is fast and simple, but it doesn't take the entity's shape into account. We could consider adopting a more expensive approach that uses raycasting + bounding boxes (or collision shapes), but I'm not sure thats worth it. I'd be curious to see what the best practices are in this space. I'm not a depth expert.
2. Allow for "custom" depth calculations. We could expand the DepthCalculation enum to include a Custom option.

[alice-i-cecile]

Is this still relevant? We swapped our projection strategy for 0.6.

[james7132]

Tentatively closing this as there has been no response to the issue in over 9 months and the implementation has shifted significantly since this issue was opened. If someone can reproduce this case in a more current version of Bevy, feel free to reopen.