Search Unity

Unity DOTS Physics Enhancements - double, quad, decimal, arbitrary precision

Discussion in 'Physics for ECS' started by egable, Feb 2, 2021.

  1. egable

    egable

    Joined:
    May 21, 2014
    Posts:
    23


    I am working on an overhaul of the Unity DOTS Framework to support double-precision and other enhanced precision types. While I am certain there is demand from the gaming community for double precision physics in Unity, I am curious how much demand exists for supporting decimal, quad, and arbitrary precision physics?

    My initial plan was to support just double-precision physics. But as I started working through that support, I realized it would be relatively trivial for me to include other types, like Decimal. Then I considered that non-gaming users of Unity may be interested in creating highly accurate scientific or mathematical simulations of various real-world problems using Unity. So, I did some preliminary work to determine what it would take to support such work. From my research, it seems like it would require arbitrary precision support. I located what looks like a solid implementation of arbitrary precision integers and floats which I could fairly easily convert into something useable by the Unity DOTS framework. It would add quad precision and arbitrary precision options to the physics. These would obviously not be real-time oriented physics options with calculations taking 20+ times as long as something like a double-precision implementation.

    After working with the arbitrary precision code for a bit, I have determined it will probably add one to two more months onto the project. So, before I go down the road of implementing that support, I wanted to get some feedback on who all might be interested in using it and what sorts of other considerations I might need to take into account for those use cases. I have outlined the support in my settings page, and will be writing the settings system to eventually support arbitrary precision. Aside from what I have outlined here, is there anything in particular anyone in the community can think of which I might need to add or consider in the implementation for it to be worthwhile?

    Before anyone gets too excited, I will note that there is a LOT of work left to do here before there is even something I can demo. At a minimum, I need to finish reworking code in the DOTS framework (including the various editor parts), as well as build some shaders which can ingest the different numeric types. I also have not completely ruled out the possible need for a final shift to a floating origin / float-based rendering to the screen. My goal is to push the higher precision types as close to the GPU as possible before any final shift to 64-bit or 32-bit float for final display.

    Also, note that this project does not solve any of the issues related to 3rd party tools like Vegetation Studio or anything else supporting 64-bit or higher precision types (or even supporting the DOTS framework). This project really just lays the groundwork for that type of additional work to start taking place.

    If you want to follow my work on this, you can do so here: https://github.com/egable/unity-dots-physics-double/wiki
     
    MNNoxMortem, bb8_1, apkdev and 4 others like this.
  2. Phenotype

    Phenotype

    Joined:
    Oct 26, 2010
    Posts:
    53
    Sounds interesting. I could certainly use more datatypes for my simulations. What is the status of this work?
     
  3. TobiasWeber

    TobiasWeber

    Joined:
    Mar 8, 2021
    Posts:
    7
    Great to see somebody is working on a double precision physics backend!

    I just run into an issue caused by limited accuracy of todays float based system. In my case I don't see the immanent need to have higher precision types as quad or arbitrary. Fixed point and decimal types could be helpful, especially when porting to other embedded platforms.

    I suspect the dots interface itself still is limited to float? So just the Physics internal types are double? In that case it would be helpful to have the ability to query / subscribe specific output from physics engine in higher precision (double).

    Just had the case that a free falling body, using small dt (<=0.0001) calculates wrong speed and acceleration as I have to derive it from Transform, which has float accuracy only. I had to use the Transform as a rigidbody can not be combined with an articulated body.