General Question Surface base tiles obsolete in next version of Orbiter?

[vchamp]

including it in the next released Orbiter will at least require conversion to new planetary textures format (i.e. it won't be compatible with the next Orbiter version as is, due to dropped support for surface base tiles).

The files have been donated to the stock Orbiter install. And yes, they will need to be converted to a new format.

Does it mean that future Orbiter versions will use these new bases' configs with all the new objects (buildings, runways, etc.), but without surface base tiles, because the new planetary textures format will make them obsolete? Will these textures match the detail level of tiles in this addon?

 

[Ripley]

Does it mean that future Orbiter versions will use these new bases' configs with all the new objects (buildings, runways, etc.), but without surface base tiles, because the new planetary textures format will make them obsolete? Will these textures match the detail level of tiles in this addon?

This is what martins said about this add-on:
http://www.orbiter-forum.com/showthread.php?p=394313&postcount=18

...And here what he said about the highres surface tiles:
http://www.orbiter-forum.com/showthread.php?p=403943&postcount=5019

 

[vchamp]

This is what martins said about this add-on:
http://www.orbiter-forum.com/showthread.php?p=394313&postcount=18

...And here what he said about the highres surface tiles:
http://www.orbiter-forum.com/showthread.php?p=403943&postcount=5019

Thanks, it sums up the current state of affairs, although doesn't answer my question. I'm especially confused by orb's statement that support for surface base tiles will be dropped in future versions. Either there won't be surface tiles anymore or I misunderstood it.

 

[csanders]

Thanks, it sums up the current state of affairs, although doesn't answer my question. I'm especially confused by orb's statement that support for surface base tiles will be dropped in future versions. Either there won't be surface tiles anymore or I misunderstood it.

Surface tiles will no longer be individual .dds files in the \Textures and \Textures2 directory, but will be in a single planetary .tex file, if my understanding is correct.

 

[4throck]

Surface tiles will no longer be individual .dds files...

Yes, that's my understanding. I haven't studied the new system yet. But let's not discuss it on this thread. This is an add-on for the current Orbiter version, nothing more.

 

[martins]

Surface tiles will no longer be individual .dds files in the \Textures and \Textures2 directory, but will be in a single planetary .tex file, if my understanding is correct.

Just to clarify this a bit:

1. I am currently working on a new planet render engine, which, among other changes, will support texture resolutions higher than the level 14 supported by the current engine. The motivation is that this will make the current base tile mechanism unnecessary, which I always regarded as something of a hack.
2. The old engine will continue to be supported. Planets can pick the new engine on an individual basis.
3. Planets that use the old engine will still support the base tile mechanism.
4. The new engine will probably not support base tiles. I haven't really decided that yet. In any case, use of base tiles is discouraged for the new engine.
5. The texture patches for the new engine will no longer be accumulated in big .tex files. Instead, the individual .dds files will be stored in a directory hierarchy. So in the best-case scenario, converting from base tiles to the new engine will simply consist of copying the base tile textures into the correct location of the planet's texture directory.

 

[Kendo]

Martins, this sounds amazing. Do you still need to use the DDS format or are there better ones available to help you reach your goal.
I just hope I,m still around to see this.

 

[Loru]

Martins, this sounds amazing. Do you still need to use the DDS format or are there better ones available to help you reach your goal.
I just hope I,m still around to see this.

Why would you need other format? dds is nativelly used by directX. AFAIK tex files were just collection of dds files merged into one bigger.

 

[orb]

Do you still need to use the DDS format or are there better ones available to help you reach your goal.

There is currently no better than S3TC/DXT texture compression format supported by nowadays graphics cards (ATI has 3Dc/BC5, but it would be only usable for AMD cards), which is used by those DDS files. Other formats just would need to be re-compressed to DXT on the fly, decreasing performance, or otherwise you'd need to get a graphics card with some 16 GB VRAM.

 

[BruceJohnJennerLawso]

Just to clarify this a bit:

1. I am currently working on a new planet render engine, which, among other changes, will support texture resolutions higher than the level 14 supported by the current engine. The motivation is that this will make the current base tile mechanism unnecessary, which I always regarded as something of a hack.
2. The old engine will continue to be supported. Planets can pick the new engine on an individual basis.
3. Planets that use the old engine will still support the base tile mechanism.
4. The new engine will probably not support base tiles. I haven't really decided that yet. In any case, use of base tiles is discouraged for the new engine.
5. The texture patches for the new engine will no longer be accumulated in big .tex files. Instead, the individual .dds files will be stored in a directory hierarchy. So in the best-case scenario, converting from base tiles to the new engine will simply consist of copying the base tile textures into the correct location of the planet's texture directory.

Forgive me for being rather ignorant in such matters, but wont scaling the entire texture map for a planet upwards really slow the program down? And just how big is it going to make the download of Orbiter?

 

[orb]

Forgive me for being rather ignorant in such matters, but wont scaling the entire texture map for a planet upwards really slow the program down?

I'm not sure I understand your question. What texture map would be scaled up, and where is it mentioned in the martins' post? :shrug:

 

[Loru]

Forgive me for being rather ignorant in such matters, but wont scaling the entire texture map for a planet upwards really slow the program down? And just how big is it going to make the download of Orbiter?

No - instead of multiple .dds files packed into one .tex file for planet you'll have something like global surface tiles. Amount of data will be comparable but instead of overlaying surface tiles on global map for bases (like in Orb2010 and below) you'll edit bits of actual global map splitted into tiles.

Or in other words entire earth will be covered with surface tiles, howver arranged slightly different than today.

 

[BruceJohnJennerLawso]

I'm not sure I understand your question. What texture map would be scaled up, and where is it mentioned in the martins' post? :shrug:

The planetary textures, in TEX format are getting bigger from what I understand. Will that not cause at least a solid-sized drop in performance on most computers, given that the processing demands of high res textures cant just be contained to small areas of a planets surface like KSC?

 

[orb]

The planetary textures, in TEX format are getting bigger from what I understand. Will that not cause at least a solid-sized drop in performance on most computers, given that the processing demands of high res textures cant just be contained to small areas of a planets surface like KSC?

In new planetary textures format, only 5 textures will need to be preloaded for each planet using them and only for levels 1-4. Other higher level textures can be loaded on demand only when they should be used.

Currently the base .tex file needs to be loaded whole, up to level 8 (500-something textures inside) to use higher resolution textures.

 

[BruceJohnJennerLawso]

In new planetary textures format, only 5 textures will need to be preloaded for each planet using them and only for levels 1-4. Other higher level textures can be loaded on demand only when they should be used.

Currently the base .tex file needs to be loaded whole, up to level 8 (500-something textures inside) to use higher resolution planetary textures.

So the methods by which textures will be loaded are more efficient. Thankyou for the explanation, I just wanted to clarify a little.

If I could be so bold, just how high can the new resolutions go to?

 

[Loru]

Reposting martins' post here

...
For the moment, I am planning to cap the planet texture resolution at level 18. This would correspond to level 19 in Orbiter 2010 (since the texture patch size has increased from 256x256 to 512x512). The Orlando International textures shown in the image are at level 15, so there is plenty of room for improvement for anybody interested in upgrading it.

The images are mainly meant to show that the current mechanism of defining highres surface tiles associated with bases will no longer be required, because the quadtree planet render engine will support sufficiently high resolutions natively.

hope it will answer your questions