Having fun in the mountains ...

Zachstar

Addon Developer
Addon Developer
Donator
Joined
May 1, 2008
Messages
654
Reaction score
0
Points
0
Location
Shreveport, Louisiana
Website
www.ibiblio.org
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.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,349
Reaction score
13
Points
0
Website
orbit.medphys.ucl.ac.uk
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.
 

BruceJohnJennerLawso

Dread Lord of the Idiots
Addon Developer
Joined
Apr 14, 2012
Messages
2,585
Reaction score
0
Points
36
Really excited to see this getting started! :thumbup:

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?!?! :eek:wned:

(ie nice simulated water, or just a flat plane at sea level ;))
 

RisingFury

OBSP developer
Addon Developer
Joined
Aug 15, 2008
Messages
6,320
Reaction score
205
Points
153
Location
Among bits and Bytes...
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?
 

BruceJohnJennerLawso

Dread Lord of the Idiots
Addon Developer
Joined
Apr 14, 2012
Messages
2,585
Reaction score
0
Points
36
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.
 

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
0
Points
0
Location
404 ROAD NOT FOUND
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 ;)
 

Hielor

Defender of Truth
Donator
Beta Tester
Joined
May 30, 2008
Messages
5,632
Reaction score
0
Points
0
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.
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,589
Reaction score
102
Points
153
Location
Moscow
Website
orbides.org
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...
 

orb

O-F Administrator,
Administrator
Joined
Oct 30, 2009
Messages
14,023
Reaction score
0
Points
0
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:
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.
 

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
0
Points
0
Location
404 ROAD NOT FOUND
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, :threadjacked: sorry :embarrassed:
 

RisingFury

OBSP developer
Addon Developer
Joined
Aug 15, 2008
Messages
6,320
Reaction score
205
Points
153
Location
Among bits and Bytes...
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.

Even creating a crater for old bases wouldn't be trivial. It'd require modification of the height map, but in a way where you can specify a file that replaces only part of the height map.

I'd really prefer it if objects were mapped to the terrain the way they are mapped to a sphere now as orb pointed out.

In either case, it'd be a good idea to have a way to modify a local area of the height map without actually changing the main file. Kind of like what local surface tiles do for bases. The reason for that is let's say we have an existing base that now gets a height map and all of the runways and taxiways get all crooked...
 

BruceJohnJennerLawso

Dread Lord of the Idiots
Addon Developer
Joined
Apr 14, 2012
Messages
2,585
Reaction score
0
Points
36
Even creating a crater for old bases wouldn't be trivial. It'd require modification of the height map, but in a way where you can specify a file that replaces only part of the height map.

It would be difficult, but not insanely so, given that Artlav can already supply his base crater implementation (or at least the general idea behind how it works)

I'd really prefer it if objects were mapped to the terrain the way they are mapped to a sphere now as orb pointed out.

In either case, it'd be a good idea to have a way to modify a local area of the height map without actually changing the main file. Kind of like what local surface tiles do for bases. The reason for that is let's say we have an existing base that now gets a height map and all of the runways and taxiways get all crooked...

I agree, the only issue would be that older scenarios might become incompatible, with the vessel below terrain alt
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,349
Reaction score
13
Points
0
Website
orbit.medphys.ucl.ac.uk
Regarding bases: mapping objects such as buildings to the actual surface elevation won't be too difficult. More of a problem are the "flat" features such as runways and taxiways. Up to now planetary surfaces have been rendered without a z-buffer, which was ok because of the convex shape, which meant no hidden face removal was required. Runways were then simply rendered after the planet surface, and were guaranteed to be visible, and obviously wouldn't suffer from z-tearing.

With elevation support, this mechanism doesn't work anymore. Planet surfaces now must be rendered with z-buffering on. This means runways also must be rendered with z-buffer (otherwise they would be visible through obstacles like mountains). Even if I matched the elevation of the runways to the terrain, this would lead to z-tearing.

One possibility would be to add a z-bias to runways, but this is really a hack offered by directx. If you make the z-bias small, you still get tearing at large distances. If you make it large, the runway may actually hide a spacecraft sitting on top of it.

The ideal situation would be if the runway was rendered together with the surface. I was thinking about supporting an optional second texture for each surface tile. The second surface would be transparent except for the features it wants to add (runways, etc). The render engine would then use both textures on top of each other in the same render pass.

