General Category > General Discussion

Question for developers or texture gurus

(1/2) > >>

cmpbllsjc:
I have noticed that in better airports like the ones made by FSDT and FlyTampa they use .dds files for textures rather than BMP files. I have an airport from another developer that I bought a few weeks ago, who shall remain nameless, but I am less than impressed by the appearance and performance of the said airport. It has no mipmapping and shimmers like crazy, not to mention that fact that this airport isn't even that complex like Zurich, Geneva, Ft Lauderdale, and Las Vegas are, and I only get about 20 FPS in addition to the shimmers.

I am guessing that perhaps using BMP's instead of .dds for textures may be part of the problem, as well as lack of mip mapping.

What I would like to know is what is the advantage, if any, to using .dds format for textures, and if it better why aren't more developers using that format.

One other question while I am at it. In my quest to fix the said airport, I have been adding the mip maps myself while the developer is trying to get an update out to fix the shimmers. A fellow on the devlopers forum where I bought this aiport said that in addition to adding the mips it would be wise to convert the textures from DXT3 to DXT1. Before I take the time to do so, what is going to be the difference in performance and look of the textures if I do convert them to DXT1?

Thanks in advance to anyone who may know the answers to these questions. I would have asked on the forum where I bought the product I am trying to fix, but it isn't as user friendly as the guys here are.

Regards.

virtuali:
Lack of Mip Mapping is the main cause of shimmering, and it might also cause fps loss, because always the highest resolution version of the texture will be shown, regardless of the distance.

It shouldn't make big difference using .dds or .bmp, because what really matters is the format textures are, like DXT1 or DXT3. If would matter, instead, if the .bmp were in the BMP format, which is inefficent. Note the possible source of confusion: .DDS and .BMP are used as containers here so, a .DDS can contain a DXT1/3/5 texture, and a .BMP file can also contain the same formats. But, a .BMP container might also contain a *real* .BMP, so it's easy to make mistakes...

You shouldn't blindly convert *everything* in DXT1. The rule is:

- If a texture doesn't have or need an Alpha channel, convert it to DXT1, and check no Alpha channel is included

- If a texture need a straight 1 bit ( pure black and pure white only ) Alpha channel, convert it in DXT1 as well

- If a texture needs partial transparency, so the Alpha has multiple levels of grey, it HAS to be DXT3.

- If a texture, on top of having partial transparency, it also features a smooth color gradient, it's best to use DXT5 (FSX only )

cmpbllsjc:
Thanks Umberto for the great explanation. I didn't expect a reply from anyone so quickly.

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?

I always make backups before I fiddle with anything, but it's good to know the rules first before I waste time fiddling with things I am not so certain about. I will mark this post or copy it to a note pad for future refernece before I proceed with any more conversions of scenery textures.

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.

Thanks

virtuali:

--- Quote from: cmpbllsjc on September 22, 2009, 11:00:21 am ---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?
--- End quote ---

There shouldn't be any problems, as long as textures have dimensions (even not equal in x and y) that are Powers of 2.


--- Quote ---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.
--- End quote ---

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.

JFKpilot:

--- Quote from: cmpbllsjc on September 22, 2009, 11:00:21 am ---I forgot to ask about converting files depending on 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.
--- End quote ---


It's too bad you still have shimmering trouble with Aerosoft's Nice. I seriously don't understand why a "fsx-only" airport would have bmp textures without mipmaps, this is completely wrong. As far as converting the textures goes -- I think Aerosoft should solve this but, since you seem to be converting them yourself, what tool(s) are you using? I hope you are not doing it one-by-one, with DXTbmp. You can just make a batch file and use imagetool instead, it only takes a few minutes. As Umberto said, the way to go is DXT5 with mips.
Still, it'll never be as optimized as Fsdt sceneries. Umberto more than covered that with his great explanation.  ;) 

Navigation

[0] Message Index

[#] Next page