Skip to content

Add libm feature to bevy_math#11238

Merged
mockersf merged 1 commit intobevyengine:mainfrom
Jondolf:libm
Jan 6, 2024
Merged

Add libm feature to bevy_math#11238
mockersf merged 1 commit intobevyengine:mainfrom
Jondolf:libm

Conversation

@Jondolf
Copy link
Copy Markdown
Contributor

@Jondolf Jondolf commented Jan 6, 2024

Objective

Different platforms use their own implementations of several mathematical functions (especially transcendental functions like sin, cos, tan, atan, and so on) to provide hardware-level optimization using intrinsics. This is good for performance, but bad when you expect consistent outputs across machines.

libm is a widely used crate that provides mathematical functions that don't use intrinsics like std functions. This allows bit-for-bit deterministic math across hardware, which is crucial for things like cross-platform deterministic physics simulation.

Glam has the libm feature for using libm for the math in its own types. This would be nice to expose as a feature in bevy_math.

Solution

Add libm feature to bevy_math. We could name it something like enhanced-determinism, but this wouldn't be accurate for the rest of Bevy, so I think just libm is more fitting and explicit.

@Jondolf Jondolf added C-Usability A targeted quality-of-life change that makes Bevy easier to use A-Math Fundamental domain-agnostic mathematical operations labels Jan 6, 2024
@alice-i-cecile
Copy link
Copy Markdown
Member

Great PR description: this is exactly the sort of context that I wish more contributors gave.

@alice-i-cecile alice-i-cecile added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Jan 6, 2024
@mockersf mockersf added this pull request to the merge queue Jan 6, 2024
Merged via the queue into bevyengine:main with commit 0349809 Jan 6, 2024
@Jondolf Jondolf deleted the libm branch January 7, 2024 00:13
github-merge-queue bot pushed a commit that referenced this pull request Jan 16, 2024
# Objective

gltf-rs does its own computations when accessing `transform.matrix()`
which does not use glam types, rendering #11238 useless if people were
to load gltf models and expecting the results to be deterministic across
platforms.

## Solution

Move the computation to bevy side which uses glam types, it was already
used in one place, so I created one common function to handle the two
cases.

The added benefit this has, is that some gltf files can have
translation, rotation and scale directly instead of matrix which skips
the transform computation completely, win-win.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Math Fundamental domain-agnostic mathematical operations C-Usability A targeted quality-of-life change that makes Bevy easier to use S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants