On Fri, 17 Apr 2015, Douglas Maxwell wrote:
The time it took for the physics and simulation to run not including the sleep time, divided by the minFrameTime passed into the program from the OpenSimDefaults.ini file variable MinFrameTime. This would mean that a value of 1 is no sleep necessary, less than 1 and the program slept for some remaining amount of time, and greater than 1 the physics and simulation took longer to run than the allotted time.
On Sat, 18 Apr 2015, Sean M wrote:
Our proposed changes positively unbinds dilation; the new calculation ranges from [0:Infinity). The previously intended range of [0:1] artificially places a limit on how long the simulator has waited for physics; this limit is not accurate because, theoretically, a physics frame can take forever.
As far as I can see, Dahlia et al. are pointing out that you are using the inverse of the original (SL) definition of time dilation. A time dilation of 0.0, according to SL, means that the simulator has come to a stand-still, so a single frame is taking forever to process.
There is therefore no "artificial limit" on the sim sloth reportable with a range [0,1].
You could argue that there is an artificial limit at the other end of the range: if an SL sim reports time dilation 1, that only says "I'm fine", but not how much spare capacity there is.
Couldn't you just report 1.0/(what you proposed)? Then you would have compatibility with the SL definition, plus new information about extra capacity in the 1+ range (easily capped to 1 in viewer code if need be).
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
