Paul,
I mope I'm getting the gist of your comment. If not, please reword it,
and I'll try again.
There are a variety of reasons that any computer-generated
*presentation* (or "rendering") of a specified model will necessarily
be imperfect. One fundamental reason is that these presentations have
finite resolution, spatially and temporally, while the models
themselves do not. Another fundamental reason is along the lines you
point out, namely the implementation usually notices and prepares to
respond to an event *after* the event's occurrence. Meanwhile, the
implementation is likely giving the user the false impression that the
event did not in fact occur.
Given the inevitability of imperfect presentation of ideal models on
computers, one must decide what to present, so as to optimize the
user's experience. This question is a deep one, and is as much a
question of perceptual psychology as one of computer science or
engineering. Our own implementation is designed to go back in time to
set the system back on the correct path, based on the accurate though
somewhat belated knowledge that an event did occur, when it occurred,
and what values were associated with the occurrence. I suspect that
maintaining a few low orders of spatial continuity will be
perceptually desirable, even though doing so slightly prolongs the time
interval during which the user experiences an inaccurate result. We
will need to do more experimentation and user testing before concluding
what approach to recommend.
Thanks for the comment.
- Conal
----------
| From: Paul Burchard <burchard@CS.Princeton.EDU>
| To: Jim Kajiya
| Cc: <www-vrml@wired.com>
| Subject: OOPS! (Re: A small comment on ActiveVRML)
| Date: Thursday, December 07, 1995 9:30PM
|
| Sorry about that junk message! :=-} Here's the real version:
|
| Jim Kajiya <kajiya@microsoft.com> writes:
| > Furthermore, there's a big payoff in thinking of
| > behavior as a *value*, that is as the thing denoted by a
| > constant like 3, instead of an object with editable state.
| > As this is a deep idea that would take much space to
| > fully explain (it's really the conceptual kernel hat
| > motivates the functional programming community to
| > essashion general purpose programming), perhaps it
| > would be better to mention one surface effect of this
| > principle. Using values instead of objects makes
| > shared, distributed programs--the very www and VRML
| > future applications that people are excited
| > about--very easy because we don't have to synchronize
| > the update of state in disparate locations.
|
| Sorry, you can't just define the problem away. There is one
| well-known, fundamental problem with the functional approach:
| dealing with reality. That's because we have only one of them, and
| its value is only revealed to us over time.
|
| What you are proposing would be useful for flexible dead-reckoning.
| But what if you received a behavior which operates over a time
| interval whose beginning has alesady passed and which affects what
| the user sees (in the past)? Rollback is just one solution to the
| synchronization problem, and not necessarily the most desirable one.
|
|
| P.S. Could you please provide the spec proposal in a portable
| format? Every PostScript interpreter (Adobe and non-Adobe) that
| I've tried so far complains of errors in the PostScript generated by
| MS Word.
|
| --------------------------------------------------------------------
| Paul Burchard <burchard@cs.princeton.edu>
| ``I'm still learning how to count backwards from infinity...''
| --------------------------------------------------------------------
|