New Orbiter Beta Released (r.13, Mar 7, 2015)

[SolarLiner]

Assuming that GetAltitude is used by the GPWS on the OrbiterSound addon, and various other add-ons (like the XRs, Shuttle Fleet, etc.), I'd say that GetAltitude() gets the new "altitude over terrain" code, while a GetAltitudeASL() contains the old code.

 

[Face]

By the way, speaking of altimeters, here is a question for addon developers: since there is now a difference between "altitude over ground" and "altitude over mean radius" (or "radar altitude" and "barometric altitude"), I will have to introduce a new VESSEL::GetAltitude method where you have to specify which type of altitude you want. The question is: what should the default behaviour of the old GetAltitude method be, to ensure maximum backward compatibility, altitude over ground or over normal-zero? I guess different addons may have different expectations, so either way there may be backwards incompatibilities.

IMHO it should keep its old meaning: altitude over mean radius.

As we've established above, the altitude over ground could well vary from one simulation run to the next, given different levels of elevation data is present and/or different visualization settings are applied. In the past, the altitude value was not that "volatile", so perhaps simply extending the API with another function returning the altitude above ground is better than changing the behavior of the previous function.

In addition, I think many vessels were programmed with the altitude display simulating barometric instruments. It might be strange to see them suddenly behaving like a laser-altimeter instrument.

just my :2cents:, though

 

[Loru]

I'm with face on that. In either way we'll need new hud mode or radar altitude display on hud.

 

[martins]

- I only downloaded the north-east part of India (which contains a part of the Himalaya mountains), and I sometimes get giant walls at points where the low-res and high-res elevation data touches. It only lasts a few seconds tho, when loading is finished, everything looks good again.

I've implemented an edge-matching algorithm to account for difference in LOD levels between neighbouring surface patches (look at the D3D7 code on OVP if you are interested in the details). This only works for a maximum difference of 5 levels between neighbours. Normally, the difference shouldn't exceed that limit, but it may do while building up a scene, or, as in your case, when neighbouring areas have different resolution data.
If this turns out to be a problem, I may have to look at solutions to enhance the edge-matching algorithm, but for now I think it's relative low priority.

- Sunrises and sunsets looks a bit washed out. I don't know if it's because I now only play on the D3D9 client, but they looks different (and less vibrant) than what it used to look to me.

I don't know - what happens when you run the 2010 release with the inline client?

 

[SolarLiner]

what happens when you run the 2010 release with the inline client?

I get the same sunset, so it is D3D9. Issue closed, I guess.

 

[FordPrefect]

Maaan, that's looking fantastic! Thanks martins for all your efforts! :thumbup:


Now all we need is the amazing atmospheric rendering ala Proland/Eric Bruneton, code is made freely available.


@ SolarLiner: Would you mind posting one screenshot with lunar terrain, just one?

 

[Loru]

Stupid question - are elevation data tiles coresponding to texture tiles?? I mean do they have the same size (covering same surface of the same coordinates) and same subfolderfolder/filename??

 

[thanksforair]

new feature is awesome! BIG Thanks.
all hail martin

 

[martins]

Stupid question - are elevation data tiles coresponding to texture tiles?? I mean do they have the same size (covering same surface of the same coordinates) and same subfolderfolder/filename??

Well, yes and no ...

A surface tile is composed of a 32x32 cell grid, i.e. composed of a 33x33 node mesh, and covered with a 512x512 texture.

However, since packing each 33x33 block of elevation data into a separate file would result in a huge number of small files, I used a "great-grandparent inheritance" scheme. : A tile stores the elevation data covering its area in a 257x257 grid, i.e. 8 times larger than required by the mesh. (actually, it's a 259x259 grid, since it uses padding to support continuous normals across tiles).

When the tile constructs its mesh, instead of using its own data, it asks its great-grandparent for a subset of its data. So if you have elevation data up to subfolder "13" installed, they will provide data for tiles up to level 16.

 

[jangofett287]

How big is the full high-res textures and height map data? Just so I can be sure I have enough space before I start downloading.

 

[Ripley]

I just did it for my website (values rounded):


Harddisk space required by zipped LoRes textures

EarthCloud 309 Mb
EarthLo    134 Mb
MarsLo     451 Mb
MoonLo     514 Mb
-----------------
TOTAL    1.408 Mb
=================

Harddisk space required by unzipped LoRes textures

EarthCloud 728 Mb
EarthLo    435 Mb
MarsLo     738 Mb
MoonLo     739 Mb
-----------------
TOTAL    2.640 Mb
=================

Harddisk space required by zipped HiRes textures

Orbiter2014_Beta_Textures_Earth 17,6 Gb
Orbiter2014_Beta_Textures_Mars   3,6 Gb
Orbiter2014_Beta_Textures_Moon   8,0 Gb
---------------------------------------
TOTAL                           29,2 Gb
=======================================

Harddisk space required by unzipped HiRes textures

Orbiter2014_Beta_Textures_Earth 53,4 Gb
Orbiter2014_Beta_Textures_Mars   7,0 Gb
Orbiter2014_Beta_Textures_Moon  24,7 Gb
---------------------------------------
TOTAL                           85,1 Gb
=======================================

P.S.1: Downloadable HiRes textures size subject to grow with time, until fully released.
P.S.2: Mars and Moon LoRes Values corrected.

 

[DaveS]

Is it a known condition that the default DG wobbles during the take-off run from the KSC SLF? FYI, no joystick or any add-ons, plain Orbiter 2014 with the hi-res textures installed.

 

[Loru]

When the tile constructs its mesh, instead of using its own data, it asks its great-grandparent for a subset of its data. So if you have elevation data up to subfolder "13" installed, they will provide data for tiles up to level 16.

So basically it looks something like this?? (padding ignored for a while):

Next question then. Are those elevation vertices spanned evenly and only differ in height or they differ from regular square/rectangle grid??

Hmm - we'll need a converter from elevation to msh and back or something similar like heghtmap in png/3ds/obj.

 

[SolarLiner]

we'll need a converter from elevation to msh and back or something similar like heghtmap in png/3ds/obj.

Heightmap, as any elevation map should be, you're gonna have serious troubles converting from mesh to elevation data if the mesh has overlapping vertices. A 32bit EXR file for the best quality, or just a 16bit PNG texture should be enough.

 

[Loru]

Heightmap, as any elevation map should be, you're gonna have serious troubles converting from mesh to elevation data if the mesh has overlapping vertices. A 32bit EXR file for the best quality, or just a 16bit PNG texture should be enough.

I think I know my 3d editor well enough not to make overlaping vertices (EditMesh->Vertex->Weld) And it has advantage as you can check how your other structures will look in the scene.

 

[SolarLiner]

True that, but it's not for no reason that heightmaps are used for elevation data, and not meshes. Plus you can paint on them, and can always have a visual representation of the heightmap via various programs, and even import the heightmap into a mesh in most 3D meshing programs.

 

[martins]

Next question then. Are those elevation vertices spanned evenly and only differ in height or they differ from regular square/rectangle grid??

To be honest, I didn't quite understand the image , but yes, the elevation data are on a regular grid. The files only contain the elevation values, not the x and y positions of the grid points.

Please note that the elvation data files (*.elv) also contain a little header in addition to the raw binary data. I am planning to do some documentation of the file format, but for now you can glean the essentials by looking on the header structure (ELEVFILEHEADER) and the file reader method (SurfTile::LoadElevationData) in surfmgr2.cpp. The most important elements are dtype (specifying if the data are stored as 8 or 16 bit signed/unsigned integers, or if the entire tile is flat), and scale and offset, which allow to extract the true elevation [m] from the stored value as

elev = offset + scale*value

(note that for now scales other than 1.0 are not yet supported but will be in the future).

Tiles which don't need more than 256 distinct elevation values should store their data in 8-bit values to save space.

 

[Loru]

To be honest, I didn't quite understand the image

I should've explained it better. Each pixel in the image coresponds to single elevation vertex (so texture tile here is 32x32 px). It was aimed at visualizing size comparison between elevation data and texture data.

Anyway that's all I need to know now. I'll get to it when bases are implemented and I'll be converting CSSC for new Orbiter version.

 

[martins]

Is it a known condition that the default DG wobbles during the take-off run from the KSC SLF? FYI, no joystick or any add-ons, plain Orbiter 2014 with the hi-res textures installed.

I guess you are talking about the fact that the surface of the SLF is no longer flat? This is down to the SRTM-90 elevation data. Since these data will inevitably have some noise on them, and due to the fact that the data have an altitude resolution of 1m, this may result in more wobble on a runway than realistic. Some manual editing of the elevation data may be needed. I'll look into it. (I already had to manually edit away the elevation hump from the VAB.)

 

[N_Molson]

There won't be a lot of originality in the comment : awesome !

Seriously, this is all I was dreaming for since a couple of years. Excellent.

BTW, when maneuvering into narrow valleys, you fully realize how the stock DG is an amazingly nimble craft :lol: