Option to enable deterministic rendering

[stepancheg]

Objective

Issue #10243: rendering multiple triangles in the same place results in flickering.

Solution

Considered these alternatives:

• depth_bias may not work, because of high number of entities, so creating a material per entity is practically not possible
• rendering at slightly different positions does not work, because when camera is far, float rounding causes the same issues (edit: assuming we have to use the same depth_bias)
• considered implementing deterministic operation like query.par_iter().flat_map(...).collect() to be used in check_visibility system (which would solve the issue since query is deterministic), and could not figure out how to make it as cheap as current approach with thread-local collectors (QueryParIter::map_collect and similar operations #11249)

So adding an option to sort entities after check_visibility system run.

Should not be too bad, because after visibility check, only a handful entities remain.

This is probably not the only source of non-determinism in Bevy, but this is one I could find so far. At least it fixes the repro example.

Changelog

• DeterministicRenderingConfig option to enable deterministic rendering

Test

[robtfm]

• rendering at slightly different positions does not work, because when camera is far, float rounding causes the same issues

My understanding is that the bias applies in depth buffer increments, so a bias of 1 should always result in an overwrite regardless of distance, but I haven’t tested it.

Either way making an option to stablesort is totally reasonable. The caveat regarding entity id reuse - making explicit/deliberate ordering difficult - still applies, but I guess a random stable order can still be better than a random unstable order to avoid flickering.

[alice-i-cecile]

Seems like a reasonable compromise for users who prefer this behavior. Flickering can be much worse than z-fighting, and "fix your models" is not always an option. The branch doesn't bother me: this isn't inside the hot loop.

Some small suggestions on how to explain this feature to users, but otherwise this LGTM. If there are better solutions, this is easy to amend or extend later.

[stepancheg]

Applied suggestions, although Z-fighting might not be precisely correct here.

This PR does not fix z-fighting, it only fixes flickering when Z-fighting already occurs, but Z-fighting stays.

[alice-i-cecile]

Good, that's much clearer. And yeah, that's a sensible distinction: we're still z-fighting, but at least it's not constantly unstable.

[rdrpenguin04]

Either this should be fixed if it's wrong, or there should be a comment to affirm that it's right. I'm assuming you chose sort_unstable for a reason.

[stepancheg]

Either this should be fixed if it's wrong, or there should be a comment to affirm that it's right.

AFAIU this is by design. I've added plenty of comments explaining current behavior. If you have suggestions how to rephrase the comments to make it more clear yet keeping comment concise, you are welcome.

[robtfm]

minor comment issue notwithstanding, lgtm and works as expected

[rdrpenguin04]

LGTM