Re: distortion (domes, etc)

New Message Reply Date view Thread view Subject view Author view

Javier Castellar (javier++at++sixty.asd.sgi.com)
Wed, 19 Feb 1997 13:45:45 -0800


>... lack of resolution ... That approach is OK for fairly mild distortions ...

Not in our "combined" method.
On the SGI's implementation we render MULTIPLE views to prevent the lack of
resolution before the transfer to texture. Then we copy to texture.

There is a performance trade off, but as it was demostrated in the equipe's
SAAB full dome (that was partially shown in I/ITSEC'96), the final performance
results are over most of the pre-existing dome solutions (in this case is a
nice 60hz non interlaced channel).

-Javier

On Feb 19, 8:29am, Steve Baker wrote:
> Subject: Re: distortion (domes, etc)
>
> I don't think you can do dome-type distortion by simply messing around with
> the transforms that are applied to vertices. The trouble is that non-linear
> distortion doesn't preserve straight lines.
>
> This means that polygons end up having curved edges and texture patterns also
> need to be applied on a curve.
>
> Some IG's try to kludge this by dynamically splitting polygons into smaller
> chunks so that those curved edges are approximated by straight lines. This
> works to some degree - but can cause problems with texture mapping.
>
> The only way that I know to attempt distortion correction on an SGI is
> to render the scene to an off-screen area, then to suck the resulting image
> into texture memory and use that to texture a set of polygons that
approximate
> the inverse of the surface that you are trying to correct for.
>
> This obviously takes a significant amount of time.
>
> That approach is OK for fairly mild distortions - but for drastic ones you
> can suffer from a lack of pixel resolution in some areas of the screen - and
> an excess of resolution (which will cause aliasing) in others.
>
> There are also external hardware boxes that take raw analog video and do a
> similar job (with presumably similar results - but without slowing the
> SGI box down).
>
>
>
> Steve Baker 817-619-1361 (Vox-Lab)
> Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail)
> 2200 Arlington Downs Road 817-619-4028 (Fax)
> Arlington, Texas. TX 76005-6171 Steve++at++MrEd.bgm.link.com (eMail)
> http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve
(intranet)
> http://web2.airmail.net/sjbaker1
    (external)
>
> "You can't destroy the Earth - that's where I keep all my stuff!" - The Tick.
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Steve Baker

-- 
*************************************************************************
* Javier Castellar Arribas          * Email:         javier++at++asd.sgi.com *                 
*                                   * Vmail:            	 3-1589 *            
* Member of Technical Staff         * Phone:  415-933-1589 / 2108 (lab) *
* Core Design - Applied Engineering * Fax:                 415-964-8671 *     
* Advanced Systems Division         * MailStop:                  8L-800 *
************************************************************************* 
* Silicon Graphics Inc.                                                 *
* 2011 N. Shoreline Boulevard,                                          *                        
* Mountain View, California 94043-1386, USA                             *
*************************************************************************
"Violence is the last refuge of the incompetent"
						Hardin Seldon
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:41 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.