Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Beta Topics related to Beta releases of Orbiter and Orbiter development.

Reply
 
Thread Tools
Old 08-07-2013, 06:31 PM   #16
Artlav
Aperiodic traveller
 
Artlav's Avatar

Default

Quote:
Originally Posted by martins View Post
 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.
Artlav is offline   Reply With Quote
Old 08-07-2013, 06:51 PM   #17
Hielor
Defender of Truth

Default

Looks awesome! Although, it looked like you were having some trouble with coordinated turns...maybe you should use AutoRudder
Hielor is offline   Reply With Quote
Thanked by:
Old 08-07-2013, 11:32 PM   #18
4throck
Enthusiast !
 
4throck's Avatar
Default

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.
4throck is offline   Reply With Quote
Old 08-08-2013, 12:16 AM   #19
martins
Orbiter Founder
Default

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 )


martins is offline   Reply With Quote
Old 08-08-2013, 12:24 AM   #20
Artlav
Aperiodic traveller
 
Artlav's Avatar

Default

Quote:
Originally Posted by 4throck View Post
 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 ----------

Quote:
Originally Posted by martins View Post
 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.
Artlav is offline   Reply With Quote
Thanked by:
Old 08-08-2013, 09:04 AM   #21
Zachstar
Donator
 
Zachstar's Avatar

Default

I am glad to see the first official steps of real terrain for Orbiter. It makes so much difference when landing on the Mun in KSP compared with landing on the current moon in Orbiter.

In my opinion (Well my case of using Orbiter) I personally would prefer if the engine could create procedurally made terrain from low resolution sources. Yes it may mean things may be out of place compared to higher resolution sources. However, if I am landing on the moon I am not caring that "OH NOES that slope should not be there!" I am "Oh wow that looks amazing!"

This is just my opinion however.
Zachstar is offline   Reply With Quote
Old 08-08-2013, 10:07 PM   #22
martins
Orbiter Founder
Default

Quote:
Originally Posted by 4throck View Post
 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.
I am trying to define a fairly flexible data format for the patch elevation files. My height resolution is currently 1m, since that is what the SRTM source files provide. Any patches with an elevation range of < 256m are stored with 1 byte per sample + offset information, any others with 2 bytes and absolute values. Especially at higher patch resolution levels, where the 256m limit is often not exceeded, this provides some file size savings.
My data format also allows for a scaling factor to the values, but at the moment that isn't supported by Orbiter yet, since I am assuming that neighbour tiles can always match their elevation at the boundary.
martins is offline   Reply With Quote
Thanked by:
Old 08-08-2013, 10:40 PM   #23
BruceJohnJennerLawso
Dread Lord of the Idiots
 
BruceJohnJennerLawso's Avatar
Default

Really excited to see this getting started!

Martins, is there any word on collision detection with this new terrain? Orulex was hampered a little bit by things like terrain dipping below the planets current collision sphere, and physics engines loading out of sync (ie meshland sending a landed vessel to escape velocity on scenario reload.)

Will it have water?!?!

(ie nice simulated water, or just a flat plane at sea level )
BruceJohnJennerLawso is offline   Reply With Quote
Old 08-08-2013, 10:46 PM   #24
RisingFury
OBSP developer
 
RisingFury's Avatar
Default

What will happen to surface bases? Will terrain have to have a crater to allow for bases or will they be updated so we can have bases with elevation above 0?
RisingFury is offline   Reply With Quote
Thanked by:
Old 08-08-2013, 10:53 PM   #25
BruceJohnJennerLawso
Dread Lord of the Idiots
 
BruceJohnJennerLawso's Avatar
Default

Quote:
Originally Posted by RisingFury View Post
 What will happen to surface bases? Will terrain have to have a crater to allow for bases or will they be updated so we can have bases with elevation above 0?
Depends on how strongly Martins wants to stick with backwards compatibility. The crater thing does work, but it often proved a somewhat bad solution in Orulex for a variety of reasons.

I would argue in favour of retaining the old bases as a legacy method, but encouraging developers to create new bases in a new format that keeps everything above ground. Maybe base objects could be set to automatically map to the nearest elevation, although it might leave some buildings with a foundation hanging over empty space.
BruceJohnJennerLawso is offline   Reply With Quote
Thanked by:
Old 08-09-2013, 12:03 AM   #26
SolarLiner
It's necessary, TARS.
 
SolarLiner's Avatar
Default

I'd rather see a plateau where the whole base is sitting on. I kinda dislike the crater feature of Ourlex. Cool for the Moon (even if still too deep), but on the Earth, do not want.
Or, in the case surface bases will not be elevated (for several reasons), I'd see a nice smoothing of the terrain to a 0 level at the base.

A pure coincidence that I'm actually searching for programs that can add details to heightmaps (and I think I found one, which lets you code your map design, I still have to find how to take an imported heightmap in order to give him height beauty. His name is GeoGen), and I think this could be a good way to enhance either "on the fly" or at startup the heights when lacks of precisions are there.
This could start as a simple "nosiy" interpolation system. This could add details easily while staying rather realistic.


This is my ideas for better terrain in Orbiter, but lacks of proof of concept as I don't know all about terrains (and 3D coding as well), so yeah
SolarLiner is offline   Reply With Quote
Thanked by:
Old 08-09-2013, 12:20 AM   #27
Hielor
Defender of Truth

Default

Maybe determine what the altitude for the 0,0 location of the base should be according to your heightmap, and then have a plateau at that height for the base?

Assuming that terrain collision works, that is.
Hielor is offline   Reply With Quote
Old 08-09-2013, 12:31 AM   #28
Artlav
Aperiodic traveller
 
Artlav's Avatar

Default

Quote:
Originally Posted by SolarLiner View Post
 I'd rather see a plateau where the whole base is sitting on. I kinda dislike the crater feature of Ourlex. Cool for the Moon (even if still too deep), but on the Earth, do not want
Hm.
A "crater" was just a name for the feature, it easily generated a plateau - gradual descent of terrain to 0 over kilometres - if you set the settings right.

Then again, i once seen a research that found out that only about 5% of all people change any settings or options on their own initiative...
Artlav is offline   Reply With Quote
Thanked by:
Old 08-09-2013, 12:39 AM   #29
orb
O-F Administrator
Ninja
 
orb's Avatar

Default

Quote:
Originally Posted by RisingFury View Post
 Will terrain have to have a crater to allow for bases or will they be updated so we can have bases with elevation above 0?
I'd say if MapObjectsToSphere is used, and the planet's collision surface is elevated, too, objects should be mapped to altitude of that surface (over the body's mean radius sphere), otherwise there needs to be a new MapObjectsToTerrain configuration option, or something:
Quote:
MAPOBJECTSTOSPHERE (boolean)
If true, the objects in the object list will be automatically adjusted in elevation to correct for the planets curvature. This means that objects with elevation 0 will be mapped onto altitude 0 of the planet surface. If false, elevation 0 maps onto the flat horizon plane of the base reference point. Default: false.
orb is offline   Reply With Quote
Thanked by:
Old 08-09-2013, 12:46 AM   #30
SolarLiner
It's necessary, TARS.
 
SolarLiner's Avatar
Default

Quote:
Originally Posted by Artlav View Post
 Hm.
A "crater" was just a name for the feature, it easily generated a plateau - gradual descent of terrain to 0 over kilometres - if you set the settings right.

Then again, i once seen a research that found out that only about 5% of all people change any settings or options on their own initiative...
Well, I can't say that I didn't tried, but I didn't understand the behaviour then and I gave up...

Uh oh, sorry
SolarLiner is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta

Tags
concept, terrain


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 09:46 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.