Re: Reducing airports polygon count

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.

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.)

> 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.

> 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?

Curt.

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


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