MasterProjects

From Robin

(Difference between revisions)
Jump to: navigation, search
(Status and supervision)
Line 17: Line 17:
** [[graphical tools | Graphics]]
** [[graphical tools | Graphics]]
** [[Tips for making presentations | Presentations]]
** [[Tips for making presentations | Presentations]]
 +
** Unity timing / indeterminism fixing (how to get your simulator deterministic):
 +
 +
MonoBehaviour.Update() and MonoBehaviour.FixedUpdate() are common script methods to use with C# in Unity — primarily to capture functionality you want to occur at every frame in your simulation.
 +
 +
In order to time-delay your C# functions/methods to be called in your simulation (e.g. to make time-based rules for how long robots have to wait before doing something in Unity), you can (most easily, but not robustly) use the MonoBehaviour.Invoke() function and pass in the amount of seconds you want your robot to wait. Another approach to this (slightly more complex, but definitely doable (ask Frank) and much more stable) is to use a Unity Coroutine.
 +
 +
What MonoBehaviour.Update() and MonoBehaviour.Invoke() have in common (apart from being overused) is that they both depend on the thread in Unity that has to do with graphics and frame rate; so if your computer is working hard and is heating up, leading to reduced frame rate, your Update() and Invoke() functions will consequently be affected, and will (at least if time is critical for your simulation) hence lead to simulator indeterminism (i.e. you will not get identical end results from identical starting points). Conversely, MonoBehaviour.FixedUpdate() is, and Coroutines can be, dependent on fixed time in Unity. That your functionality runs on fixed time (as opposed to the first mentioned graphics thread) means that Unity keeps detailed track of time — even though your simulation might take longer in real life due to a warm computer and lower frame rate.
 +
 +
This latter way, with MonoBehaviour.FixedUpdate() and Coroutines, is *the* way to go if you want to get rid of indeterminism and inconsistent timing in your simulation, and if you want to get the same results from your Unity simulation given the same input-variables, hyperparameters, as well as the same software/code. Trust me, it can save you months of worthless debugging.
 +
 +
Some *minor* ordering indeterminisms/inconsistencies in your simulation can also occur by using MonoBehaviour.Update() in too many individual Unity GameObjects simultaneously; that is, Unity can switch up which GameObjects's Update() function it calls first if they are to be called simultaneously.
 +
* [[High_performance_computing | High performance computing]]
* [[High_performance_computing | High performance computing]]
* [[Libraries for experimentation]]
* [[Libraries for experimentation]]
* [https://www.mn.uio.no/ifi/studier/master/avslutning/index.html IFI information page on deadlines etc.]
* [https://www.mn.uio.no/ifi/studier/master/avslutning/index.html IFI information page on deadlines etc.]
* [https://www.uio.no/for-ansatte/arbeidsstotte/sta/enheter/mn/eksamen/karaktersetting%20av%20masteroppgaver/ Grading]
* [https://www.uio.no/for-ansatte/arbeidsstotte/sta/enheter/mn/eksamen/karaktersetting%20av%20masteroppgaver/ Grading]
 +
 +
Main

Revision as of 06:18, 26 October 2022

Status and supervision

Individual project pages

(make links to your own personal pages above. You are free to put whatever content you find useful at these pages. Use it to collect information for you own sake, and to have information available for supervisors or other potential collaborators in case it becomes relevant. For inspiration you can take a look at the pages of the previous students.

Resources

MonoBehaviour.Update() and MonoBehaviour.FixedUpdate() are common script methods to use with C# in Unity — primarily to capture functionality you want to occur at every frame in your simulation.

In order to time-delay your C# functions/methods to be called in your simulation (e.g. to make time-based rules for how long robots have to wait before doing something in Unity), you can (most easily, but not robustly) use the MonoBehaviour.Invoke() function and pass in the amount of seconds you want your robot to wait. Another approach to this (slightly more complex, but definitely doable (ask Frank) and much more stable) is to use a Unity Coroutine.

What MonoBehaviour.Update() and MonoBehaviour.Invoke() have in common (apart from being overused) is that they both depend on the thread in Unity that has to do with graphics and frame rate; so if your computer is working hard and is heating up, leading to reduced frame rate, your Update() and Invoke() functions will consequently be affected, and will (at least if time is critical for your simulation) hence lead to simulator indeterminism (i.e. you will not get identical end results from identical starting points). Conversely, MonoBehaviour.FixedUpdate() is, and Coroutines can be, dependent on fixed time in Unity. That your functionality runs on fixed time (as opposed to the first mentioned graphics thread) means that Unity keeps detailed track of time — even though your simulation might take longer in real life due to a warm computer and lower frame rate.

This latter way, with MonoBehaviour.FixedUpdate() and Coroutines, is *the* way to go if you want to get rid of indeterminism and inconsistent timing in your simulation, and if you want to get the same results from your Unity simulation given the same input-variables, hyperparameters, as well as the same software/code. Trust me, it can save you months of worthless debugging.

Some *minor* ordering indeterminisms/inconsistencies in your simulation can also occur by using MonoBehaviour.Update() in too many individual Unity GameObjects simultaneously; that is, Unity can switch up which GameObjects's Update() function it calls first if they are to be called simultaneously.

Main

Personal tools
Front page