Re: GIS
Angus Dorbie (dorbie++at++sgi.com)
Fri, 03 Sep 1999 17:07:46 -0700
Rémi Arnaud wrote:
>
> Hi Phil,
>
> > 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.
>
> Thanks for that clarification. I agree that this is often the case.
>
> > 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.
>
> Sorry to contradict you, but if you'd check our O2 library, you'll see that
> it is simply mapping
> Performer calls to a software emulation layer, and therefore is not a
> 'solution level approach', but relies on
> Performer for the framework.
> It does not do any of the 'bad' thinks you are talking about, and does all
> its magic transparently from the application.
>
The transparency is impressive but at some level it must modify texture
id and be somewhat dependent on the geometry described. I don't see a
significant contradiction although it's great for a developer who wants
to reuse his code and can live with the rest.
Cheers,Angus.
--
"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/
This archive was generated by hypermail 2.0b2
on Fri Sep 03 1999 - 17:07:53 PDT