Clip map blues...

New Message Reply Date view Thread view Subject view Author view

Jim Durbin (durbin++at++ait.nrl.navy.mil)
Thu, 23 Jan 1997 14:27:23 -0500 (EST)

We, like everybody else these days, are working with large terrain
databases created from dted and high-res imagry.

We are currently using a 8k by 8k clip-map texture pyramid. When the
application is running, we notice that the bottom left corner
(cooresponding to the origin of our world) has a high-res texture tile
loaded. Moving out from that corner along the x and y axes, the
texture tiles displayed are from progressively lower-res levels of the
pyramid.

No matter where we move the viewpt, the resolution of the clip map
displayed for a given tile does not change. The same behavior is
observed when the textured object is moved and the viewpt is held
constant.

Also, in one of our applications, the high-res texture in the bottom
left corner was replaced when the texture model was scaled up with a
stale texture that was from another application that was run 4 days
prior. We were finally succesfull at flushing that texture by
rebooting the machine. Has anyone else seen this type of behavior?

However, when we load the same model into perfly, the clipmap behavior
works perfectly.

What am I missing? Is there an extra step that I need to take to
inform Performer to recalculate the clipmap?

Should I be able to move the textured model and leave the viewpt
constant (position and hpr with respect to world coordinates) and get
the same affect as moving the viewpt and holding the textured model
constant?

We have an Onyx w/ 4 R10000s, one IR pipe with a single RM6/16,
running Performer 2.1 internal version number 1234000053.

=======================================================================

To make story more interesting:

We know that the clip mapping worked in one of our applications (where
the view point was changed) last week. The only known change made to
the machine between success and failure of clip mapping is the
application of:

        Patch SG0001422: IGLOO (IrisGL On OpenGL) patch for O2, Impact
                        and InfiniteReality
        Patch SG0001572: 6.2 streams rollup patch
        Patch SG0001601: mediad rollup patch
        Patch SG0001625: dmedia rollup patch
        Patch SG0001650: All platform kernel rollup patch
        Patch SG0001667: XFS rollup #6 for 6.2
        Patch SG0001679: Special rollup for NFS locking FailSafe enhancements
        Patch SG0001692: fix kernel memory consumption on cachefs during find

Removal of those patches has not corrected the situation. It is my
guess that the patches are irrelevant, but I include here for
completness.

Any suggestions would be greatly appreciated!

Thanks!

-Jim

-- 
_________________________________________________________________________
|	Jim Durbin			     durbin++at++nrl.navy.mil        |
|	ITD Virtual Reality Lab		     (202) 767-6025		|
|	Naval Research Laboratory	     (202) 767-1122 (fax)       |
|		http://www.ait.nrl.navy.mil/people/durbin		|
|									|
|  "It is much easier to criticize an idea than it is to conceive it."	|
|							anonymous	|
|   Lack of brains hinders research - The Columbus Dispatch, April 16   |
_________________________________________________________________________
=======================================================================
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:27 PDT

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