Rémi Arnaud (remi++at++intrinsic.com)
Fri, 3 Sep 1999 16:27:13 -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.
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.
Go check it out, it has been there since January.
It has some constraints and defaults that the hardware implementation does
not have,
and the hardware implementation has problems that the software
implementation does not have... all those trade off !
>
> 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>
>
This archive was generated by hypermail 2.0b2 on Fri Sep 03 1999 - 16:27:17 PDT