Having fun in the mountains ...

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,352
Reaction score
9
Points
0
Website
orbit.medphys.ucl.ac.uk
I may be a bit late to the action, but here is something I've been playing with:

[ame="http://www.youtube.com/watch?v=pfvCJNbEG-c"]http://www.youtube.com/watch?v=pfvCJNbEG-c[/ame]

Before you get too excited:
  • For now, this is just a proof of concept
  • It's very preliminary, about a week's worth of coding
  • It's not very stable yet
  • It's just eye candy for now. No surface interactions yet.
  • Even the eye candy isn't too good yet. Some artefacts, ugly shadows

If this does make it into a future release, it will probably be just as a reference implementation, to show the use of any new interfaces for addon developers. The proper stuff will hopefully be done by somebody else, similar to the graphics clients.

This isn't uploaded to the beta repository yet, but maybe I can do it in the next few days. For now, only the inline graphics client supports it. I still have to port it to the D3D7 client.
 

Andy44

owner: Oil Creek Astronautix
Addon Developer
Joined
Nov 22, 2007
Messages
7,625
Reaction score
4
Points
113
Location
In the Mid-Atlantic states
Cool.

That video reminds of a game I played on the Atari 5200 long ago called Resuce on Fractalus. I'm fairly certain that if you were to land in one of those valleys a hideous alien would jump up and smash his way through your windscreen...
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,646
Reaction score
138
Points
153
Location
Langendernbach

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,003
Reaction score
117
Points
88
Location
Lisbon
Website
orbiterspaceport.blogspot.com
Looks cool. :thumbup:

From a mesher & script based add-on maker point of view, the only thing I need is 1) a way to define altitude for each point on the surface OR 2) generic collision with meshes.

For method 2 there's no need for a terrain generator, but for method 1 I'd be happy with the mountains shown on the video. I'm happy with Orulex and it's not perfect also.
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,560
Reaction score
35
Points
138
Location
Moscow
Website
orbides.org
Nice!

Is it in the good old cylindrical LOD grid?
If so, what would happen around the poles?
If not, how did you align the textures (and with what)?
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,646
Reaction score
138
Points
153
Location
Langendernbach
Looks cool. :thumbup:

From a mesher & script based add-on maker point of view, the only thing I need is 1) a way to define altitude for each point on the surface OR 2) generic collision with meshes.

(1) is pretty ineffective if you want to cover more than a few square meters. For a full planet to look half-way good, you need a more efficient structure to get the data. It is similar to the planetary textures in Orbiter. Remember that Orbiter would need to cover scales from low orbit to EVA.

The best I have seen so far operated by two approaches: It has a two-dimensional tree/map structure for storing the height data. And it interpolates between available samples by using different procedural terrain generators.

But already a rather simple terrain engine like they use in DCS:World would be sweet enough, despite looking a bit too planar and sharp-edged from a tank drivers perspective, but the procedural vegetation improves the world a lot.

And (2) works for small surface bases, but is terrible for bigger projects and is performance-wise terrible. A topography tree structure (Like: kd-tree, quadtree) is much faster.

But: From a 1000x1000 data point digital terrain model file, you can produce a not too bad 20000 triangle mesh of a ~30 x 30 km region by a simple greedy algorithm.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
4,125
Reaction score
30
Points
73
Location
Dallas, TX
[*]It's just eye candy for now. No surface interactions yet.

Quite frankly, this has always been the biggest problem with 3D terrain in Orbiter: Either there have been no surface interactions at all, or the surface interactions have been implemented by third-party developers outside of the main physics engine. I don't see 3D terrain really taking off until the physics engine supports it natively.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,352
Reaction score
9
Points
0
Website
orbit.medphys.ucl.ac.uk
Nice!

Is it in the good old cylindrical LOD grid?
If so, what would happen around the poles?
If not, how did you align the textures (and with what)?

Yes, I'm afraid it is still cylindrical LOD, although a bit modified from the old Orbiter grid. The root of the quadtree is now simply a 2x1 grid of patches, each divided into 4 patches for the next level. This avoids complicated patch alignment at different latitude bands and easier implementation of the quadtree, at the cost of slightly larger texture volumes because of anisotropic pixel sizes at high latitudes.

What you see in the video is the alps mapped up to level 17 (corresponding 16384x8192 patches over the sphere), where each patch has a mesh with a 25x25 node grid. So it's a resolution of about 100m/element. I got the data from a MOLA 90m data set.

I won't be able to ship the entire Earth at that resolution. Currently I've global coverage for level 15, and a few "scenic hotspots" at level 17. Even so, the elevation data comes in at a few GB after compression. Not sure yet how to distribute that.
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,560
Reaction score
35
Points
138
Location
Moscow
Website
orbides.org
Not sure yet how to distribute that.
At one point i had a "World Studio" program for Orulex. In it you selected a region of interest and a resolution level, and it would download textures or height maps from various now-dead WorldWind servers (Landsat, USGS, etc), and save the data in the right format for Orbiter SURFTILEs or Orulex.

