On Monday, 29 November 2004 04:34, Curtis L. Olson wrote: > 2. Draw the taxi lines as separate polygons over the top of the taxiways > and runways. We would need to use glPolygonOffset, and make sure we > split all the taxiway lines at the borders of all the underlying surface > triangles so that the taxilines always lay in the perfect plane of the > underlying surface triangles.
Number 2 is the route I was planning to take. There would be no need for an unlimited set of textures and we could add the black tire marks too, not just the taxiway lines. Clipping the lines against the underlying polygons is a bit tricky but not that hard. I was just going to float the polygons on top of each other with a *very* small offset so that there would be no z fighting and yet no visible floating. I'm not too sure how well this would work as I haven't reached that stage yet. > round number.) That's 28Mb worth of texture, and if you do mipmapping, > that's more like 56Mb of texture ... just for one tile and not a very > high resolution. What do you do if you are near the corner and need 4 > tiles at high resolution ... either you need to break this down into > much smaller tiles so that you have only a few small areas at the > highest res, or you need a ton of video ram, because you still need all > the other textures loaded along with these per tile textures. And it > would be nice to be able to do 1 or 2m per pixel which is just that much > more video ram. That's why MS use DXT texture compression. The DXT (S3TC) texture compression formats use a form of lossy vector quantization to compress texture images by a ratio of 4:1 or 6:1. These formats are a standard part of Direct3D, and are available in OpenGL via the ARB_texture_compression and GL_EXT_texture_compression_s3tc extensions. Texture compression works very well for color maps. The textures are stored in compressed format which makes loading a lot quicker and saves lots of IO when being transferred to the video card. Without texture compression technology FS2004's scenery would not be possible. > Anyway, sorry for the tangent ... > > From a wysiwyg editor stand point, #2 or #3 would probably be the > easiest, and probably equivalent from the editing side. You define > taxiway lines independent of the taxiway surface and you don't have to > worry about combining basic textures with line primatives embedded in > them. Actually I would only define the taxiway lines seperately for non-standard stuff. The taxiway lines would normally be drawn automatically based on the properties of the taxiway segments. > #4 is probably better > left for next year or the year after. :-) Number 4 would not be hard to implement later on. I'm using OpenGL so it would just be a matter of rendering to a texture and exporting the elevation data. Paul _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
