Ability to set Transform fundamental native type to f64 or fixed-point types

[recatek]

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

For very large game worlds, or for multiplayer games, it can be difficult to work within the floating point confines of f32. Giving users control over the native floating- or fixed-point type that bevy uses for rendering and other position-driven logic would enable for a wider range of potential games and simulations without having to hack through bevy internal systems.

What solution would you like?

Expose a compile-time configuration option that controls the inherent type that bevy uses for its position and transform components in rendering and other related (e.g. audio) systems. In the case of a custom fixed-point solution, this would require a conversion method on the user's part. In the case of f64, in a perfect world, this would use 64-sized SIMD intrinsics wherever 32-sized intrinsics are used for f32. For rendering, at some point in the pipeline, a conversion to f32 is almost inevitable, but objects far enough away from the camera would likely be culled to where precision loss would be irrelevant.

What alternative(s) have you considered?

1. Separating gameplay entities from rendering entities. Gameplay entities are given a homemade position component using f64/fixed-point values in world space, while rendering entities use f32 in a transformed camera-relative space. This is undesirable because it necessitates a large-scale copy of data from gameplay to rendering entities each frame. On top of that, this copy process is rife with cache misses, as the decision of which entities are close enough to the camera to bother transforming creates an effectively random set of gameplay/render entity links, and each lookup for this process is then a random access.

2. Not using bevy's transform components at all and rendering manually in batches. This avoids the copy and entity-linking process, but requires a lot of manual work on the user's part to pass over each gameplay entity, determine if it's worth rendering, convert its coordinates into camera-relative space, bin it into proper instances, and send it out for rendering. This essentially recreates, or requires forks of, entire crates like bevy_sprite and such in the process.

Additional context

Not sure how much it matters, but regarding SIMD instructions, SSE up to 4.2 has an adoption rate of at least 98% on the Steam hardware survey, and AVX is just shy of 95%. This covers the bulk of support for f64-sized SIMD intrinsics as far as I know.

[RoyAwesome]

this would probably need glam to support avx instructions for f64 types

[aristaeus]

When downcasting to f32 for rendering, you will need to have some kind of floating origin, to keep the camera away from floating point errors.

I solved this problem by creating my own Transform64 type, and giving entities both the f32 and f64 variants as components. I added a RenderingOrigin resource, and every frame there is a system to sync the Transform to TransformF64 - RenderingOrigin. I don't see why you need the complexity of gameplay entities and render entities, and syncing between them. I'm not worried about cache misses or having iterate over all entities like this - it should be a pretty cheap operation in the grand scheme of things.

[recatek]

Oh, right, you can just have both position representations on the same entity. That is simple and clever, good point!

[alice-i-cecile]

As part of this, we'd want f64 and fixed point variants of physics (and related systems), to allow for their seamless use in games that need these transform types. Probably toggle this by using a State as part of the default plugins; even though we'll always need to cast to f32 for rendering.

[alice-i-cecile]

Relevant to #1678.

[ValorZard]

I completely agree with doing this, lol. Godot is currently trying to do the same thing, so the earlier we do this, the less work we have to do in the long run. I know rapier already does something like this also, so that might be something to look towards

[danieljpetersen]

This is extremely important for deterministic simulations. You can certainly work around it by having other types on a component and syncing the transform, but that's not ideal.

Might be worth looking into how nalgebra / nphysics is handling this

https://www.rustsim.org/blog/2020/06/01/this-month-in-rustsim/

[dman-os]

I'd like to chime in support for this.

The recent rendering rework seems to adopt separate game/rendering entities concept and should help with the rendering issues. We just have to transform the game world locations relative to some floating "RenderingOrigin" transform when generating the render world transforms....somewhere around...here though know that my understanding of the code base and rework is minimal.

Edit: with rendering done in a completely separate context, I think making the game world default to f64 should be considered.

[james7132]

Edit: with rendering done in a completely separate context, I think making the game world default to f64 should be considered.

This should definitely be benchmarked if we ever decide to do so. Losing widespread support for SSE2 on f32s in both software and hardware, lower cache coherency due to the larger data types, and limited/no support for in both glam and hardware support AVX for f64s may have serious performance implications.

[yottapanda]

I'd also like to note my support for this change and my willingness to help with work on this.

I have grand plans to use Bevy and I've been meaning to get into helping with development while simultaneously building using the engine.