Steve Baker (sbaker++at++link.com)
Fri, 20 Mar 1998 07:37:11 -0600 (CST)
> Dan Brockway wrote:
> >
> > We at Paradigm use a similar technique in domes with our Non-Linear
> > Distortion Correction module. 60Hz can be maintained. But beware, more
> > than half of the 16.6ms frame will be spent copying the frame buffer to
> > texture memory.
>
> I just wanted to chip in here since times provided without context can
> mislead. The image readback time is entirely dependent on the
> resolution and number of readbacks to texture memory.
>
> Please tell it like it is, without simplification. At 1024x768++at++60Hz the
> readback time is around 50% but change frame rate or resolution and the
> ratio will change dramatically. I got the impression that the resolution
> of the slewed scanline problem was low and so readback overhead could be
> fairly small.
>
> Given the number of copypixels requests in my earlier advice I'd like to
> encourage you to explore readback to texture memory and drawing on quads
> or parallelograms. For high slew rates the overhead of the slew may
> cause
> excessive overdraw requirements so I suspect you still want to split the
> channel up into multiple sub channels and go for a hybrid approach.
...or you could use some custom clipping planes to render a parallelogram
shaped window. That would eliminate the overdraw issues on the rendering
phase (high slew rates would causing you to need a very wide window) -
however, the critical issue of transferring from frame buffer to texture
memory wouldn't improve and the extra clipping planes would probably
increase the geometry processing time somewhat - so Angus's plan has
some merit.
In the end it depends on the ratio of the horizontal field of view to
the maximum pan rate. If the image only pans (say) 10% of the screen
width each frame then the additional complexity introduced by Angus's
suggestion would probably be unwarranted. If the maximum pan rate is
(say) ten times the field of view - then you'll probably need Angus's
trick just to keep the width of the original window to a reasonable
size.
If the pan rate gets too high then spherical distortion will become
a problem too. Since the first rendering phase is rendering onto a
flat surface, but the distortion phase is effectively pointing that
surface in a different direction (at least at the bottom of the
screen), the image will be somewhat distorted at the bottom of the
screen. That effect becomes more and more pronounced the faster the
rotation becomes.
By splitting the original rendering into horizontal strips, you'd
be able to change the view direction for each strip and somewhat
reduce the distortion - but then you'd end up with some amount of
tearing in the image at the boundaries of those strips due to the
abrupt change in view direction at the strip boundaries.
That suggests that neither technique is going to produce a perfect
image at very high pan rates. But hopefully the image will become
so hard to understand at those high rates that it won't matter.
For objects that are moving independantly of the eye, you could
also render each strip with the moving object at a different
location (since each strip represents a different point in time).
This might be a bit over-the-top for some applications, but it's
quite necessary in at least a few special cases.
Another thing that may be relevent here is that in real human
vision, the eye/brain 'edits out' the imagery that you see when
your head+eyes pan really quickly - and fills in the gaps from memory!
There is a proper name for this effect (something like a 'circade'??)
- but I forget where I read about it. We have used this effect
in the past to solve problems with eye-trackers used to drive
mechanically targeted laser projectors in large dome displays.
At times when the eye is moving rapidly and the mechanical systems
can't keep up, you can actually turn off the video and the person
wearing the eye tracker doesn't notice!
The eye+brain is a very strange piece of equipment.
Steve Baker 817-619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc. 817-619-4028 (Fax)
2200 Arlington Downs Road SBaker++at++link.com (eMail)
Arlington, Texas. TX 76005-6171 SJBaker1++at++airmail.net (Personal eMail)
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
Ann Colby, New Orleans, LA:
"I sent out 100,000 emails for my product and received over 55 orders!"
(...and upset 99,945 other people)
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:03 PDT