Orbiter Surface Texture Question

[DarkEnergy]

I'm not sure exactly how Orbiter renders texture for planets, but it seems like it renders just one huge texture for each planet. While this looks good from a couple hundred kilometers away, the texture looks stretched and the resolution seems to be a kilometer or more on the ground.

Microsoft Flight Simulator and even regular games use small tiles of textures that are loaded as the player gets closer to them. Why doesn't Orbiter take a similar approach? The textures would look much better on the ground. I understand that this will soon become a massive amount of tiles that need to be rendered as the player gets higher. But with height, the textures could become progressively bigger until, once in space, the single texture tile is used.

I'm not positive if Orbiter renders the entire texture, including the parts that aren't visible, but if it does wouldn't this method be much more efficient and save processing power?

I'm sure there is probably a good reason this has not been done yet. I've just been wondering after playing FSX lately. Any thoughts?

 

[orb]

Not exactly. Only level 1-8 textures are rendered as a texture for whole planet. These are .tex files. They are composed from 256x256 px tiles (except level 1-2), that's a span of 360 degrees for level 1-3 and 11.25 degrees for level 8 tile near planet's equator. So, starting from level 1, each following level is rendered with planet taking more space in your field of view. If your field of view of that 11.25 degree part of planet contains more pixels on your monitor, then level 9 textures are used if they are present. They are located in _tile.tex files, and are used as local textures, but can be also created for whole planet. Again if your field of view of planet is 2 times narrower (5.625 degrees for 256 pixels on equator), level 10 of textures for this part of planet is used, if it's also present in file, and that's all for the .tex files for Orbiter 2006 (for Orbiter 2009 this is as mush as up to level 14).

Then if you have surface bases, they may use their own detailed surface tiles, that are placed over less detailed textures mentioned earlier. They are loaded when you are near base using them. There are also few levels of textures, but surface tile size in pixels doesn't need to be 256x256 like with global textures, because those tiles are taken from separate .dds files, but may be even 8192x8192 if your graphics card supports that texture size. Cape Canaveral for example uses levels 2, 3 and 4 of surface tiles, but you can use also higher levels if you have enough detailed textures.

Level 1-8 planet textures take 16 MB of space. Now, level 9-10 for global coverage takes 230 MB, and level 9-11 as much as 960 MB. And that's only for 3 levels starting from level 9 of global planet textures. Global coverage level 14 planet textures would take over 64 GB of space for whole one planet or moon, and there is usually more than one planet in a system, and some may also have more than 10 moons.

Now, how much detailed textures would you like to have, how long would you like to spend on downloading them, and how much RAM, VRAM and HDD would you like to dedicate for them?

Of course I was talking here only about real textures. Details can be also achieved by using false detail maps, like in Orulex.

 

[fort]

I never succeeded creating local surftiles in Orbiter, and accepted by Orbiter, of a superior format to 2048x2048 (the format of the surftile; not the one of the initial picture used fot it). I did a research rather long on internet to understand why.The result is that it seems possible with Flight Simulator, according to what I read and under certain conditions, to use a format such 4096x4096. Beyond, probably not and this would be a due limitation to DirectX.

 

[orb]

I never succeeded creating local surftiles in Orbiter, and accepted by Orbiter, of a superior format to 2048x2048 (the format of the surftile; not the one of the initial picture used fot it). I did a research rather long on internet to understand why.The result is that it seems possible with Flight Simulator, according to what I read and under certain conditions, to use a format such 4096x4096. Beyond, probably not and this would be a due limitation to DirectX.

2048x2048 is not a limit for texture size in Orbiter. I successfully used 4096x4096 textures in it, but there aren't released add-ons, because add-on developers avoid that, to keep compatibility with older graphics cards.

It's only in graphics card's capabilities what defines maximum size of textures (i.e. MaxTextureWidth, MaxTextureHeight in D3DCAPS).

 

[fort]

I do not remember where I found these information. I attempted several times to do textures, . dds, of 4096x4096px with DxtBmp, without success.I, later, found other tools that well worked for this dimension. But while launching the texture in Orbiter, the tile did not appear (white rectangle in the occurence). I will try again, but my graphic card is far from being recent.

Are the graphic cards working with DirectX 9 (?) capable to go beyond 4096x4096 for . dds ? Is this strictly a question of graphic card ? And if my memory is good, Orbiter is built on the DirectX 7 engine ?

There is some confusion in my mind about all that things.

 

[orb]

I do not remember where I found these information. I attempted several times to do textures, . dds, of 4096x4096px with DxtBmp, without success.I, later, found other tools that well worked for this dimension. But while launching the texture in Orbiter, the tile did not appear (white rectangle in the occurence). I will try again, but my graphic card is far from being recent.

Well, I didn't use DxtBmp tool, so I don't know for sure, but it may be problem with this tool. I use DxTex form DirectX 9 SDK, and it can create textures up to 4096 in width or height, and those textures work fine in Orbiter. If I had DirectX 10 and DirectX 10 SDK I'd try with 8192 px textures, because my card supports them.

Are the graphic cards working with DirectX 9 (?) capable to go beyond 4096x4096 for . dds ? Is this strictly a question of graphic card ? And if my memory is good, Orbiter is built on the DirectX 7 engine ?

There is some confusion in my mind about all that things.

DirectX 9 card isn't capable to go beyond 4096x4096 textures. DirectX 10 card is capable, but needs DirectX 10 to use 8192x8192 textures.

Orbiter is built for DirectX 7, but I think it works on some compatibility layer from DirectX 9 (or DirectX 10/11), so 4096 px textures are allowed. I may try with 8192 px textures when I switch to Vista and DirectX 10, but I like much more to work on XP, so it won't happen very soon (and Vista lays in the box, since I bought it with my current graphics card 2 years ago).

 

[DarkEnergy]

Level 1-8 planet textures take 16 MB of space. Now, level 9-10 for global coverage takes 230 MB, and level 9-11 as much as 960 MB. And that's only for 3 levels starting from level 9 of global planet textures. Global coverage level 14 planet textures would take over 64 GB of space for whole one planet or moon, and there is usually more than one planet in a system, and some may also have more than 10 moons.

Now, how much detailed textures would you like to have, how long would you like to spend on downloading them, and how much RAM, VRAM and HDD would you like to dedicate for them?

Well, of course enormous amounts of textures with high resolutions takes up a huge amount of space, as you said. But FSX uses a certain collection of texture tiles and renders them in the appropriate locations (sand in deserts, streets in towns, i.e.). This allows only a couple high resolution tiles and use them across the world to save space. Different terrain is simulated in a similar method to Orulex. Also, about 70% of the world is water, so actually you only need to cover 30% of the world with these tiles.

So, returning to the original point, is it possible for Orbiter to use a similar method for textures through an add on? Once in space, the single large and unique tiles could be used again to prevent that "tiled" look of the smaller tiles. I am not requesting an add on and I am quite content with it as it is, but I am wondering about why an approach like this has not been used (HDD space should not be a problem if the tiles are not all "unique").

 

[fort]

Thank you orb for these explanations.

I will keep all this.

Good day.