From: Angus Dorbie (dorbie++at++sgi.com)
Date: 10/12/2000 10:54:43
The problems are not entirely related and occur at radically different
levels of magnification w.r.t. the coordinates.
A cliptexture can try to combat wobble because it has two numbers which
determine the texture address being applied and these can be subtracted
in the application to keep the values low in the interpolation hardware.
Conventional texture with detail does not have that option.
With clip texture if you subtract a large value from the texture
coordinates in the database and subtract the same large value from the
clip center while keeping the software clip center (for paging purposes)
large, (i.e. you lie to OpenGL about the location of the clip center and
compensate by sending lower coordinates), you can eliminate wobble.
This is a separate problem from jello, which is can be managed by
reducing numeffective levels and adjusting the MIP lod offset to use the
appropriate levels in the clip stack in a virtual clip texture.
If reducing numeffectivelevels doesn't help then it is very likely
wobble not jello although I'd dial the effective levels right down to
around seven before I drew such a conclusion but it depends on your
stack height, offset, magnification and geometry in arcane ways.
You want to translate the coordinates before you apply them as
attributes to the geosets rather than using say a texture matrix to
translate. You then keep the clip texture the same and provided you've
resolved the cull sorting issues you adjust the clip center in the
downstream process (say cull) by subtracting the same number to
subtracted from the vertex values.
In terms of good area size that is determined very simply by the
resolution, the offset+numeffectivelevels. The clipped MIP level at
offset+numeffectivelevels (-1 since num effective levels is inclusive)
covers a specific geographic region. This is a nice way of approximately
figuring what offset needs to be for a tile, you just get most distant
point from the center and see what level it falls within. There is a
valid concern that this may still alias because of the LOD clamp ant
offset+numeffective so you might want to add a few levels depending on
minification. The other thing is that the lowest level doesn't have a
smoothly moving border. Internally cliptexture is managed an
offset_numeffective levels in 1/4 clipsize position increments so again
that's another motivation for subtracting one level from this size
estimation.
The wobble management is entirely separate from the jello LOD virtual
stack management. It is a known subtraction from the clip center based
on the known subtraction from the known and predetermined texture
coordinate attributes.
Cheers,Angus.
Klaus Otto wrote:
>
> Hello Ian,
>
> we were having a similar problem with a normal (non-clip) texture
> overlayed with a detail texture for a ground vehicle application.
>
> We could only eliminate the wobble by reducing the span of terrain covered
> by the texture. We ended up with a span of about 400 m.
> It did not matter which resolution of the base texture we choosed (2048x2048
> or 512x512) nor which size the individual terrain polys had.
>
> This is an excerpt from the answer we got from SGI support at that time:
>
> The problem still is the magnification of the texture close to the
> eyepoint. Making the polygons smaller only does not work, there is
> still not enough texture resolution available for the first 5 to
> 10 metres.
> The use of detail textures helps, but the choosen texture still
> spans too big an area.
> [..snip..]
> Clipmapping only helps when high resolution textures are available.
> End of excerpt.
>
> So, it does not seem to be a problem of texture(vertex) coordinates but
> of the (hardware/firmware) resolution the texel2pixel mapping inside the poly
> is calculated with.
>
> Hope this helps in your case,
>
> Klaus
>
> On 12 Oct 00, at 16:11, ihawkes2++at++csc.com.au wrote:
>
> > Hi,
> > I am having some problems curing a cliptexture of wobble/jello problems
> > (Performer 2.2.8; Irix 6.5.8f on an Onyx2).
> [ ... snip ...]
> > So, my questions are ...
> >
> > 1) Examples of wobbly tex coords (before translation) include the area
> > around (0.917722, 0.266216) and also (perhaps less severely) around
> > (0.095587, 0.362692). Would you expect precision problems at these values?
> >
> > 2) Any ideas why neither reducing the num effective levels, nor translating
> > the texcoords seems to improve things? Is it possible that the polygons
> > involved are just too big?
> >
> > 3) Assuming that translating tex coords is the way to go, how should I
> > incorporate it into my cliptexture strategy which tiles the cliptexture,
> > and uses pre-cull node callbacks to set the virtual cliptexture params for
> > each tile. Should I use the largest (_numEffectiveLevels+Offset) of all the
> > tile callbacks in order to calculate the goodAreaSize and then do the
> > translation and the applyCenter a frame later in the pre-cull (since it
> > doesn't work postcull)?
> >
> > Any help would be most appreciated!
> >
> > Thanks,
> > Ian Hawkes
> >
> >
> >
> >
> >
> >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> >
>
> ------------------------------------------------------
> | Klaus Otto | |
> | CAE Elektronik GmbH | Email: kotto++at++cae-gmbh.de |
> | Abt. Systemtechnik | |
> | Steinfurt 11 | Tel. : +49-2402-106-456 |
> | D-52222 Stolberg | Fax : +49-2402-106-270 |
> | Germany | Web : http://www.cae.de |
> ------------------------------------------------------
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
-- For Performer+OpenGL tutorials http://www.dorbie.com/"In the middle of difficulty lies opportunity." --Albert Einstein
This archive was generated by hypermail 2b29 : Thu Oct 12 2000 - 10:54:52 PDT