I forgot to ask about converting files depending on sizes. I usually only mip files that are 1024X1042, 512X512, and 256X256. Is there a problem mipping files that are either smaller than 256X256 or have weird sizes like 1024X64?
There shouldn't be any problems, as long as textures have dimensions (even not equal in x and y) that are Powers of 2.
Umberto, can you explain to me how your sceneries are very complex, have mip maps, don't shimmer, and perform very well, while another aiport I bought from this other developer is much less complex in size, came with no mip mapping, and doesn't perform so well? I know that FSDT uses the LOD techniques to make objects disappear when you get a certain distance from them, so I am guessing that is part of the reason. But what I dont get is how this aiport I bought that is located in the south of France, is pretty small and I get only about 20 FPS around it, while I can get 40 to 50 FPS in Zurich.
Shimmering is mostly caused by lack of Mip Mapping.
Bad performances, instead, are more difficult to diagnose, it's usually a combination of several issues.
LOD has a part, of course. With SP2, FSX doesn't support LOD anymore in .BGL files so, this affects basically everybody, except us, since we are drawing most of our 3D objects in C++, not using .BGL, so LOD is not lost for us.
Apart for lack of LOD, we also manage a lot of optimizations with the Addon Manager, that are no longer possible when using the FSX BGL format. For example, we can cut objects over a certain altitude (like, for example, small ground details), and we can finely tune all loading distances with more control compared to what is allowed by the FSX BGL format.
If you combine this with the lack of LOD, it's easy to understand why we might not be able to do something as large and complex as JFK ( which also resides in an area that is very slow on its own ), without using the Addon Manager.
Bad fps in FSX also depends how much of FS9 or (even worse) FS8 commands are used, especially those related to 3D objects. There are many design techiques that pre-date even FS8, which are *still* supported in FSX, but were already obsolete in FS9, and are more and more inefficent, the more the sim relies on video card hardware acceleration. This affects mostly 3D objects made in Scasm, for example, using old design tools like Airport, and the old .API macros, that use commands that were not needed since FS8/FS9, and slow down performances considerably in FSX. They slow down fps even in FS9 but, since FS9 on a modern hardware is so fast, even slowing it down to 50%, is still usable so, nobody complains too much, even if the scenery is sloppily-made, FS9 is more forgiving.
And, there are other advanced stuff that can be used to optimize scenery, like the number of materials used, the number and the types of *shaders* used and shader constant used, the welding of texture vertex coordinates, etc. All these optimization techniques are only meaningful for FSX, and FSX is *expecting* a scenery developer will use them. Unfortunately, not many scenery developers knows about this: there were a couple of tutorials on some of the ACES's people blogs discussing this, and there was also a presentation at the 2007 DevCon in Seattle by ACES about optimizations, but not many scenery developers probably know about these issues, also becasue it would force them to design with an "FSX mind", which is not something they usually do.
Problem is, many mistakenly believe that, just taking a Gmax file and compiling it with the FSX SDK exporter would auto-magically result in a FSX native scenery that would perform at its best in FSX.
It's not like that: one should start to think about how FSX will react to that object, when is still in the design stage so, basically, it has to start from scratch with FSX in mind. And, using this methods will not have any negative effect on FS9: when dealing with those FSX-specific optimizations, the worse it can happen, is that you are working to get no benefits in FS9, but otherwise there will be no problems.
THAT'S why we start with the FSX scenery, and port *back* to FS9 when FSX is done: so we can get the best possible result in FSX, which doesn't affect FS9 anyway.
