From: Angus Dorbie (dorbie++at++sgi.com)
Date: 05/02/2000 07:11:43
It sounds like it is probably jello. The best way to describe the
difference I've heard is you can take a screen shot of jello which shows
the problem but you can't take a screen shot of wobble.
The methods you derscibe to fix this reduce the active area of good
texture and buy you back texture coordinate interpolation precision. If
you look again at your situation you may find that the polygons in
question are being clipped which is one set of circumstances which can
expose the issue and may be why the problem seems to be related to your
underlying triangulation.
The problem looks like it could be a misinterpretation of the meaning of
the box distances, the algorithm attempts to optimize LOD useage to
those required when rendering the geometry within the specified box
ranges assuming a simple surface, by asking the lod computation a
question which requires all those levels it cannot optimize for jello.
The idea is that you supply a ring (actually two concentric squares)
where all geometry lies between those squares. If your inner square is
very close and your outer two far away the algorithm will try to
estimate usefull texture LOD's for that region. It neither knows nor
cares about your geometry granularity, it has no impact on the
algorithm, the application must ensure the appropriate LOD's are applied
to the geometry in the specified regions.
There is an algorithmically simpler approach to this whole affair which
doesn't require all this complexity and is actually much more elegant.
First, you determine how many LODs you require by experimentation for
two or three different ranges (sounds like you've already done this as
most people do). Then on the fly you determine how far a tile is away.
You know the scale of your texture so all you need to do is ensure you
go far enough up your MIP pyramid to include the texture required by
that tile i,e make sure your highest level clipsize region fully
includes that geometry (pad it a lot by subtracting a level and remember
the invalid border). So it all boils down to a simple range test which
maps directly to an offset+numeffectivelevels value, and you already
know what numeffectivelevels should be for that range. A sufficiently
large numeffectivelevels then gives you the higher resolution you need
nearer the eye (i.e. means a smaller offset). If your database is too
coarse grained then you will lose resolution towards the eye with this
method but will see no artifacts and you will know to either increase
numeffectivelevels (in which case you might introduce jello) or create a
finer grained database with more frequent LOD adjustments.
CHeers,Angus.
ihawkes2++at++csc.com wrote:
>
> Hi,
> Our Performer application currently has some problems with cliptexture wobble.
> The Performer documentation suggests that jello strikes the high texel quadrant
> of the cliptexture relative to the clipcenter, but in this case the "wobble"
> seems to be aligned with polygons and is independent of the quadrant. Only a few
> polygons seem to be affected. When clipflying the problem area, the cliptexture
> wobble can be fixed by either increasing the LOD Offset or decreasing the number
> of effective levels.
> Does this sound like jello, or is this some other problem that we are seeing?
>
> I am using IRIX 6.5.6f and Performer 2.2.7 on an Onyx2 system. I am currently
> using a 19 level (ie 262144 texels per side) virtual cliptexture, although we
> plan to eventually increase the number of levels. In our application, I am
> setting the virtual cliptexture parameters per tile, and the texture wobble is
> visible on various polygons on the closest tiles. The side length of the tile
> in texture coordinates is approximately 0.02798 (ie 7335 finest level texels). I
> have implemented an algorithm to calculate the virtual cliptexture parameters
> based on what I found in the virtcliptex.c and pfspherepatch.C samples, using
> pfuCalcSizeFinestMipLOD and pfuCalcVirtualClipTexParams (see attached
> pseudo-code):
> (See attached file: ctAlgorithm.pseudo)
> The results from the algorithm are as follows:
>
> for the closest tiles (when tile closest distance = 160.877472):
> nLevels = 19 clipSize = 1024 invalidBorder = 16 min_dst_dxyz = 0.000004
> minLODTexPix = 0.000000
> minLODLoaded= 0.000001 maxLODLoaded =18.000000 bboxMinDist = 0.000000
> bboxMaxDist = 0.025390 tradeoff = 1.000000
> LODOffset 0 numEffectiveLevels 16 minLOD 0.000001 maxLOD 6.000000
>
> for intermediate distance tiles (when tile closest distance = 1056.229858) I
> get:
> nLevels = 19 clipSize = 1024 invalidBorder = 16 min_dst_dxyz = 0.000004
> minLODTexPix = 0.000000
> minLODLoaded= 0.000001 maxLODLoaded =18.000000 bboxMinDist = 0.002594
> bboxMaxDist = 0.030579 tradeoff = 1.000000
> LODOffset 1 numEffectiveLevels 15 minLOD 0.000001 maxLOD 7.000000
>
> and for more distant tiles (when tile centre distance = 26882.296875) I get:
> nLevels = 19 clipSize = 1024 invalidBorder = 16 min_dst_dxyz = 0.000004
> minLODTexPix = 4.078858
> minLODLoaded= 0.000001 maxLODLoaded =18.000000 bboxMinDist = 0.081358
> bboxMaxDist = 0.109342 tradeoff = 1.000000
> LODOffset 6 numEffectiveLevels 12 minLOD 0.000001 maxLOD 12.000000
>
> I was surprised to see that the algorithm is giving me numEffectiveLevels = 16
> for the closest tiles, rather than a smaller value that will reduce the
> likelihood of jello. Looking at the pfuCalcVirtualClipTexParams code, it appears
> that if I reduce my bboxMaxDist in the case of the closest tile (ie reduce the
> tile size), then the calculated numEffectiveLevels will decrease and perhaps the
> "cliptexture wobble" will improve. However, the tile is already pretty small in
> terms of finest-level texels and is well under the recommended 16K limit. Is
> tile size likely to be the problem here, or are there some other factors
> involved? Perhaps some of my other inputs to pfuCalcVirtualClipTexParams are
> incorrect?
>
> Also, what is the meaning of the minLOD & maxLOD values calculated by
> pfuCalcVirtualClipTexParams? Aren't the LODOffset & numEffectiveLevels enough to
> specify the levels in use?
>
> Any suggestions would be most appreciated!
>
> Thanks,
> Ian Hawkes
> CSC Australia
>
> ------------------------------------------------------------------------
> Name: ctAlgorithm.pseudo
> ctAlgorithm.pseudo Type: unspecified type (application/octet-stream)
> Encoding: base64
-- For Performer+OpenGL tutorials http://www.dorbie.com/"In the middle of difficulty lies opportunity." --Albert Einstein
This archive was generated by hypermail 2b29 : Tue May 02 2000 - 07:11:54 PDT