Re: Reducing airports polygon count

Curtis L. Olson wrote:

> Dale E. Edmons wrote:
>
>> How does this compare to how it is currently being done?  I have to 
>> admit I don't fully understand how things work now.
>
>
>
> FlightGear runways are composed of smaller quads, that hold texture 
> pieces to assemble the entire runway.  We carefully divided up the 
> markings so that we can assemble just about any configuration.  For 
> instance each digit has a separate texture so we can construct a 
> runway with any heading, etc.  This means we need to divide the runway 
> up into a number of smaller chunks, but it's not completely insane.  
> What is probably getting you is the complex taxiway layouts ... those 
> end up generating a lot of polygons.
>
I don't consider it insane at all, more like terribly inconvienent due 
to the horrible things I'm trying to make it do--display approx 200 
polygons per display per frame!  I've actually found a way to exceed 
that limit for the general terrain.  I'll be better able to judge once I 
get my Terragear version debugged.  I'm judging based on FGSD output 
right now.  Though very similar, they aren't exactly the same.

> What Erik suggests would be an approach for a machine that is good at 
> handling a lot of large textures, and less good at handling a lot of 
> polygons.  You could draw the complex airport layout into a texture 
> (or set of textures) and then draw those textures using only a very 
> few polygons.
>
>> I've already substantially reduced the surrounding terrrain.  If I 
>> understand correctly, the airport is built independently and the 
>> surrounding terrain clipped and adjusted to match the airport.  Also, 
>> if I understand Curt's description, the airport polygons are build to 
>> match the textures and this caused the high polygon count.  If the 
>> repeating textures were duplicated and placed into new longer 
>> mid-textures the polygon count could be reduced to match the terrain 
>> instead of the texture.
>
>
>
> I don't think we are going overly crazy with polygon count for 
> runways.  But, you could use a generic runway texture (with incorrect 
> numbers?) and do the entire runway in 2 triangles (ignoring cases 
> where runways intersect and need to be split up.)

Two would be nearly equivalent to  modeling the  runway flat.  I'm just 
trying to avoid what we'll actually end up doing.  Use the TerraGear 
version as a rough-in and re-model each airport by hand.   The RAS 
system coming up is going to tax us and the equipment to the very limit 
(hopefully not beyong) of what is required in terms of accurately 
modeled airports.  RAS, as I understand it, is to be tied into the 
EGPWS.  The  EGPWS gives terrain elevation map on the radar display.  
The RAS will be kind of like one of the city street maps tied to a GPS 
in a car.  RAS will be for airports and taxiways.

>
>> This might also help others who are having problems with frame rate.  
>> Airports are currently very dense in terms of polygon count, and 
>> somewhat flat.  Reducing the polygon and texture count would bound to 
>> improve FGFS's framerate too.  As long as result matches the curve of 
>> the actual airports I'd say this is a good approach.  This might 
>> yield significant frame-rate increases, especially at airports such 
>> as KDEN, KLAX, KORD, and others with multiple runways.
>
>
> I think that to make a change, we'd have to sacrifice some quality.  
> If we could come up with a better way to go without sacrificing 
> quality or detail, I'd be interested in considering it.
>
That's why I'm using FlightGear.  Quality is the important part!  Once I 
understand the code better and finish debugging my current stuff, I'll 
take a serious look at this.  Especially if a user selectable parameter 
could be added to affect the desired end count similar to what can be 
done for the terrain, that would be a very good solution.

>> I don't know if projecting the airport onto the terrain is a valid 
>> approach.  Airports often represent a unique area modified to 
>> accomodate landings.   For example, at KSEA they have been hauling 
>> dirt for about two years to build a third runway.  The airport is on 
>> top of a hill, so to speak, and a simple projection would warp it 
>> terribly and not have the sudden drop at the ends.  Landings would be 
>> more like controlled crashes.
>
>
>
> I don't think Erik was talking about just dropping a big airport 
> picture on over the terrain.  I think he meant drawing the complex 
> geometry and polygons into a single *big* texture (or a few *big* 
> textures) depending on the pixel/m size you need, and then drawing 
> those textures on top of a few very simple polygons.  You should be 
> able to be careful to keep the underlying airport surface similar to 
> what it is now ... although the closer you match the current surface, 
> the more polygons you need. :-)
>
> It's a tough task.  Is there a reason you couldn't just use FG running 
> on a standard PC instead of your existing IG hardware?
>
1) Certification.  I believe that FGFS as been through certification on 
"Training Equipment" or maybe even for FTD's, but I don't think its been 
certified for a Level C/D Full Flight simulator--even a grandfathered 
one.  On my system at home I notice that FGFS display will stop at 
certain intervals and continue on.  Granted its only momentary (maybe 
1/4 sec or less) but noticable.  When we put an O-scope on the signal 
and do the step response tests as required by the FAA, I reasonably 
expect FGFS would fail--if only intermittantly.
2) Hooking a PC to a caligraphic projector is non-trivial.  Converting 
the projection system to a raster only display is non-trivial.  There 
are some vendors doing exactly that and we're looking into equivalent 
FAA certified systems, but that brings up item 3).
3) Cost.  If we can purchase an equivalent system with new IG then I'll 
still be doing the same thing except that polygon count will no longer 
be a major problem.  But, cost-cutting has become an absolute imparative 
in the Airline industry in its current form.  Even then we're only 
looking at replacing one of the two systems--unless things change.  If 
management gives us the funds I'll be very happy indeed.


Dale

I've run out of time for the momement.....

> Curt.
>


_______________________________________________
Terragear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/terragear-devel
2f585eeea02e2c79d7b1d8c4963bae2d