I'm not really sure if this is a good idea. First the potential problems:
- I suspect that the creation of the taxiway layouts can get slow when the number of sides in the airport layout is really huge and there are holes. I don't know this for a fact because we let the OpenGL libraries do the heavy lifting. Because this loading is done on a second CPU, it might not be noticeable to all users.
- The pavement can have only one texture direction per polygon, so multiple polygons may be necessary.
- Certainly in WED having a few large complex polygons slows down editing -- if all else is equal, the tools work better with smaller polygons.
- The more square feet of overlap, the worse. So a small overlapping intersection is not so bad, but avoid layering a huge polygon on top of another huge polygon, which just strains the video card.
- Fewer segments are better. Consider two crossing taxiways...8 segments with overlap, but 12 by making a plus.
- But wait - the above example is misleading...if you need to change the light types so the blue taxiway lights don't cross the intersection then you'll need to add 4 more segments, so now it's 12 and 12 - a wash. (In this case, having one big polygon is probably easier to manage.)
- Try going to your layout from far away and watch the last step of loading...if it starts to take a long time to "preload" things it means your layout might be a bit complex.
- Do not expect X-Plane to become faster at loading airport layouts...the limiting factors are proportional to complexity, so if you have a killer polygon now it'll be pretty expensive later too.
So please do not try to use the split command to make X-Plane "smoother". We'll provide a rendering setting for this some day. The current value was chosen because anything smaller looks awful and you have to make it a lot bigger (read: a lot slower fps) to get an even marginal visual improvement.
No comments:
Post a Comment