User:Vrmlguy

From Wikipedia, the free encyclopedia
Committed identity: cd3bbb7c621fc1309b91f023e4643b627ca9e4737c86b8280fc9569456cec401523e22f3c3c721553b3feccdeb2698e0c6d7094b2c86ac46f70ad66b06ee97ff is a SHA-512 commitment to this user's real-life identity.

"User:Samwyse" was already taken, so I've had to fall back on my (much older) Slashdot userid. At the time that I first joined Slashdot, I was a contributer[1] to the for VRML 2.0 specifications, thus the name. Who knew that VRML would flop so spectacularly[2]?

VRML 2.0 and me[edit]

This section is my rant against a decision reached in 1996 about a technology that has since withered away. You see, I'm the guy who wrote the "Touch Sensor"[3] section of the VRML 2.0 specification, maybe two pages out of 207. Perhaps "wrote" is too strong of a word; there had been (IIRC) a section titled "Mouse Sensor" that I thought was unnecessarily oriented towards 2-D input devices, so I re-wrote it to use a 3-D positioning device. Everybody loved it and it was quickly adopted.

I also pushed hard for a minor "fix" to the Time Sensor, but everyone from the SGI Cosmo team shot me down. The reason given was that I'd noticed the issue too late and the spec had been set in stone, never to be changed. I accepted that reason, but then two weeks later a change of greater impact to a different section was pushed through by the same people who'd rejected my change. Obviously, I still feel a bit of resentment.

To understand my fix, you have to understand what a Time Sensor does:

TimeSensors generate events as time passes. TimeSensors can be used to drive continuous simulations and animations, periodic activities (e.g., one per minute), and/or single occurrence events such as an alarm clock. [...] The remaining outputs generate continuous events and consist of fraction_changed, which is an SFFloat in the closed interval [0,1] representing the completed fraction of the current cycle, and time, an SFTime event specifying the absolute time for a given simulation tick.

I objected to the way that the value of fraction_changed events was computed:

 time = now
 f = fmod(now - startTime, cycleInterval)
 if (f == 0.0 && now > startTime)
   fraction_changed = 1.0
 else
   fraction_changed = f / cycleInterval

I felt then (and obviously still do today) that fraction_changed should only become 1.0 for non-looping sensors, i.e. the code should have instead been:

 time = now
 f = fmod(now - startTime, cycleInterval)
 if (!loop && f == 0.0 && now > startTime)
   fraction_changed = 1.0
 else
   fraction_changed = f / cycleInterval

My reasoning was that items such as clocks never reach the end of a cycle; the second hand may get arbitrarily close to 60, but it resets to 0.0 when the next minute starts. As a result, in some cases you'd need to undo the assignment of 1.0 in your script. Everyone agreed with my reasoning, but shot me down anyway. Oh well.

Wikipedia Users Whom I Know[edit]

User:Sdenton-at-math.ucdavis

Footnotes[edit]