-
Notifications
You must be signed in to change notification settings - Fork 6
Home
Welcome to the wiki for the Unity DOTS Physics overhaul project to provide double-precision floating point support!
This project is a personal undertaking primarily to implement double precision floating point support into the new Unity DOTS framework. I would like to add support for Decimal, Quad, and Arbitrary precision, as well, but double-precision is my current focus. This project includes enhancements to numerous DOTS packages, but especially to com.unity.mathematics and com.unity.physics to support double-based transforms and associated operations across the full spectrum of geometric types and associated mathematical operations.
You can contact me on my game development Discord server: https://discord.gg/PUEUJqZ
Contacting me on this Discord server is the most reliable means of reaching me. Other methods of contact may be ignored or go unnoticed.
Unity's native lack of support for double precision physics touches many different packages, but the math and physics packages require the most work. The default upstream packages lack support for a considerable array of functionality required to implement double precision physics. This includes even a lack of support in the math package for long and ulong vectors and matrices, as well as all related math functions on those 64-bit integer types. Some of the physics code relies on conversions from 32-bit float to 32-bit integers and vice-versa. Implementing 64-bit double precision float physics in the same way thus also requires support for 64-bit integer types.
In addition, the many structs used by the system have fixed-type data members specified directly as int, uint, float, and their vector and matrix variants. This presents an issue when adding 64-bit support as it either requires adding additional 64-bit data members to those structs which go unused when you use them as 32-bit structs or it requires the 32-bit data members to go unused when using them as 64-bit structs. Changing the structs and math functions to generics not only would break compatibility with existing code in your project, it would not provide an effective and efficient way to specify the use of all of the appropriate 32-bit or 64-bit data variants used throughout the methods.
As a result of these issues, I have chosen to provide the 64-bit support by creating new variants of the different types throughout the code while preserving the 32-bit variants in their original form. Luckily, the Mathematics package already provided a lot of the double-types. Unfortunately, the Physics package does not provide any.
The following types have been added to the com.unity.mathematics package:
- long
- long2
- long3
- long4
- long2x2
- long2x3
- long2x4
- long3x2
- long3x3
- long3x4
- long4x2
- long4x3
- long4x4
- ulong
- ulong2
- ulong3
- ulong4
- ulong2x2
- ulong2x3
- ulong2x4
- ulong3x2
- ulong3x3
- ulong3x4
- ulong4x2
- ulong4x3
- ulong4x4
- matrixd
- quaterniond
- RigidTransformD
- PlaneD
- MinMaxAABBD
In addition to these types, I have added all of the associated mathematical function support (Euler, rotations, translations, bitwise operations, etc), as well as the associated type conversion support. This includes the ability to directly convert from 32-bit variants to 64-bit variants (and the reverse where it makes sense).
I have also not only added 64-bit integer support to the random number generator, I have completely rewritten nearly every function to fix numerous issues. The core PRNG algorithm has been changed to XOSHIRO256++. All of the max-bounded random generation functions have been fixed to correctly generate uniform random distributions in the range of [0, max), including all possible bounds-constrained integer values for both 32-bit and 64-bit integers, regardless of the choice of max value. Additionally, the range generation functions have been fixed to correctly generate uniform random distributions between the specified min and max values. Previously, these bounds-constrained functions not only did not produce uniform random distributions, but they also did not even generate all possible values within the specified range. In addition, edge case issues have been resolved throughout the remaining functions.
The following items have been added to com.unity.physics:
- Extra double-based physics math functions
- AabbD
- DoubleRange
- FourTransposedAabbsD
- FourTransposedPointsD
- MTransformD
- PlaneD
- CompoundCollierD
- ConvexHullGenerationParametersD
- ConvexColliderD
- CylinderColliderD
- BoxGeometryD
- BoxColliderD
- CapsuleGeometryD
- CapsuleColliderD
- IColliderD
- IConvexColliderD
- ICompositeColliderD
- ILeafeColliderCollectorD
- ColliderD
- ChildColliderD
- MeshColliderD
- SphereGeometryD
- SphereColliderD
- TerrainColliderD
- TerrainD
- PolygonColliderD
- BoundingVolumeHierarchyBuilderD
- BoundingVolumeHierarchyD
- ConvexHullBuilderD
- ConvexHullD
- MeshBuilderD
- MeshD
- IQueryResultD
- QueryContextD
- ICollectorD
- AnyHitCollectorD
- ClosestHitCollectorD
- AllHitsCollectorD
- ICollidableD
- QueryWrappersD
- ColliderCastInputD
- ColliderCastHitD
- ColliderCastQueriesD
- ConvexConvexDistanceQueriesD
- ConvexConvexManifoldQueriesD
- PointDistanceInputD
- ColliderDistanceInputD
- DistanceHitD
- DistanceQueriesD
- ContactHeaderD
- ContactPointD
- ManifoldQueriesD
- OverlapAabbInputD
- OverlapAabbHitD
- OverlapQueriesD
- RayD
- RaycastInputD
- RaycastHitD
- RaycastQueriesD
- RigidBodyD
- BroadphaseD
- CollisionWorldD
I tried to keep code breaking to a minimum, but in some cases it makes sense to require minor code modifications. I have attempted to document any cases of which I am aware from my own usage of the new packages.
Anywhere you utilize Math.Random and store the state of the random number generator, you will need to switch from uint to ulong4. Additionally, if you are performing boolean comparisons against the state, you will want to modify those to make use of functions like math.all() and math.any().
Because there are now long, long2, long3, long4, ulong, ulong2, ulong3, and ulong4, you may now receive errors about missing implicit conversions between these types and their previous int-based counter-types. Similarly, you may receive them between float and double types.
Again, as a result of the newly added types, you may now receive errors about your use of specific methods being ambiguous as it may not be possible for the compiler to automatically determine whether your code refers to an int2 or a long2. This same issue exists for all new long, ulong, and double types and functions. In these cases, you may need to place a type hint on the invocation or specify numbers with a suffix which denotes the intended bit-length of the value.
- com.unity.mathematics :: 67 files changed, 26359 insertions(+), 136 deletions(-)
- com.unity.physics :: 76 files changed, 16315 insertions(+), 48 deletions(-)