David Luff wrote:

I keep meaning to reply to some of your (and Chris M's) posts about taxiways, but since they always seem to require a carefully considered reply I never seem to find the time. I'll try to finish and post this one. I very much belong to the 'keep putting one foot in front of the other' school of thought - TaxiDraw current aims to solve the immediate problem of being able to edit the data format that we have at the moment. Now that it is largely functionally complete for this, I'm also keen to turn towards the problem of how to represent the taxiways better in the sim.


Hi Dave,

I hope you know how much your efforts are appreciated. As we move forward, it will be wonderful to have more and more FG users be able to submit airport upgrades to the FG/X-Plane airport data base.

Now that it is largely functionally complete for this, I'm also keen to turn 
towards the problem of how to represent the taxiways better in the sim.


I can think of 4 approaches to defining taxiways and lines.

1. Follow the same basic approach that we used for runway markings ... come up with a clever way to design a minimal set of textures that can be assembled into all the possible taxiway layout and marking schemes. As you suggest, this is almost an impossible task given the variety of marking schemes and intersections and such that exist ... plus taxi lines can run out into the runway which makes it even more problematic. We'd have to settle for some severe compromises if we went this direction.

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. We could put a small amount of alpha on the edge of the lines to blend them in nicely with the underlying surface textures. This also has the advantage that the lines exist separately from the taxiway and runway textures eliminating the texture usage and combinatorial problems of #1. But this scheme would burn a lot of polygons and it would require some complex preprocessing of the line polygons to clip them against all the underlying triangles. That would be no small task ... (writing the code to do that.)

3. Cut the lines right into the geometry ... i.e. cut holes for the lines. This would probably be the easiest programatically because the code to do this priority clipping already exists. We would just lay the lines down first and they would own their areas ... the runway/taxiway surface polygons would fill in around the lines. This eliminates the need for doing glPolygonOffset (which isn't exactly platform independent and can have parameter "tuning" difficulties.) But we couldn't use the alpha edge trick of #2 any more, and we'd still be burning a fairly high number of polygons.

4. This last one intrigues me, but I don't think we have the hardware or computer power to do it today. We could draw the entire airport in 2D into a really large texture (or a couple large textures) and then create a fairly simple polygon mesh coverting the airport area. The large textures would be overlayed on the simple underlying mesh ... all the runways textures, lines, taxiways, etc. would be "burned" into this larger texture. The large texture could be created at run time based off of a set of simple base textures. We could really do any number of arbitrary layering and shapes and surface types all burned into the large airport texture. This sort of approach probably wouldn't work so well until video cards with a 1/2 or whole Gb of video ram are common place ... but it's an idea that really intrigues me.

Heading off on a tangent ...

MSFS does something sort of similar for the base terrain which allows them to do nice blending between land use types, but there are limitations to pulling off this technique on current consumer hardware ... it's intriguing though ... sort of like doing photo/satellite based scenery, but generating the textures yourself on the fly ... you could burn in roads, buildings, trees, and other objects, then match the burned in objects with precisely positioned autogen objects ... it would allow you to distribute scenery in more of a base/component/layered form and then render at runtime in various LODs.... intriguing, but I'm not sure that most people would be happy with the performance.

Just a quick back of the envelope calculation for instance ... if we want 4 meter/pixel resolution (which isn't great) and we want to cover just a single tile, the memory requirements really balloon quickly. Let's say a tile is 8 miles x 8 miles. That's about 13x13 km or 13000x13000 meters. At 4m/px res, we would need a texture of 3072x3072 to cover that area (thats 3*1024 which is not quite 4m/px but is a nice 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.

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. None of these are perfect in terms of rendering output. #1 would probably be the hardest to impliment from both the taxidraw and genapts perspective. #2 would probably look the best if it could be done correctly. #3 would be the easiest from a genapts perspective and would probably look ok with a lot of FSAA turned on. #4 is probably better left for next year or the year after. :-)

Regards,

Curt.

--
Curtis Olson        http://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:        2f585eeea02e2c79d7b1d8c4963bae2d


_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to