Project Planetary Textures for D3D11

[Veterok]

The D3D11 client is approaching support for normal mapped planetary textures, 3D terrain, and vegetation.

I would like to put together a big bittorrent o' visual upgrades.

To start with, I'm going to be converting Celestia textures for use with Orbiter. I'll be attributing the authors and getting their permission if I can contact them.

Besides the obvious need for planet wide normal maps, we also need diffuse textures with few or no shadows, and height maps for 3D terrain.

As a first step, I've applied my embarrassingly poor coding skills to create a tool to import Celestia virtual textures into Orbiter. I'll post it once I can get it to handle 64K bitmaps without running out of RAM.

Is there a version of pltex that takes command line arguments? That would make this much easier.

 

[dumbo2007]

Man! there is a huge and serious effort on to bring Orbiter's visual experience up to speed. Just loving it!

 

[asmi]

Just tell me what do exactly you need from pltex - and I will write a program to do just that. I've hacked this tex format inside and out, and can do almost everything with it

 

[4throck]

What do you need regarding heightmaps? A grayscale BMP ? I have imported some of those to Orulex, and there's some real data available, besides Earth, Moon and Mars.

Just out of the blue, are there any plans for "landclass" type scenery generation for trees, large / small rocks, buildings, etc? I'd be more than interested in that!

 

[Veterok]

Just tell me what do exactly you need from pltex - and I will write a program to do just that. I've hacked this tex format inside and out, and can do almost everything with it

I've got a working toolchain now. It's a bit of a Rube Goldberg solution, and it eats up a lot of disk space while it runs, but it seems to work.

I might need help with a tool for "sliding" the texture around a planet to get it to line up with orbiter's coordinates, if you know how to work directly with the .tex, _tile, and _bin format that would probably be much faster than my method. (modifying the bitmaps and feeding them back into pltex)

What do you need regarding heightmaps? A grayscale BMP ? I have imported some of those to Orulex, and there's some real data available, besides Earth, Moon and Mars.

Just out of the blue, are there any plans for "landclass" type scenery generation for trees, large / small rocks, buildings, etc? I'd be more than interested in that!

I don't know if Glider has decided on a format for height maps yet, so there's not much to be done there at the moment.

Yes, scenery generation is on the to do list (and not too far down) in the D3D11 development thread. I was thinking we should start with assets for the Moon, or Mars, as they have much simpler terrain, (rock strewn landscapes) than the Earth with all it's biomes and urban environments.

If you're interested in modeling and texturing assets, or even compiling them from other sources with permission to redistribute. Get started! I don't know what the final format will be, probably mipmaps from one or more angles, and a couple LOD models. You can ask Glider or asmi what they might have in mind.

 

[asmi]

I've got a working toolchain now. It's a bit of a Rube Goldberg solution, and it eats up a lot of disk space while it runs, but it seems to work.

I might need help with a tool for "sliding" the texture around a planet to get it to line up with orbiter's coordinates, if you know how to work directly with the .tex, _tile, and _bin format that would probably be much faster than my method. (modifying the bitmaps and feeding them back into pltex)

I have "half-done" utility that navigates through _bin file and looks up corresponding texture tiles in .tex file. Right now it doesn't actually displays them nor allows to replace individual tiles - it just became unneccessary as development progressed I was writting it mostly to learn format, so once I was able to successfully parse it, I figured that that was enough Allthough I could probably finish it in a few days of dedicated work...

I don't know if Glider has decided on a format for height maps yet, so there's not much to be done there at the moment.

Yes, scenery generation is on the to do list (and not too far down) in the D3D11 development thread. I was thinking we should start with assets for the Moon, or Mars, as they have much simpler terrain, (rock strewn landscapes) than the Earth with all it's biomes and urban environments.

If you're interested in modeling and texturing assets, or even compiling them from other sources with permission to redistribute. Get started! I don't know what the final format will be, probably mipmaps from one or more angles, and a couple LOD models. You can ask Glider or asmi what they might have in mind.

As I've said, it's Glider's show, so you should ask him. But here are my 5 cents:
Heightmap format is actually a VERY good question. We can't use ordinal greyscale bitmaps, as they have only 256 levels of intensity, which is obviously far from being enough to cover interval [-12km..+25km] (OK we could probably forget about oceans on Earth, which would raise lower limit, but still...). This could probably be remedied by coding relative heights for each tile - and if they are small enough (so relative heights will be within 255 m from reference point), but there are two other problems - first of all, vertex shader code will be a real mess to calculate all of this, and second and more important - in case of mountainous regions we'll be forced to keep in memory a lot of tiles - and since I've never heard about Martin's plans to implement 64bit client, we're effectively screwed
More viable choice would be using 32bit single-component float bitmaps (16 meaninful numbers + exponent are more than enough for our purposes), but how many graphics editors do you know which are cabable of working with such bitmaps? I know none...
So let's ask Glider what he thinks about all of this since he is actually doing that now, but as far as I understand we're about to face some serious challenges. And - this is just a pure speculation - maybe for that very reason Martin hasn't implemented heightmaps support in the client yet...

 