Maybe you can do something similar, with modern data sources?
Or set up a data server with custom-made maps, i.e. on OrbitHangar.

Yes, I'm afraid it is still cylindrical LOD
Have you considered using a cubic LOD?
Would there be any drawbacks (besides needing to convert each and every planet texture already made)?
 

statickid

CatDog from Deimos
Donator
Joined
Nov 23, 2008
Messages
1,682
Reaction score
0
Points
0
One thing that made me stop using Orulex was that the surface was "immune" to the atmospheric haze. I preferred to have a more seamless visual experience with no terrain to having it suddenly explode into view with saturated colors. Also, the moon didn't look natural in the sky on the surface, it appeared black and white rather than the nice "daytime blue" of the moon without mods. Does this terrain generator address any of these visual anomalies?
 

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
0
Points
0
Location
404 ROAD NOT FOUND
Already looks neat ;)
For a collision point of view, I don't think it has to be the first thing to implement with the terrain, as Orbiter is a Space flight sim. Terrain will adds some sort of bump to the planet, and enhance the reentries a lot. Wideawake has a terrain with no collision and everyone is happy with that :)

For the distribution you may add a basic level 7 heightmap (like the diffuse planet textures) and have the full res to servers capable of handling powerful bandwidth, like a Google Drive cloud. Now 5 Gb for free may be not enough for all 4 rocky planets (and their moons).

Finally, I may bring back a long and old discussion here, but once the terrain collision system is done, would it be possible to port to a vessel collision system? That would be the ultimate update of Orbiter.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,352
Reaction score
9
Points
0
Website
orbit.medphys.ucl.ac.uk
At one point i had a "World Studio" program for Orulex. In it you selected a region of interest and a resolution level, and it would download textures or height maps from various now-dead WorldWind servers (Landsat, USGS, etc), and save the data in the right format for Orbiter SURFTILEs or Orulex.

Maybe you can do something similar, with modern data sources?
Or set up a data server with custom-made maps, i.e. on OrbitHangar.
A custom online tile fetch mechanism would be nice, but I guess depending on popularity there could be quite a demand on the server, so this could translate into costs. Maybe I'll have to ask ESA or NASA if they are interested in sponsoring a file server ;)
Have you considered using a cubic LOD?
Would there be any drawbacks (besides needing to convert each and every planet texture already made)?
I did consider it, but cylindrically mapped tiles do have advantages. Most surface map resources are in cylindrical projection, which makes them easy to convert to Orbiter, without need for a complex mapping mechanism.
Also, queries to the terrain manager for elevation data will be usually based on longitude/latitude coordinates (e.g. from a vessel checking for collision), so traversing the quadtree to find the correct patch will be trivial if the patches are already aligned that way.

Does orulex use a cube projection?
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,560
Reaction score
35
Points
138
Location
Moscow
Website
orbides.org
Maybe I'll have to ask ESA or NASA if they are interested in sponsoring a file server ;)
How about Google? They already have the servers, the data and the interface. :cool:

Does orulex use a cube projection?
Yes, Orulex is the same engine which is in OGLA, and it's based on cube projection, which i explained back in January.
To support Orbiter's textures i did projection translation at runtime, pixel by interpolated-on-CPU pixel, so it was rather slow.

The Orulex's interface to collision engines take a vector (from centre of the sphere to the point on the surface), and returns elevation at the point - no latitude/longitude, no singularities.
The data comes directly from the underlying dataset, without parsing a quadtree.

Also, queries to the terrain manager for elevation data will be usually based on longitude/latitude coordinates (e.g. from a vessel checking for collision), so traversing the quadtree to find the correct patch will be trivial if the patches are already aligned that way.
Interesting.
Never thought of that.

Basic design of my terrain system is a function that takes a vector, and returns the data for the point.
There is a function for elevation, a function for texture colour, a function for biome, etc.
These functions can either interpolate a dataset, or provide procedural generation.
Quadtree algorithm that makes the mesh produce textures and heightmaps by running the functions.
So does the collision engine.

In your case the elevation data is loaded from disk directly mapped to the quadtree structure, you don't get that kind of information for free and have to actually look it up, so cylindrical would be easier.
That about sums it up?
 

tomthenose