The disadvantage is that the resolution for these surface features is then no longer arbitrary, and you could no longer define runways parametrically in the def file. It would actually have to be painted into a texture. Also, there could be a lot of waste if you need to provide a complete tile texture for only a small feature.
 

Kendo

New member
Joined
Oct 16, 2007
Messages
589
Reaction score
1
Points
0
Could a runway be made a simple mesh, would this work.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,779
Reaction score
269
Points
173
Location
Langendernbach
What about creating a runway mesh in Orbiter from the terrain elevation data? Like starting with two triangles and then subdividing them, where each triangle intersects with the edges of the terrain? Would only be needed to be done once during scenario start, could still use a different texture resolution than the planetary surface and could in the worst case be shoved into a file for faster loading.

If the same algorithm could then also be extended for taxiways and tarmacs, we would have a pretty good solution for keeping base creation simple and not make things too complicated for add-on makers.

After all, the number of intersection checks for creating such a runway mesh would still be finite... approximately around 2x350x8 = 5600 intersections for a typical sized runway on a 10 m per sample terrain.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,349
Reaction score
13
Points
0
Website
orbit.medphys.ucl.ac.uk
Could a runway be made a simple mesh, would this work.
No. That's how it is done at the moment. Since the mesh coincides with the terrain surface, the z-buffer can't distinguish between the two surfaces, and will show one in some places, the other in others (z-tearing).
What about creating a runway mesh in Orbiter from the terrain elevation data? Like starting with two triangles and then subdividing them, where each triangle intersects with the edges of the terrain? Would only be needed to be done once during scenario start, could still use a different texture resolution than the planetary surface and could in the worst case be shoved into a file for faster loading.

If the same algorithm could then also be extended for taxiways and tarmacs, we would have a pretty good solution for keeping base creation simple and not make things too complicated for add-on makers.

After all, the number of intersection checks for creating such a runway mesh would still be finite... approximately around 2x350x8 = 5600 intersections for a typical sized runway on a 10 m per sample terrain.
But then I would have to cut out the area of the runway from the ordinary terrain surface. It may be doable (with stencil buffers), but it will add a lot of complication.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,349
Reaction score
13
Points
0
Website
orbit.medphys.ucl.ac.uk
Edit: I just thought of another possibility: If I render the runways the same way as currently (as a flat mesh), with a large z-bias, and with z-testing, but without writing to the z-buffer, before rendering any spacecraft, I may bypass any problems. It's still a hack, but hey, life is too short to find an elegant solution for everything :)
 

Quick_Nick

Passed the Turing Test
Donator
Joined
Oct 20, 2007
Messages
4,071
Reaction score
152
Points
103
Location
Tucson, AZ
One possibility would be to add a z-bias to runways, but this is really a hack offered by directx. If you make the z-bias small, you still get tearing at large distances. If you make it large, the runway may actually hide a spacecraft sitting on top of it.
[...]
The ideal situation would be if the runway was rendered together with the surface. I was thinking about supporting an optional second texture for each surface tile. The second surface would be transparent except for the features it wants to add (runways, etc). The render engine would then use both textures on top of each other in the same render pass.

How about a small z-bias, and then stop rendering the runway at sufficiently large distances. If an addon developer wishes, they can add in a runway to the tile, which you would see (and already low-res due to distance) since the actual runway isn't rendering.
This is of course assuming your meaning of 'large distances' is the same as what I'm imagining.

Edit: :ninja:'d. I think many hacks sound more elegant than adding z-biases to various objects.
 
Last edited:

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,589
Reaction score
102
Points
153
Location
Moscow
Website
orbides.org
Planet surfaces now must be rendered with z-buffering on. This means runways also must be rendered with z-buffer (otherwise they would be visible through obstacles like mountains). Even if I matched the elevation of the runways to the terrain, this would lead to z-tearing.
In OGLA i do a second fine pass for Z-buffer rendering after coarse whole-planet one.
In the second pass Z-buffer is set to vessel space scale, and only the nearest terrain is rendered (with colour channels off).
This way you can combine planet-scale and precision in one Z-buffer.

Not sure if this applies, however - that was a solution for a problem of bases and vessels showing through hills. A runway might still be too thin even in a vessel Z-buffer to flicker or be visibly elevated.
 
Top