From: ihawkes2++at++csc.com.au
Date: 01/24/2001 14:45:24
Hi Angus,
Both problems were present before I implemented tex coord offsets.
The good news is, I've found the solution for problem 1. My algorithm for
calculating the cliptexture params sets minLod = ct->getMinDTRLOD() (I
copied this from sample programs). When I am flying over the lo-res
regions, the calculated LODOffset is less than the calculated minLOD.
Apparently I need to set LODOffset = PF_MAX2(LODOffset, minLOD) in order to
stop Performer from trying to access levels that don't exist..
Unfortunately problem number 2 (the striping) still exists! Reducing num
effective levels to 9 does not help.
Regards,
Ian
Angus Dorbie <dorbie++at++sgi.com>++at++sgi.com on 23/01/2001 23:56:47
Sent by: dorbie++at++sgi.com
To: ihawkes2++at++csc.com.au
cc: info-performer++at++sgi.com
Subject: Re: Cliptexture anomalies
No I don't think 1.1 is relevant. And was IMHO more applicable to your
pervious inquiry w.r.t. wobble.
You might try further reducing num effective levels to see if that has
an impact on issue 1.
It's quite strange that you are seeing the line, you are adjusting any
clipcenter parameters in a down stream process. Is it possible that your
center offset is off by a tiny ammount equivalent to a texel say? I'm
guessing that changing the clipcenter normally in the app and lying
about it in a downstream process for the coordinate wobble correction is
off by a small ammount which somehow causes the subload to be offset by
a line.
Does this happen when you disable the anti-wobble clipcentre and
coordinate displacement?
This is a bit tenuous since I haven't thought through exactly what
coords used by the DTR code in the cull and exactly how this impacts the
subload called in the draw but I'd appreciate feedback on whether
temporarily disabling your anti-wobble code fixes the line problem. This
*might* be a clipcenter position/offset rounding issue in your code.
Cheers,ANgus.
ihawkes2++at++csc.com.au wrote:
>
> Hi Angus,
> I have set the invalid border to 16 as you suggested. It was previously 8
> in the .ct file, but I have noticed that Performer seems to boost a value
> of 8 up to 16 anyway when I call getInvalidBorder(). In answer to your
> other queries, I am using pfMPClipTexture and reducing the
> numeffectivelevels down to 12 has no effect on the problem.
>
> Another respondent has suggested that the problem may be that the only
> formats supported are rgb and raw8. He suggested trying the following
> ext_format: PFTEX_PACK_8
> int_format: PFTEX_RGB_8
> img_format: PFTEX_RGB
> We will give this a go, but it will take a while to regenerate.
>
> Are you aware of any such limitations with the formats for cliptextures?
> The ones we are currently using are:
> int_format PFTEX_RGB5_A1
> ext_format PFTEX_UNSIGNED_SHORT_5_5_5_1
> img_format PFTEX_RGBA
>
> Do you think IRClipmapBugs.txt section 1.1 is relevant?
>
> Regards
> Ian
>
> PS Our cliptexture wobble is a thing of the past now that the tex coord
> offsets are in place - thanks for your input on that one!
>
> Angus Dorbie <dorbie++at++sgi.com>++at++sgi.com on 23/01/2001 04:39:13
>
> Sent by: dorbie++at++sgi.com
>
> To: ihawkes2++at++csc.com.au
> cc: info-performer++at++sgi.com
> Subject: Re: Cliptexture anomalies
>
> In the .ct file you probably want to increase the invalid border size to
> at least 16, but probably no more than 32, esp for a clipsize of only
> 512.
>
> The problems you are seeing are quite unusual, are you using an
> pfmpcliptexture or just a pfcliptexture?
>
> Does adjusting the numeffectivelevels to a smaller number affect problem
> 1?
>
> Cheers,Angus.
>
> ihawkes2++at++csc.com.au wrote:
> >
> > Hi,
> > I am seeing some strange anomalies in my 26 level cliptexture. There
are
> > two distinct effects:
> >
> > 1) Whilst flying over low-res regions of the database (where only 20
> levels
> > are present), small sections of corrupted or misplaced imagery are
> > sometimes paged into view. Often these sections of imagery are clearly
> > recognisable as bits of hi-res imagery from other parts of the
database.
> > The sections are paged in/out at a fairly constant distance in front of
> the
> > eye point. Turning gridify on (forcing a reload) does not remove
> corrupted
> > imagery. In fact, the corrupted bits overlay & obscure the coloured
grid.
> > The attached snapshot snap1 illustrates the problem. A previous email
in
> > 1999 "Re: clip texture LOD offset trouble" seems to be describing a
> similar
> > problem, and the author has suggested that this is the bug documented
in
> > /usr/share/Performer/doc/clipmap/IRClipmapBugs.txt section 1.1. I have
> > trouble understanding sections 1.1 and 1.2 of this document - can
anyone
> > give a higher level description of these bugs? Are there any
workarounds?
> >
> > 2) The second effect is "striping". Stripes pop up at various places in
> my
> > database (both hi-res & low-res areas), often (but not reliably) at
> > repeatable locations. A stripe consists of a short thin section of
> > misaligned imagery. Sometimes a stripe appears on its own, other times
as
> a
> > set of parallel stripes. When a stripe is in view, turning gridify on
> > (forcing a reload) will remove the stripe. The stripes are aligned with
> the
> > cliptexture tex coord axes. The attached snapshots snap2 and snap3
> > illustrate the problem.
> >
> > I have been unable to reproduce either problem in clipfly. Examining
the
> > levels in clipgen does not reveal any defects in the data.
> >
> > To try to fix the problems, I have tried adjusting all the .ct file
> > parameters (including an invalid border ranging from 8 to 256) to no
> avail
> > (see attached .ct file). Note that I use pre-cull callbacks to set my
> > virtual cliptexture parameters (and yes, I have set
> > PFN_CULL_SORT_CONTAINED).
> > My DTR parameters, which I have also experimented with unsuccessfully
are
> currently:
> > dtrMode = ( MEMLOAD, TEXLOAD );
> > dtrLoadTime = 1.25; # Milliseconds, per pipe
> > dtrFadeCount = 5; # Frames
> > dtrBlurMargin = 0.5;
> > dtrLoadTimeFrac = 1.0;
> >
> > I am using Irix 6.5.8f and Performer 2.4 on an Onyx2 IR.
> >
> > As an aside, does the _PFDRAW_EXERCISE_ARENA environment variable work
in
> 2.4?
> >
> > Thanks,
> > Ian Hawkes
> > CSC Australia
> >
> > (See attached file: Australia.ct)(See attached file: snap1.jpg)(See
> attached file: snap2.jpg)(See attached file: snap3.jpg)
> >
> >
> ------------------------------------------------------------------------
> > Name: Australia.ct
> > Australia.ct Type: unspecified type (application/octet-stream)
> > Encoding: base64
> >
> > Name: snap1.jpg
> > snap1.jpg Type: JPEG Image (image/jpeg)
> > Encoding: base64
> > Description: JPEG File Interchange
> >
> > Name: snap2.jpg
> > snap2.jpg Type: JPEG Image (image/jpeg)
> > Encoding: base64
> > Description: JPEG File Interchange
> >
> > Name: snap3.jpg
> > snap3.jpg Type: JPEG Image (image/jpeg)
> > Encoding: base64
> > Description: JPEG File Interchange
>
> --
> For Performer+OpenGL tutorials http://www.dorbie.com/
>
> "In the middle of difficulty lies opportunity."
> --Albert Einstein
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/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 : Wed Jan 24 2001 - 14:56:32 PST