Addon Developer
Addon Developer
Joined
Jan 27, 2011
Messages
96
Reaction score
0
Points
0
Location
aberdeen, scotland
it would be cool to have terrain as standard for some future version of orbiter, even really simple landscapes like in 'Pioneer' make a huge difference to immersion. Lookin good
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,352
Reaction score
9
Points
0
Website
orbit.medphys.ucl.ac.uk
In your case the elevation data is loaded from disk directly mapped to the quadtree structure, you don't get that kind of information for free and have to actually look it up, so cylindrical would be easier.
That about sums it up?

Yes, pretty much. So in your case, the elevation data for the entire planet is preloaded at the highest resolution (unless you generate it procedurally on the fly), and the tiles extract the information from the data set whenever they are constructed? I guess that could get quite bulky for high resolution terrain data. Does your mechanism allow for local variations in the maximum supported resolution?
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,560
Reaction score
35
Points
138
Location
Moscow
Website
orbides.org
Does your mechanism allow for local variations in the maximum supported resolution?
Sort of.
Heightmaps are always loaded completely, to allow for collision data, for textures i did some on-demand loading optimizations to make it fit the RAM.
Local heightmaps were up to Lv17 or so (USGS data), they are checked independently of the global heightmap (bounds check to see which heightmap to sample data from), so you could have variable level of details without needing to have one global Lv17 array.
One global Lv8 heightmap is 112Mb, i never went higher than that, and extra details could be added by some procedural noise.
If you need, i still have them online here - http://orbides.1gb.ru/orulex.php , Mars, Moon, Earth, reasonably accurate. Format is X res, Y res, array of int16 data.

The engine was designed for procedural generation from scratch - early version of Orulex couldn't show normal planetary textures at all - so it's far from efficient when you're dealing with existing data.
A slow general solution, rather than a fast special-case one.

But that all only applies to the whole system, the cubic quadtree part is (probably) as good as any other LOD - if you have textures/height maps split in it's format, they would just load directly to the tiles - looks the same, works faster, takes no extra RAM.
So, if Orbiter had cube mapped textures, it would just snap into place, making my job a lot easier in OGLAClient. :)
 

Hielor

Defender of Truth
Donator
Beta Tester
Joined
May 30, 2008
Messages
5,632
Reaction score
0
Points
0
Looks awesome! Although, it looked like you were having some trouble with coordinated turns...maybe you should use AutoRudder ;)
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,003
Reaction score
117
Points
88
Location
Lisbon
Website
orbiterspaceport.blogspot.com
I'll leave the discussion for the experts, but I'd like to point out that if you use 8 bit values, global heightmaps are much smaller. Sure, there's some stepping effect, but can be overcome with random small scale terrain generation. For general distribution, I wouldn't object.

Again from a user point of view, I only need the spacecraft to land at the correct altitude, and to have the landing points intersect the local slope ;-) That way, I have real piloting to do and of course, to find a suitable landing spot. Perhaps do some scout flight before the actual landing. That is important for a simulator!

Small scale details could be derived taking into account surface roughness. Such data exists, again in image format, easily convertible to coordinates if needed.
For Venus (Venus Meter-Scale Slope) at least, and I think I've seen it for the Moon and Mars.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,352
Reaction score
9
Points
0
Website
orbit.medphys.ucl.ac.uk
Here's a first small fix for the 'ugly shadows' problem: cell diagonals adapted to local gradient. See the before/after image. (This is the Grand Canyon, btw, if you didn't spot it :thumbup:)


 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,560
Reaction score
35
Points
138
Location
Moscow
Website
orbides.org
if you use 8 bit values, global heightmaps are much smaller. Sure, there's some stepping effect
Alps on average are 4 km tall. Divide by 256, and you get steps of 15-16 metres.
Double the heightmap size by going 16bit, and the error is only 6cm.

I've made some examples with simulated 8bit heightmap compared to simulated 16bit one.
From far away they look about the same, snow line starts at about 4km.
http://spaceway.1gb.ru/img/terres-far-8.jpg
http://spaceway.1gb.ru/img/terres-far-16.jpg

But up close it looks quite bad:
http://spaceway.1gb.ru/img/terres-near-8.jpg
http://spaceway.1gb.ru/img/terres-near-16.jpg

Remember, that you will be landing on that - no smooth slopes, only either 16 meter up or 16 metres down.

If you're thinking interpolation, then there is the problem:


Basically, as you double up resolution with 8 bit heightmap, you can only get sharper 16-metre cliffs, while with 16 bit heightmap you can bump up resolution as far as you like (up to about 12cm/pixel), and still get smooth slopes.

So i picked 16bit heightmaps for Orulex.
But as we seen already, my solutions don't always fit Martin's objectives well, so maybe he can make it work.

---------- Post added at 04:24 ---------- Previous post was at 04:21 ----------

Here's a first small fix for the 'ugly shadows' problem: cell diagonals adapted to local gradient.
See - he already made it better than what i have. :)
 
Top