Does FS need the built-in mipmap system?

[JimmiG 244]

Hi. Considering "blurries" is one of the most common problem with FS, I was thinking about what to do about them.I'm mostly refering to the "dynamic" blurries, where the terrain engine can't keep up, causing 2m, 5m or even 10m tiles to appear in place of the 1.2m tiles close up.FSX includes many miplevels built into its textures, and dynamically loads and unloads textures "on the fly". So that while 1024x124 textures are displayed up close, the engine gradually switches to 512x512, 256x256, 128x128 etc farther out toward the horizon. As only textures very close to the viewer had to be stored in their highest resolution, videoram usage was significantly reduced with no visual impact (provided the terrain engine could keep up and unload/load texutres in a timely manner). This system was invented to reduce video ram usage, back when videocards had about as much built-in RAM as your average cellphone does today.So, I decided to do some calculations, which I hope someone more knowledgable can verify.Here are my assumptions:1. Terrain texture tiles are 3072KB uncompressed (1024x1024 and 24 bits per pixel)2. FSX has 93 unique landclass tiles total3. Assuming uncompressed textures, and all 93 tiles visible in a single scene (extremely unlikely), the textures would use 279MB of video RAM. This is clearly unacceptable, as many still use 256MB videocards. There would be AGP/PCI-e swapping and no room left for aicraft and autogen textures. So, at this point, built-in mipmaps make sense4. First, let's consider how many texture tiles are displayed in a single scene. Those 93 tiles are supposed to cover everything from desert to pine forest, farmland to highrise. I'd say you often only see a dozen or so textures at once, but let's assume 32 textures for a typical "complex" scene. That would be 96 MB of scenery texture data, leaving 160MB for everything else (aircraft, clouds, autogen) w/a 256MB card. Still a little bit much, as VC's can use a lot of textures these days.5. Now, let's apply DXTC texture compression (which I believe FSX already uses). It offers between 4:1 and 8:1 compression ratio. Let's again assume "worst case" and 4:1 compression. That's 24MB for 32 tiles. That's "nothing" in the age of 256/512MB videocards.This would save FSX from having to constantly load and unload textures of various miplevels. I noticed with FSX, that the radius of 1024 and 512 textres is very small. This means that just as FS has finished loading and composing the 512 set, it almost instantly has to begin loading 1024 textures, while new 256 textures are constantly shifted into the 512 "lod circle" as well. It's kind of disturbing that farther from the plane, where the tiles are tiny, there's plenty of time for the sim to swap textures, as the miplevels are much farther apart, but closer to the viewer where much larger tiles are used, FSX also has far less time to switch between tiles because the invisible lines dividing the miplevels are so much closer together.In my view, I think we have reached a point where it would be much more efficent to simply scrap the miplevels. This would significantly reduce I/O, and make pre-caching easier to manage and implement, since you wouldn't have to guess which miplevel would be needed next. Use 1024 textures and let the videocard do the mipmapping. That's why 3d cards were invented in the first place, to move things like calculating mipmaps off the main CPU and RAM and onto a dediecated chip with its own RAM.

[Guest cbuchner1]

Wouldn't the availability of only 1024x1024 pixel textures lead to an overload of memory bandwidth on the graphics card during rendering? Or would the DirectX driver take care of generating the required mip levels all by itself - if so: how efficient is it to downscale a 1024x1024 texture to a lower mip level at run time vs. simply loading it from disk?

[LuisFelizTirado 33]

Hello Jimmi,I am probably mistaken, but if you are referring to the ground textures in FS X, then they can be found in the SceneryWorldTexture folder.At my count, there are not 93 unique land class tiles - those are only the land class values. Each land class (NOT "landclass") value can display a different ground texture in each of the different regions, all 26 of them.Fortunately, there are not yet that many distinct ground textures, and often the same texture is displayed no matter the region. So, let us say that so far it is 93 land class values per region, although many will never appear in certain regions.So, each land class value displays a ground texture. Then, each ground texture can have distinct variants, to break up the monotony and avoid a repetitious effect. There can be between 3 to 15 (?) variants for each ground texture.So, you can now multiply 93 by about an average of 10 different variants, and then see how much memory is occupied.Of course, there are also seasonal and night variants, but that does not come into your calculation.If you take a look at the folder, you will find about 7800 distinct textures, about 4.5 GB compressed.And that is not even taking into account all the other textures in the game, such as aircraft (user and AI), clouds, autogen and library objects, vehicles (land, airport, and sea), environment maps, and all the specular and bump maps for all of that.Perhaps this is the reason for the MIPMaps. Although I am no expert.Best regards.Luis

[virtualstuff 758]

It's real simple yes they do I'm not going technical but without your hardware can't run all the stuff drawn on your screen...As for blurries I don't have them beside the normal behavior ;-)Cheers,Andr

[scott967 62]

There is another issue, which I'm not sure how it affects the mipmap issue, and that is that the texture is square, but the area to be covered is defined by a lat/long extent. Since longitude converges towards the poles, the texture must be stretched/compressed accordingly. Also, mesh slope changes will force stretching of the texture to fit.scott s..