pete_leaback@cix.compulink.co.uk (Peter Leaback) (01/31/91)
I agree with many of your points.
A standard language that deals with object communication and interaction
is essential.
But..
You say VR is here, it is only *JUST* here. At the moment, the
programming of VR's are coupled very tightly to the hardware because of
the crippling restrictions of the hardware.
A VR system has to display a frame at 50 or 60 Hz or else one tends to
get sick. If one standardises the object destription and rendering, each
machine that has implemented the language is required to render images at
roughly the same *speed*.
The examples you gave of functions that have been pulled away from the
hardware has only come about because the hardware has *allowed* it.
Machines are fast/large enough for the OS to be portable. Laser printers
have become standard because the resolution is similar and speed is not
essential.
VR is not at the point where it can peal off completely from the
hardware.
I suggest that a standard language should be layered in its definition.
The highest would be such that it can be realistically implemented on
most hardware.As our hardware progresses, subsequent levels would be
defined.
If a *complete* VR language is defined today, it would either be too
restrictive or impossible to implement.
An area of computing has a critical mass before it is useful to start
standardising. In a few years, the non trivial layers of a VR can start
to be standardised.
E.G. a scene is defined with trees, a path, some rocks and a light
source. A low end VR machine would implement the scene with flat faced
polygons, no light source, no shadows and at low resolution. A high end
machine would plot a much more realistic scene, but basicly the same as
the low end machine.
My point is that, at the moment, many machines won't be able to render
that many objects using *ANY* method! So what would the program do ? Miss
out 50 trees ?
Regards,
Peter Leaback.frerichs@ux1.cso.uiuc.edu (David J Frerichs) (02/02/91)
In article <15594@milton.u.washington.edu> pete_leaback@cix.compulink.co.uk (Pet er Leaback) writes: [things wiped out] >A VR system has to display a frame at 50 or 60 Hz or else one tends to >get sick. If one standardises the object destription and rendering, each [things abolished] Have you used a VR sytem before...? No VR system in existence has a frame rate that high. (if there is, I will be quite impressed.) This is not a exact figure, but the VPL system only has a frame rate of about 8Hz per eye (I have heard it is lower that that even). Systems I have used have rates higher than that (no numbers allowed) but still they don't come close to 60Hz (I hope that you are talking about the frame rates of both eyes, not just one.) Your statement that one tends to get sick at a low frame rate is false (IMHO). Please forgive my forwardness if you have experienced this sickness first hand. Low frame rates only make for choppy movement, not flickering. It just means that the frame stays in the buffer longer. When you are doing computer animation, you don't just flash a picture and take it away, you hold a picture up til the next one is ready. High frame rate means smoother motion, not less flicker (flicker has to do with the display hardware frequency). I think that alot of people in the newsgroup have been making statements that they think sound good at the time but aren't supported by any facts, not a good practice if we are to get to the root of some of the problems that face our industry. If you are going to make wide statements about tech, do your homework, or make sure you say that this is your opinion, not a solid fact. [dfRERICHS University of Illinois, Urbana Designing VR systems that work... Dept. of Computer Engineering Networked VR. IEEE/SigGraph _ _ _ frerichs@ux1.cso.uiuc.edu _/_\__/_\__/_\_ frerichs@well.sf.ca.us \_/ \_/ \_/ ]
jwtlai@watcgl.waterloo.edu (Jim W Lai) (02/02/91)
In article <15594@milton.u.washington.edu> pete_leaback@cix.compulink.co.uk (Pet er Leaback) writes: >You say VR is here, it is only *JUST* here. At the moment, the >programming of VR's are coupled very tightly to the hardware because of >the crippling restrictions of the hardware. > >A VR system has to display a frame at 50 or 60 Hz or else one tends to >get sick. If one standardises the object destription and rendering, each >machine that has implemented the language is required to render images at >roughly the same *speed*. These frame rate restrictions are due to currently available mass-produced monitors. Note that the 50Hz and 60Hz frame rates correspond to the rates of the two dominant power standards. Psychoperceptual studies done in HDTV research. Such studies have indicated that frame rates of 80Hz or higher are improve the quality of the perceived image significantly. >I suggest that a standard language should be layered in its definition. >The highest would be such that it can be realistically implemented on >most hardware.As our hardware progresses, subsequent levels would be >defined. > >If a *complete* VR language is defined today, it would either be too >restrictive or impossible to implement. I generally agree. Let's find out what works well in VR before deciding on it as a standard, rather than jumping the gun and potentially being stuck with the VR equivalent of COBOL. However, I disagree with a standard that can be realistically implemented on current hardware as being the solution. HDTV research has been done for approximately twenty years, but only with the relatively recent advances in chip technology have such sets been feasible and mass producable.
williamb@milton.u.washington.edu (William Bricken) (02/04/91)
In article <15638@milton.u.washington.edu> frerichs@ux1.cso.uiuc.edu (David J Fr erichs) writes: >I think that alot of people in the newsgroup have been making statements >that they think sound good at the time but aren't supported by any facts, One problem is that we don't have a consistent definition of what we are communally talking about. A taxonomy of types of VR would be helpful. I assume the above comment is about *inclusive VR*, like VPL systems. I strongly sympathize with David's comment. Could folks who post about VR please try to include the basis of the observation. Like * read about this * spent ten minutes in VR once * logged twenty hours total in VR * gossip * generalizing my expertise, no experience It's funny how folks working with hardware don't fall into the problem of over-generalization. Software and psychology comments tend not to provide the experiential or research anchors. William Bricken Principal Scientist, HITL
danr@uunet.UU.NET (Dan Rosenfeld) (02/05/91)
frerichs@ux1.cso.uiuc.edu (David J Frerichs) writes: >In article <15594@milton.u.washington.edu> pete_leaback@cix.compulink.co.uk (Peter Leaback) writes: >[things wiped out] >>A VR system has to display a frame at 50 or 60 Hz or else one tends to >>get sick. If one standardises the object destription and rendering, each >[things abolished] >Your statement that one tends to get sick at a low frame rate is false >(IMHO). Please forgive my forwardness if you have experienced this sickness >first hand. Low frame rates only make for choppy movement, not flickering. >It just means that the frame stays in the buffer longer. When you are >doing computer animation, you don't just flash a picture and take it >away, you hold a picture up til the next one is ready. High frame rate >means smoother motion, not less flicker (flicker has to do with the display >hardware frequency). >I think that alot of people in the newsgroup have been making statements >that they think sound good at the time but aren't supported by any facts, >not a good practice if we are to get to the root of some of the problems >that face our industry. If you are going to make wide statements about >tech, do your homework, or make sure you say that this is your opinion, >not a solid fact. I believe there IS some evidence that low frame rates can cause nausea in simulation participants. I can't provide any references to support this, but I knew several Psychologists at NASA (Ames) who claimed that flight simulator subjects tended to get nauseous when imagery was presented at too low a rate. The issue, I believe, is not flicker, but rather the temporary inconsistency between sensory systems that low frame rate can cause. Specifically, you tilt your Polhemus-tracked head, or a flight simulator tilts you, and your vestibular system tells your brain that you are oriented a certain way. Unfortunately, your visual system is computing your head's orientation on the basis of imagery which represents your head's "view" 100ms ago. I have no understanding of why this should cause nausea, and I'm not sure whether anyone else does, but it does seem to. BTW, I have tried three VR systems and never experienced any nausea, but these demos never lasted more than ten minutes at a time. Dan Disclaimer; I don't work on the Cyberspace project, and I am not representing their views. ---------------------------------------------------------------- Dan Rosenfeld danr@autodesk.com ( ) "Enjoy life, eat out more often." S.I. Rykoff o) o) moo -- ----------------------------------------------------------------
brucec%phoebus.labs.tek.com@RELAY.CS.NET (Bruce Cohen;;50-662;LP=A;) (02/06/91)
In article <15638@milton.u.washington.edu> frerichs@ux1.cso.uiuc.edu (David J Fr erichs) writes: > > Have you used a VR sytem before...? No VR system in existence has a frame > rate that high. (if there is, I will be quite impressed.) > This is not a exact figure, but the VPL system only has > a frame rate of about 8Hz per eye (I have heard it is lower that that even). > Systems I have used have rates higher than that (no numbers allowed) but > still they don't come close to 60Hz (I hope that you are talking about > the frame rates of both eyes, not just one.) > Your statement that one tends to get sick at a low frame rate is false > (IMHO). Please forgive my forwardness if you have experienced this sickness > first hand. Low frame rates only make for choppy movement, not flickering. > It just means that the frame stays in the buffer longer. When you are > doing computer animation, you don't just flash a picture and take it > away, you hold a picture up til the next one is ready. High frame rate > means smoother motion, not less flicker (flicker has to do with the display > hardware frequency). That's true down to some minimum frame rate which depends on just how much interaction the user is trying to do. Below the minimum, you lose the ability to interact effectively with the display. In other words, if you move your head by 20 degrees and it takes more than about a quarter of a second for the view to change, you will not get feedback about the amount of angular change in time to prevent overshooting the angle you wanted. If the delay is too long (depends on the amount of angle and rate of swing) the angular velocity of your head will exceed the maximum acceptable for the feedback loop consisting of your head and the display, and you'll probably go into oscillation. Similar problems occur when you move your hand. I spent *quite* a lot of time dealing with this problem when implementing the 3D input feedback system of the Tektronix 3D terminal / workstation, now departed :-(. It turns out that the best you can do is accumulate motions while the last frame is updating, so at least you don't queue up more frame updates and fall constantly further behind. So you try as hard as you can to make the update fast. -- ------------------------------------------------------------------------ Speaker-to-managers, aka Bruce Cohen, Computer Research Lab email: brucec@tekchips.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077
brucec%phoebus.labs.tek.com@RELAY.CS.NET (Bruce Cohen;;50-662;LP=A;) (02/06/91)
I should have added to my last posting that frame rates down to about six per second (each eye) were acceptable for interaction, though ten or more was much better. Below four things went to hell in a hurry. -- ------------------------------------------------------------------------ Speaker-to-managers, aka Bruce Cohen, Computer Research Lab email: brucec@tekchips.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077