Hello,
I am currently developing a Unity application where I need very high accuracy and stability from the Unity Engine during long periods of time. It would atleast need to be running for days or months, or optimally for years. It would not be impossible to restart the Unity application, but very unfortunate.
The application is supposed to be an Unity Web GL application. I need very high stability and accuracy in rotation and collision detection (OnTriggerEnter and OnTriggerExit) mostly. There will also run 2 WaitForSeconds(0.1f) calls for the whole duration and it’s important this doesn’t become inaccurate (meaning more than ± 0.1f).
We are not talking about my personal-made floats becoming inaccurate over a long course of time, but if there are any UnityEngine stability issues or UnityEngine floats/variables or whatever that would become inaccurate over the course of a day, month, year then this is what I am interested in.
Thanks in advance, Eirik.
Ohh well, where should I start here ^^. First of all a WebGL build will probably never be anything close to “stable”. An application running in a JS sanbox in an emulated environment with a virtual heap, emulated garbage collection inside a garbage collected environment inside a multi page browser is prone to suffer from timing issues.
Apart from all those external influences (browser tab in the background receives way less updates and varies heavily from browser to browser), there are some things in the Unity engine that aren’t designed for long running applications. Have a look at my post over here regarding floats in general but with the concrete example of Time.time.
Using coroutines and WaitForSeconds to track time will never be accurate. It highly depends on your usecase, but for long running systems you usually want to use the system time to time anything in your application.
Not sure what this has to be with phyics though. For the same reasons mentioned above, if any values get larger and larger you will run into floating point issues. However if the values stay bounded relatively close to 0 there shouldn’t be much issues. Though keep in mind that the physics system is not a scientific physics system. Nvidia’s PhysX is designed to be fast, not accurate. It contains many simplifications that are not physically accurate. Two examples are drag and also that it does not preserve angular momentum but just angular velocity. So certain physical effects (like the middle axis theorem) are simply not possible.
So it’s actually impossible to give a clear answer to your question because we don’t know what this is all about and what parts are important. Also I don’t think most people have done long-time tests of the Unity engine. We as developers simply do not know how Unity or certain parts of Unity are implemented on the native side. We can only do blackbox testing and any long term effects can only be seen if you actually let it run for that long.
Though if we just talk about certain limits, beside the mentioned floating point accuracy degrading, any integer values of course are also limited to the bit size of the integer type. So for example Time.frameCount is a signed Int32. If your game runs at 60fps the frame counter is enough to count up for about 414 days, so a bit over a year. After that time the counter has to either reset or may even wrap into the negative values. Unity as so many parts that it’s impossible to think of all of them.
Keep in mind that you will have issues like that on any system. Think about the GetTickCount function of the windows API. It counts the milliseconds since system start in a 32 bit unsigned integer. This will only last for about 49 days. Any system that uses the tick count to measure time or delays could fail when the counter wraps around. All integer types have some max value at which they will eventually wrap around if they are always increasing. Floating point value will never wrap around but they can saturate and either “get stuck” at a value or saturate to infinite any get stuck there instead.