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

[DaveS]

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.)

What is the current plan to flatten runways and other smooth areas of bases? The wobble is really bad, leading to several severe pitch oscillations and a drag to the right before even reaching the rotation velocity.

Two areas I'm concerned with is Edwards AFB and Vandenberg AFB, the latter located in a very mountainous area of California.

 

[fsci123]

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


Harddisk space required by zipped LoRes textures

EarthCloud 309 Mb
EarthLo    134 Mb
MarsLo     389 Mb
MoonLo     443 Mb

Harddisk space required by unzipped LoRes textures

EarthCloud 728 Mb
EarthLo    435 Mb
MarsLo     646 Mb
MoonLo     646 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

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

P.S.: Downloadable HiRes textures size subject to grow with time, until fully released.

I dont want ruin the fun and all but i have to bring this up:

When this Orbiter version gets a full release, will we see the arrival of multi-gigabyte addons? And if so how will these large addons be distributed?

Is it possible to have a detailed height map combined with a low res image?
And also what is the resolution of these earth files pixel-wise?

Now that im thinking about it...The arrival of o2014 could trigger an addon arms race in which developers begin to release larger and larger files that pushes the limits of the sim, the website, and the host computer.

 

[martins]

And also what is the resolution of these earth files pixel-wise?

Texture resolution at LOD level 'lvl' is

2 \pi R / 2^(lvl+6) m/pixel

at the equator.

Mesh resolution is

2 \pi R / 2^(lvl+2) m/node

 

[Swigert]

This is my past self before I went to test the beta...How did I even have time to type this?

 

[Face]

The arrival of o2014 could trigger an addon arms race in which developers begin to release larger and larger files that pushes the limits of the sim, the website, and the host computer.

Well, I could imagine a much worse fate for Orbiter than having more and more GBs of add-ons released for it. :lol:

On a serious note, don't forget that the scenery add-ons are outnumbered by vessels, and on that front we've already seen add-ons in the tens of megabytes. The tile for e.g. Valles Marineris covers a huge area with 111MBs in level 11 resolution, but the files it consists of are as small as 150kB. I can imagine that a particular smaller area of custom scenery could be implemented with a smaller footprint.

On a side note: due to the small size of the files the data consists of, putting it in version control was no problem at all. That enabled me to confirm that only matching installation of elevation data levels (regarding surface tile levels) will get you consistent surface collision experience.

 

[SolarLiner]

[bla bla bla] version control [bla bla bla]

Is it me or you have these words in every single post you make? :lol:

I believe that we're about to have the first >1 Gb addons being released with Orbiter 2014. The ones that covers countries or interesting landmarks on planets. But, since Orbiter 1.0, the internet has grown exponentially, no?

 

[Face]

Is it me or you have these words in every single post you make? :lol:

It's just you, because it is clearly visible that the post before that one did not contain them . Besides that, the fact that I'm very interested in this topic is not exactly a secret here.

 

[N_Molson]

Get fiber optics. I can tell you I really enjoyed it in this particular case

 

[Pipcard]

Okay, downloaded it through torrent, which took an hour, and extracted it, which took another hour. Now it works.

It's almost like downloading the entirety of Google Earth's textures/terrain data.

 

[Xyon]

On a side note: due to the small size of the files the data consists of, putting it in version control was no problem at all. That enabled me to confirm that only matching installation of elevation data levels (regarding surface tile levels) will get you consistent surface collision experience.

I have a loathing for reams of static binary data clogging up immutable history in version control, though I bet the small files go in well, they then make high-res terrain non-optional, which puts out our more bandwidth-limited users.

Working out how best to distribute all this data has given me a lot of thinking to do over the months, but I'm open to suggestions for improvement if anyone has any ideas.

 

[Face]

I have a loathing for reams of static binary data clogging up immutable history in version control, though I bet the small files go in well, they then make high-res terrain non-optional, which puts out our more bandwidth-limited users.

Working out how best to distribute all this data has given me a lot of thinking to do over the months, but I'm open to suggestions for improvement if anyone has any ideas.

I've put them into a separate branch, with fine-grained commits. First level 1-4 for earth/moon/mars, as you can see here: https://bitbucket.org/face/orbiter/commits/all . Also DVCS is not immutable history, anyway (remember I'm not using SVN).

Then for each planet another branch with levels 5-7 (30MB), 8 (71MB), 9 (255MB), followed by the few high-res tiles I was interested in for each gbody (Alps for Earth, Valles Marineris for Mars, Taurus Littrow for Moon). I obviously did not push that to Bitbucket, but given an appropriate host, I could upload such blocks with no problem (in fact I'm hosting it at my private server). Interested users could then selectively clone/pull only up to the desired resolution for the given planet(s). This is making them optional. Just a similar setup to what described here. Old story...

The repo itself does not take up more space than the necessary ZIPs BTW, in fact it is less (although not by much).

That said, I find nothing wrong with distributing it the way it is now, just wanted to note that it is no problem for the-words-I'm-using-too-much , because Martin obviously took the standard textures out of the SVN repo due to distribution worries.

 

[Xyon]

I understand mercurial likes to keep history immutable, though I know you can screw repositories up strip changesets...

 

[meson800]

Thanks for this awesome beta, martins!

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

I highly recommend going to the Grand Canyon and blasting through the valleys there :thumbup:

You get a completely different experience than normal Orbiter when trying to maneuver through there at 300m/s :lol:

 

[Face]

I understand mercurial likes to keep history immutable, though I know you can screw repositories up strip changesets...

Like every other VCS, Mercurial first wants to preserve history. Like every other DVCS, though, Mercurial offers functionality to let you create new commits that re-write history, and throw away old commits in your local repository. The same is true for e.g. Git and Bazaar. Not so much for SVN, of course.

Anyway, I guess this is becoming off-topic, so here is another beta-testing comment:
While flying around Olympus Mons and Valles Marineris, I observed slow terrain building, especially regarding the large mountain and the far view along the Valles canyon, respectively. Much in contrast to e.g. the Alps on Earth, it constantly showed rendering artifacts like holes or missing tiles. Are there separate settings for rendering speed of tiles for each planet, perhaps?

 

[Kyle]

Despite the bugs, as expected for a beta, this is absolutely breathtaking. In particular, having a shuttle land at Edwards is stunning.

 

[martins]

While flying around Olympus Mons and Valles Marineris, I observed slow terrain building, especially regarding the large mountain and the far view along the Valles canyon, respectively. Much in contrast to e.g. the Alps on Earth, it constantly showed rendering artifacts like holes or missing tiles. Are there separate settings for rendering speed of tiles for each planet, perhaps?

No, they all use the same engine, and share the same tile loader, running on a separate thread. There is a global load frequency setting you could play around with under Extra | Visualisation parameters | Planet rendering options, but if it works for Earth, it's not obvious why it wouldn't work for Mars.

Did you download the complete high-resolution set, or just certain areas? Do the artefacts disappear once the scene has settled, or do they persist? Does the camera zoom factor make a difference?

 

[n122vu]

Just wanted to note, the Orbiter Beta link on orbithangar.com now gives a 404.

Carry on.

 

[blixel]

I'm just wondering if this is the normal behavior for the moon textures at the moment?

This is with the HiRes textures. I have md5sum-checked all my files to make sure they were not corrupted during download. This is orbiter.exe (the inline client that comes with the 2014 beta.)

My relevant specs:

• Intel Core i7-4770K Haswell 3.5GHz CPU
• ASUS B85-Plus Motherboard
• Corsair Vengeance 16GB RAM DDR3 1600MHz 240 pin
• MSI Radeon R7870-2GD5T (Driver: (newest) - 13.35.1005-140223a-168456E)
• 2x ASUS VN247H-P 24" LCD's

 

[Kyle]

No, they all use the same engine, and share the same tile loader, running on a separate thread. There is a global load frequency setting you could play around with under Extra | Visualisation parameters | Planet rendering options, but if it works for Earth, it's not obvious why it wouldn't work for Mars.

Did you download the complete high-resolution set, or just certain areas? Do the artefacts disappear once the scene has settled, or do they persist? Does the camera zoom factor make a difference?

I think getting the same issue as well and I downloaded the whole package for the Moon. They do not go away once the scene has settled and camera zoom doesn't make much of a difference.

 

[meson800]

No, they all use the same engine, and share the same tile loader, running on a separate thread. There is a global load frequency setting you could play around with under Extra | Visualisation parameters | Planet rendering options, but if it works for Earth, it's not obvious why it wouldn't work for Mars.

Did you download the complete high-resolution set, or just certain areas? Do the artefacts disappear once the scene has settled, or do they persist? Does the camera zoom factor make a difference?

I also have the artifacts described above, it seems like they occur at the edge, where the last terrain mesh-tile merges with the flat planet surface that loads far away from the camera.

On my computer, turning "Tile Resolution Bias" all the way to quality seems to extend the range where the mesh tiles are generated, eliminating most of the artifacts, but some can still be seen at some camera angles.