Re: GIS

New Message Reply Date view Thread view Subject view Author view

Phil Keslin (philk++at++cthulhu.engr.sgi.com)
Fri, 03 Sep 1999 16:05:54 -0700


Some clarification is needed in case there is a perceived incongruity
between the claims made in this email and other statements made about
the viability of clipmapping on non iR systems.

Specifically, one of the objectives of clipmapping is to avoid changing
texture id's across polygons in the database or imposing any constraints
on the layout of geometry. Conventional database paging strategies
suffer from these methods which are required to seamlessly manage
texture memory as the eye moves over the database. Tools like those from
Terrex build a tiled terrain pyramid much like the clip texture MIP
pyramid tiles but it is not treated as a single contiguous image entity
during rendering. That is a key difference.

The approach described here, while useful for using your cliptexture
database suffers from some of the same overheads and quality issues of a
conventional paging technique although it uses the same MIP pyramid file
system. That's because it has more in common with traditional approaches
than it does with clipmapping. It is also a solution level approach,
which is an important distinction between the role of Performer and the
role of higher level software. In general Performer refrains from
assuming the responsibility of setting state information in the scene
graph, for example going in and modifying texture id's or other state
information. That's one of the appealing features of cliptexture,
Performer can manage the image content and pretty much leave the
database polygons and state information alone.

In summary, we've never said database paging requires cliptexture, it
helps. It's important to understand when discussing a database paging
method that using the same database structure as a cliptexture doesn't
mean that you are in fact cliptexturing. You may find that you are
simply using a more conventional approach with some associated
restrictions or at least relinquishing a degree of control over your
database, albeit with compelling reasons to do so.

-Phil

Rémi Arnaud wrote:
>
> > Well it's still not clear to me. You've explained what Performer
> > does and the complexity and why it's hard etc. But I've yet to
> > glean any understanding of what specific hardware feature must exist
> > to accomplish all this. Sorry but saying you can only do it on
> > IR is not enough. What "Hardware" is missing from an Octane or an O2
> > that prevents clip-mapping. Is it a systems thing or is there some
> mystical
> > clip-mapping asic?
>
> IR has per pixel computation for texture LOD.
> Without that hardware feature the best you can do is per polygon or even
> geoset computation.
> Everything else can be done with standard openGL.
>
> On the other hand, the software version does not have limitations that the
> hardware version has :-)
> You can see for yourself if you download the O2 software clipmapping at
> www.intrinsic.com , done by Chris Tanner and Michel Jones.
>
> What that demonstration shows is that the same (clipmap included) database
> and (performer) software can be used on platforms with or without the
> hardware capability.
> The performance and quality of the result will not be the same, but that is
> a trade-off that can be done by the integrator/user/application developper.
>
> -- Rémi
> Intrinsic Graphics
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

-- 
Phil Keslin <philk++at++engr.sgi.com>

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Fri Sep 03 1999 - 16:06:01 PDT

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