On 12/16/04 at 12:16 PM Curtis L. Olson wrote:
>David Luff wrote: > >>I've commited a work-around to the base that wraps all the symetrical >>runway panels in the v direction (everything except the threshold panel >has >>identical upper and lower borders, and so can safetly be wrapped in v >given >>that we're only wrapping a handfull of pixels). This removes the vast >>majority of the lines (all except at the threshold, and the longitudional >>line where rwy numbers are made of 2 digits). You can still test Andy's >>plib patch by using the 2D c172 (--aircraft=c172p-2dpanel) which will >>almost certainly exhibit panel jointing problems if you've been seeing >>runway lines. >> >> > >Dave, > >Based on all my knowledge of OpenGL, this is the wrong thing to do and >will introduce additional (although possibly less visible) artifacts at >the edges. The visual results should be examined *very* carefully. I >don't think this is what we want to do. > Hi Curt, I had a feeling I'd cop some flak for this ;-) I'm quite prepared to be proved wrong and to revert it if need be. Lets look at the benefits first though and give it a couple of days to see if there really are some downsides. Here's some screenshots to look at - 2 before the change, and 2 after. KDPA screenshots from my Cygwin build, KSFO from the official binary, both with an ATI Radeon 7200 32Meg card. http://www.nottingham.ac.uk/~eazdluf/KSFO-default.jpg http://www.nottingham.ac.uk/~eazdluf/KSFO-new.jpg http://www.nottingham.ac.uk/~eazdluf/KDPA-default.jpg http://www.nottingham.ac.uk/~eazdluf/KDPA-new.jpg Without any change thousand of users who download the official binary and use (an unknown but significant subset of) non-NVidia cards are going to be seeing those lines in the runway. They don't look good :-( Explanation of the ATI vs. NVidia differences is given by Andy Ross, a full two years ago: http://mail.flightgear.org/pipermail/flightgear-devel/2002-December/014095.h tml http://sourceforge.net/mailarchive/forum.php?forum_id=4479&max_rows=25&style =nested&viewmonth=200212 His patch never got included in Plib though (looking at the current source), and even if it did I don't have the knowhow to get OpenGL-1.2 stuff working under Windows. I can think of 3 possible avenues for fixing this: 1 - Look at the airport generator. Perhaps we've got tiny over or underruns on the tex co-ords. Maybe lining them up perfectly or even with slight overlap would fix it. Disadvantage - need to regenerate scenery to see benefits - not practical for this release. 2 - Fred compiles Plib with Andy's patch and gets the official binary to use GL_CLAMP_TO_EDGE if available. Apparently most modern cards should handle this. Disadvantage - AFAICT using 1.2 extensions on Windows is possibly somewhat non-trivial - win32api supplies openGL 1.1 by default if I'm not mistaken. 3 - My, erm, hack. I can't theoretically see where it's going to cause artifacts. AFAICT, I'm just wrapping in one direction where the bottom and top pixels of the texture are practically the same anyway. That's why I can't do the threshold piece. I'm quite prepared to be proved wrong though - I thought I'd better do this with enough time before the release to back it out if need be ;-) We could almost certainly wrap all the full width pieces in u and v if it's the 1D wrapping you're concerned about, since the left and right are identical, as long as we don't overrun the small runway shoulder. Can't do the 9r, 7l etc bits in that direction though. I guess I'd better go and see what it looks like on an NVidea card now... Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
