Re: GIS (and cliptextures)

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Mon, 04 Oct 1999 12:52:47 -0700


There are different levels of functionality in a clip texture.

Think of the Performer design as a multilevel cache. The data on disk
contains the entire texture, the host memory representation contains an
image cache at each level of MIP holding several coarse image tiles
immediately surrounding the region which can be stored in hardware
texture memory. The data in host memory is loaded into texture memory in
a fine grained way to replace old data as the clip region moves over the
database. Less frequently new image tile data is paged to update the
image cache as it moves.

The image cache & image tile system should work on most hardware. The
piece of the puzzle which is missing is that associated with the clip
texture representation in graphics hardware. Unfortunately this is the
part what makes clip texture technically interesting. There are paging
mechanisms which have been used for years which divide the database into
regions where state can be managed such that the image tiles are applied
directly to the graph.

A clip texture holds a single texture in graphics hardware and applies
it at various resolutions (as available) to the fragments as they are
drawn. For this it needs a torroidal addressing scheme, invalid borders
for paging and more complex MIP lod selection.

You could use an image cache like paging scheme but you'd need a
different method for applying the texture to the database. I could go
into more detail on this but it's probably best done with some diagrams.
I'm considering presenting something on clip texturing at iitsec for
those interested in it, with a bit more detail on getting around jello &
other issues like what can be done on conventional hardware. It might be
at FOP, or it could be at some other more formal SGI training event,
we're still deliberating.

Cheers,Angus.

Simon Pigot wrote:
>
> Sorry to pick up so late on this but I'm kind of curious about whether
> pfImageCache (the underlying texture tile pager and toroidal loader for
> pfClipTexture) can actually be used on hardware other than InfiniteReality. To
> refresh your memories:
>
> Angus Dorbie wrote sometime back (Fri, 03 Sept) about cliptextures:
> > It's an OpenGL extension to support the torroidal scrolling of physical
> > texture memory over a larger virtualized texture area. It includes the
> > specification of an invalid border surrounding the moving texture memory
> > border where paging can occur invisibly at various levels of MIP and
> > when rendering if data at a given MIP level is not present the lowest
> > available level is used. The actual download uses glsubtexload.
>
> When running the icache and icache_mwin test programs everything appears to work
> just fine on hardware such as the good old Crimson RealityEngine :-)
>
> > Performer uses this OpenGL extension and adds fast disk i/o, host memory
> > management, multiprocessing, load balancing of downloads and in general
> > simple management of the whole process by specifying a CLIP center and
> > tweaking a lot of parameters.
> >
>
> Looks to me like only the actual pfClipTexture bit requires/uses the appropriate
> OpenGL hardware extensions - is this correct? If so, then maybe its possible
> (particularly for RealityEngine which doesnt support EXT_texture_lod and thus
> bogs down quickly on texture paging) to use the pfImageCache to drive a
> high-detail texture tile across a paging ASD. I can do a tile of 1024x1024 with
> a RM4(s) (and 2048x2048 with RM5(s)) in the Crimson RE. Any reason why this
> wouldnt work? Obviously I'm not expecting 30 frames/sec but 10 frames/sec would
> be nice enough especially since (a) its unlikely that we'll ever have an
> InfiniteReality of any kind down here (much as we'd like to have one) (b) paging
> ASDs of quite high detail already work nicely (given its age) on Crimson RE.
>
> Cheers,
> Simon
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

-- 
"One of the best-known folk theorems of software engineering is that
60% to 75% of conventional software projects are either never
completed or rejected by their intended users. If that range is
anywhere near true (and I've never met a manager of any experience
who disputes it) then more projects than not are being aimed at goals
which are either (a) not realistically attainable, or (b) just plain
wrong."
                 Eric S. Raymond - The Cathedral and The Bazaar

For advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Oct 04 1999 - 12:52:54 PDT

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