As was mentioned, cryptography and hashing require a balance between security and usability. If you set the security too high, the user will be put off and avoid using your OS. If you set it too low, hackers will easily crack the system.
As argon2 is quite different from your bcrypt example, it would be wise to follow the strategy in the paper recommended by Otus.
Depending on the goals of your system, you may want to have dynamic values rather than static ones.
When the OS is installed, the user could select a value for usability vs security, which represents your maximum t value.
The OS could then detect the available RAM and designate a portion of the RAM for the m value: m=x*RAM.
You could also ask or detect the number of CPUs, Cores, threads, etc and use a portion of those as the h value: h = x*maxthreads.
Then you run a time test across a range of t values until the magic threshold of usability/security is determined.
Save the resultant values in some config file. and add a script to adjust them in the future.
For logging into a high security system, a user may be willing to wait over a second for the validation, but in a high usability system, users want instant gratification so something on the order of 1-50 milliseconds may be required to keep them happy.
A good starting point for m is 0.75 * ( RAM / number_of_users ) a high security system may require a larger multiple than 0.75, but you don't want to go over RAM, because that will greatly slow things down.
For h, the best starting point is the number of cores.
t should then be calculated based on how long it takes to make or verify the hash.