[4throck]

From a data availability point, we do have 8bit grayscale data for lots of bodies.

Perhaps the best approach would be to generate random terrain, extrapolating from each original data point. This is what Orulex does (if you use a bmp heigmap along with a "surface function" and it works.

As for landclass, the data exists in the form of geologic maps, such as this:

Those colors only need to translate to rock size / distribution on ground. Again, some extrapolation would need to be done, because the data resolution is low and boundary effects might be ugly (like going from rocks to no rocks). Flightsim uses this system and I'm sure there's some free data that could be used.

On my end time is very very limited, so what I can do NOW is to post links for data sources and relevant images. Can I use this thread?

 

[Glider]

Heightmap format is actually a VERY good question. We can't use ordinal greyscale bitmaps, as they have only 256 levels of intensity, which is obviously far from being enough to cover interval [-12km..+25km] (OK we could probably forget about oceans on Earth, which would raise lower limit, but still...). This could probably be remedied by coding relative heights for each tile - and if they are small enough (so relative heights will be within 255 m from reference point), but there are two other problems - first of all, vertex shader code will be a real mess to calculate all of this, and second and more important - in case of mountainous regions we'll be forced to keep in memory a lot of tiles - and since I've never heard about Martin's plans to implement 64bit client, we're effectively screwed
More viable choice would be using 32bit single-component float bitmaps (16 meaninful numbers + exponent are more than enough for our purposes), but how many graphics editors do you know which are cabable of working with such bitmaps? I know none...
So let's ask Glider what he thinks about all of this since he is actually doing that now, but as far as I understand we're about to face some serious challenges. And - this is just a pure speculation - maybe for that very reason Martin hasn't implemented heightmaps support in the client yet...

I intend to make heightmap in that way: each tile is a 33x33 PNG-compressed INT16 bitmap with possible height range from -32 km to +32 km (should be enough for any planet). all tiles will be in _height.tex file with this structure:
heightmaps for all L8 tiles, followed by L9,10,11,12,13 and higher tiles which offsets are in _height.bin file (in HEIGHTFILESPEC structs similar to TILEFILESPEC). I don't think we need any graphics editors, the most simple way to create a heightmap is to write a small program that will read .DEM (or similar format), then resize tiles, compress them with libpng and write result into _height.tex file.

If you're interested in modeling and texturing assets, or even compiling them from other sources with permission to redistribute. Get started! I don't know what the final format will be, probably mipmaps from one or more angles, and a couple LOD models. You can ask Glider or asmi what they might have in mind.

I think that it is too early to getting started with rock/tree textures or any meshes, because I didn't tested the code that will use them, so it can change. But links to data sources with heightmap, land cover or other data like that are very welcome.

Just out of the blue, are there any plans for "landclass" type scenery generation for trees, large / small rocks, buildings, etc? I'd be more than interested in that!

Not only plans, there's a code. (so far without buildings, only rocks and trees) But I didn't test it so far.

Perhaps the best approach would be to generate random terrain, extrapolating from each original data point. This is what Orulex does (if you use a bmp heigmap along with a "surface function" and it works.

That should be simple, I only need add some noise value to loaded heightmap and then create texture.

As for landclass, the data exists in the form of geologic maps, such as this:

Maps like that could be very usefull if they would be without these shadows and craters,(example: integer value that is same for any point within a region) so I could use them directly in geometry shader to create right rock density and type.

 

[4throck]

Just two comments:

Regarding 8bit heightmaps and editors: for some bodies the public that is just that: a grayscale JPG. Sometimes coverage is partial but improves over time, so a editor will be needed. I'm talking about the Saturn satellites, for example, for which we have partial altimetric maps.
16 bits are great for datasets such as LOLA, but some of those are not public.

Shaded maps: I can remove the shading ;-) and produce a indexed BMP with 4 or 8 "colors" indicating the terrain type.

Enough talk on my end, I'll start posting link to resources I think are interesting by body. I'll only cover altimetry and land cover, and leave the rest for others :thumbup:!

 

[dumbo2007]

LOLA data right here : http://imbrium.mit.edu/DATA/LOLA_GDR/

 

[4throck]

Mercury geology:

http://photojournal.jpl.nasa.gov/catalog/PIA12083

On the geologic map, the pale yellow and darker yellow areas represent different types of smooth plains. ...
The light and dark blue colors highlight areas of the surface that have a lower reflectance and different composition than the smooth plains. The black areas on this map represent other kinds of terrain. The crosshatched areas were not included in the map because the high Sun angle during the flybys made them unsuitable for interpreting surface texture.

Here he have 4 types of terrain and the missing surface area would have to be filled in using artistic licence. But the dataset is usable.

Mercury altimetry:

Some partial results from older data, as 8bit images.

http://www.psrd.hawaii.edu/Oct01/MercuryMtg.html
http://users.aber.ac.uk/atc/papers/andre2001.pdf
http://users.aber.ac.uk/atc/papers/ms016.pdf

This can be assembled into a partial mosaic, but resolution will always be limited. Yet, for some locations at least we have some real data.

 

[Veterok]

Conversions are coming along,
I've finished level 8/11 diffuse and normal maps of the moon, and a lvl 8/10 normal map of Mars.


Some data sources I've come across.

There is some mars landclass data here, rock abundance and mineral types.
http://www.mars.asu.edu/data/


Visible and topgraphic
http://visibleearth.nasa.gov/view_cat.php?categoryID=1484
http://www.mapaplanet.org/
http://www.mapaplanet.org/explorer/help/data_set.html#m123m10

 

[asmi]

Just in case you haven't seen it yet:
http://www.google.com/mars/
http://www.google.com/moon/
But there seems to be an bureacratic issue of getting Google's permission to use this data. It might actually be easier to stream tiles directly from Goggle Maps (they seem have API for that) - this actually sounds like a very good idea - at least for Earth, also possibly for Mars and Moon.
UPDATE:

It looks like Google doesn't have API for accessing map tiles, while Bing Maps do: http://msdn.microsoft.com/en-us/library/ff701716.aspx

 

[Veterok]

I took a picture from hirise, made it some what tile-able, and applied a color palette. This is scaled down, the full image is 4000 x 2000 resolution is 1m/pixel. Maybe we could do something like this with height maps to provide additional terrain detail rather than just using noise.

Also, JMars http://jmars.asu.edu/ (and JMars for Earth and Moon) Have tons of data.

Also, a glimpse of what's to come.
http://www.youtube.com/watch?v=G8uyHV3SBDA&feature=youtu.be

 

[4throck]

Asmi:

Google maps (or Bing) are a no go. That approach is against their TOS and will result in the user being banned from the service.
Also Gmaps now is a paid service (above a certain number of maps viewed, of course).

The only data that can be used comes from public data sources such as Nasa or from published papers (giving attribution in the documentation).

What CAN be done is to use the GoogleEarth API plugin as a graphic engine, acting as a online viewer only. We only need to get the camera coordinates from Orbiter into a Javascript variable for realtime viewing in a browser window... I can program the API, no problem, I just need to have the data from Orbiter

 

[asmi]

Asmi:

Google maps (or Bing) are a no go. That approach is against their TOS and will result in the user being banned from the service.
Also Gmaps now is a paid service (above a certain number of maps viewed, of course).

The only data that can be used comes from public data sources such as Nasa or from published papers (giving attribution in the documentation).

What CAN be done is to use the GoogleEarth API plugin as a graphic engine, acting as a online viewer only. We only need to get the camera coordinates from Orbiter into a Javascript variable for realtime viewing in a browser window... I can program the API, no problem, I just need to have the data from Orbiter

Hmm, I've read through this: http://www.microsoft.com/maps/product/terms.html and couldn't fins such restrictions...

 

[4throck]

For bodies other than Earth, Moon & Mars data quality is more limited.

For Venus, here's the altimetry from http://www.mapaplanet.org/:

And here's some global geological map (fig. 21)that can be used to generate landclass:
http://www.planetary.brown.edu)/pdfs/3947.pdf

---------- Post added at 14:39 ---------- Previous post was at 14:26 ----------

Hmm, I've read through this: http://www.microsoft.com/maps/product/terms.html and couldn't fins such restrictions...

Trust me, they exist. Can you find a software such as Orbiter clearly identified in the TOS ? Are we "education" ? Are we online viewing in a browser?
I'm not trying to push a point of view, I'm just warning that "they" can spin the TOS enough to give us problems, such as IP ban from their servers.
I do agree that Microsoft is less restrictive than Google though.

This road has been followed by the FlightSim guys. There's a software (http://www.edtruthan.com/tileproxy/tutorial/) that downloads terrain images as you fly, and there were problems because the images were downloaded to the client PC and because of heavy server usage. That software still exists but it requires that the user manually configures the tile server. And not all such servers accept requests from the said software.
There's a good explanation in tileproxy's manual: http://www.edtruthan.com/tileproxy/manual.htm#7
"The TileProxy project does NOT SHIP PRE-CONFIGURED to access any commercial map
service in particular as to stay clear of any liability issues and possible infringements of trade
marks."

This is a gray area and my comments are intended just as a word of caution. You can always send an email to Microsoft and ask :thumbup:

 

[Veterok]

http://visibleearth.nasa.gov/view.php?id=73934
86400 x 43200 height map of Earth, as an int16 array.

Can someone take a crack at converting it to the format Glider described?

86k is between tile levels, so you should scale it up to 128k.

It should possible to make a normal map as well yes?
:tiphat:

 

[Veterok]

Open Street Maps has a free dataset (19GB) of XML tagged vector data for roads, bodies of water, parks, runways...
http://www.openstreetmap.org/?lat=28.6118&lon=-80.6945&zoom=14&layers=O

We could stream this data (from a local install, or through the API), and use it for laying out textures.

 

[Felipi1205]

WOW! A really nice idea!!!
Are you going to make a D3D9 version? Right now I can't use the D3D11 client, so a version for the D3D9 client would be nice! :thumbup: