Micro-elevation fun

[martins]

Happy new year! Back from holidays, and struggling to find time for Orbiter development.

I'm in the process of of switching the default surface patch mesh resolution from 33x33 to 65x65 nodes. This will have some impact on performance (4x the number of vertices for planet surfaces), but will also improve the visual appearance significantly where high-res elevation is available.

This brings the minimum supported node spacing to about 8 meters (for Earth and level-19 tiles). That's enough to roughen up the local vegetation (see image). There isn't any data available at that resolution I know of, so this was all hand-crafted to fit with the textures. It's pretty tedious to paint those elevations by hand, so I will only do the local KSC scenery as a proof of concept.

Still, pretty cool, no?

 

[Face]

Still, pretty cool, no?

Indeed. Orbiter quickly approaches FSX standards in this regards IMHO. Only micro-objects like trees and boulders are missing now.

 

[MaverickSawyer]

Indeed. Orbiter quickly approaches FSX standards in this regards IMHO. Only micro-objects like trees and boulders are missing now.

How hard would it be to add some terrain scatter of trees and such around bases?

 

[fort]

Happy new year!

Still, pretty cool, no?

Happy new year. And, yes, it's pretty cool.

When you say: "There isn't any data available at that resolution ...( level19 ), you are talking about elevation indeed "

Good day.

 

[N_Molson]

Looks great ! Stuff like the Great Pyramids, China's Wall or The Grand Canyon should become interesting places

 

[jedidia]

Will it be possible for graphics clients to introduce perlin noise microterrain? That would be awesome.

How hard would it be to add some terrain scatter of trees and such around bases?

You can make them part of the bases visuals, shouldn't be a problem.

 

[Artlav]

Will it be possible for graphics clients to introduce perlin noise microterrain? That would be awesome.

Considering that i had it in OGLA, i would guess it's not too hard.

 

[Loru]

We'll need surface elevation patch > msh (or other 3d format) and back converter. Imagine all those bases among the canyons on Europa or hidden in craters of the Moon.

---------- Post added at 12:28 PM ---------- Previous post was at 12:26 PM ----------

Looks awesome indeed.

 

[Urwumpe]

Maybe we can also access some TanDEM-X radar altimeter data for improving the tiles, the resolution is high enough to see tractor tracks in the ground (about 1 meter resolution in the best case, 3m and 6m for lower quality DEMs), but not yet global. Also the guaranteed vertical resolution is only 2 meters, though it is usually much better in the data.

A SpotLight data set with 1m resolution covers 10x 5 km surface, which is perfect for improving an Orbiter base.

 

[Post much?]

I'm in the process of of switching the default surface patch mesh resolution from 33x33 to 65x65 nodes.

Does this mean the elevation patch size is now 515x515? And also, will there finally be a means to roll your own elevation data in the near future? I'm busy downloading the whole SLDEM2013 elevation map and am hungry to see it at level 12 resolution soon

 

[martins]

Does this mean the elevation patch size is now 515x515? And also, will there finally be a means to roll your own elevation data in the near future? I'm busy downloading the whole SLDEM2013 elevation map and am hungry to see it at level 12 resolution soon

No, the patch size in the files remains at 256x256 (or rather 259x259 including padding), to avoid having to re-package the entire elevation tileset. The only difference is that a patch now queries its granddad, rather than the great-granddad for its elevation data. This also allows to make the grid resolution user-selectable without much hassle, for anybody who wants to retain the 33x33 grid for performance reasons.

I can clean up one of the Matlab files I wrote to generate an elevation tile set, if that's any use. Unfortunately the scripts are not very generic but depend on the format in which the source data were available, so manual editing of the scripts may be required to adapt it to other datasets.

Most scripts also require gdal as an external dependency, which performs any required reprojections and mosaic constructions.

If I remember correctly, you also need a Matlab with BigTIFF support for reading GeoTIFF files. This may mean a fairly recent Matlab version, and possibly also the Image Processing toolbox (not sure). Depending on dataset and resolution, gdal might produce a really big GeoTIFF file (several 100GB) if you process the global surface in a single pass.

Finally, the scripts were done pretty quickly and are not really "production class". In particular, they may not be very economic with memory. I ran most of the scripts on a machine with 128GB RAM. Probably overkill, but any less than 32GB might cause problems. This could probably be fixed with not too much effort, if anyone wants to give it a go.

 

[SolarLiner]

We'll need surface elevation patch > msh (or other 3d format) and back converter. Imagine all those bases among the canyons on Europa or hidden in craters of the Moon.

Maybe not an elevation to mesh conversion, but a tool to be able to paint on 32bit grayscale images and then converting them to elevation data might be great though.

Nonetheless, this looks really, really good! I do agree with MaverickSawyer here, the only thing remaining I guess are terrain scatter objects. Something a la KSP would be really great, but would mean defining 'biomes' to select which objects are spawned.

 

[TMac3000]

This looks awesome!
I'm really afraid Orbiter is going to out-grow my system specs one of these days

 

[Post much?]

No, the patch size in the files remains at 256x256 (or rather 259x259 including padding), to avoid having to re-package the entire elevation tileset. The only difference is that a patch now queries its granddad, rather than the great-granddad for its elevation data. This also allows to make the grid resolution user-selectable without much hassle, for anybody who wants to retain the 33x33 grid for performance reasons.

I can clean up one of the Matlab files I wrote to generate an elevation tile set, if that's any use. Unfortunately the scripts are not very generic but depend on the format in which the source data were available, so manual editing of the scripts may be required to adapt it to other datasets.

Most scripts also require gdal as an external dependency, which performs any required reprojections and mosaic constructions.

If I remember correctly, you also need a Matlab with BigTIFF support for reading GeoTIFF files. This may mean a fairly recent Matlab version, and possibly also the Image Processing toolbox (not sure). Depending on dataset and resolution, gdal might produce a really big GeoTIFF file (several 100GB) if you process the global surface in a single pass.

Finally, the scripts were done pretty quickly and are not really "production class". In particular, they may not be very economic with memory. I ran most of the scripts on a machine with 128GB RAM. Probably overkill, but any less than 32GB might cause problems. This could probably be fixed with not too much effort, if anyone wants to give it a go.

For Matlab, I have R2015b, and will acquire the Mapping Toolbox (not Image Processing, already have that) shortly. For GDAL, I don't know the required version, but is 1.11 recent enough?


In regards to the SLDEM2013, I am downloading 45°×45° chunks, downsampling them to 1024 ppd since the effective resolution of the data is WAY lower than indicated. The authors behind the SLDEM2015 analyzed the RMS error at 5 different resolutions and found the lowest value was somewhere between 256 to 512 pixels per degree, or around the detail of a 131k×65k map, however I will see if going one level higher (262k×131k) would produce better quality. A global level 11 elevation map weighs in at 16GB, a bit too much for my PC, which only has 12GB total. I hope the script can/can be modified to process the data in chunks, so lower-end computers can handle huge datasets better, and I hope that doesn't mess up the padding calculations when the time comes to merge the data.


To note, I processed a single 32k×32k color bitmap and plsplit handled it fine. So, if the memory usage can be tuned down a bit, I'll test the script and see where that leads me .

 

[ZiggyStardust]

There's a 30m global land cover dataset here:

http://www.globallandcover.com/GLC30Download/index.aspx

Seems like it's 8.5GB in size, not that huge compared to the hires textures, and resolution is fine enough to show SLF strip as "artificial" surrounded by "wetland".

That could be useful to steer local modifications, i.e. local geotypical texture splatting, or autogen of trees and buildings eventually.

I don't know if license permits reuse tough.

 

[Loru]

Maybe not an elevation to mesh conversion, but a tool to be able to paint on 32bit grayscale images and then converting them to elevation data might be great though.

Well - Meshfile can be very usefull for designing custom base objects that perfectly fits terrain. (Think of the settlement inetgrated inside a mountain ridge where elements are sticking from the mountain slopes). I think elevation data format is easy enough for our programmers to make simple tool.

 

[Tex]

I like! Thanks Martin!!

 

[Abloheet]

Sir, how did u paint the micro terrain manually on to the terrain data? What tool did you use to modify the data manually?

 

[jroly]

Sir, how did u paint the micro terrain manually on to the terrain data? What tool did you use to modify the data manually?

We asked quite awhile ago, a new tool needs to be developed to create bases in Orbiter 2015, using tiles like in 2010 is now defunct which Martin said. Martin probably wrote something to do it but not ready for release, probably when Orbiter 2015 is released out of beta.

 

[GLS]

Like I said in another thread: "soon enough we'll be starting the simulation with a DG parked at the end of the street". :lol:
Thanks Martin!