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

[fred18]

Couldn't you just create a symbolic link for the Earth, Moon and Mars folders inside the Textures folder to a different Orbiter install?

Sure, there are many ways to do it, my consideration was only about the general architecture: I thought it was better to separate planets from vehicles, that's it

 

[martins]

Hopefully not dumb question.

I noticed that surface maps are dxt1 with no alpha map. Instead alpha maps are located in "mask" folder that has nightlights as rgb and mask as alpha. Is that correct and why?

Wouldn't it be better to store alpha map in daylight texture?

Then you would need to store as DXT5, otherwise you lose the colour information of the water areas. This would double the texture sizes, and you would still need the textures for the night lights. The way it's done now (mask riding piggyback on the nightlight textures), you get the masks for free, at the minor cost that you can't have lights in the water areas.

 

[4throck]

The latest update partially solves visual terrain issues at high altitudes. I can now see the terrain although with some transparency issues.
Collision and altitude data on the MFD are as before (terrain non existent).

 

[fort]

Summary: when one leave a scenario to restart it later, if this scenario initially referred, through something as: Help Default \ Checklists \ ... - , to a chm file located in the checklist folder (html / scenarios / default / checklists), that statement is not
longer present at the re-launch, in the current state or quicksave and replaced, in the scenario, by Help CurrentState_img

........................................................................................

Hello,

I finished a small addon for viewing in full screen different types of files: images, pdf, videos (flv)...a timer (countup / countdown) and some other things.

It consists, first, of a chm. (9.chm) located in the checklist folder and referenced in the scenarios as follows:

BEGIN_ENVIRONMENT
..........................................
Help Default\Checklists\9,9
END_ENVIRONMENT

...and serving as a relay ... (parser) to a html file, actual carrier for the code for presentations mentioned above.Overall: a
help file governed by the same principle as checklist1.chm,
checklist2.chm ... called by the button "scenario" in the help window.

I have not seen in the last betas, particularly when was implemented - in current state or quicksave mode - in the
launchpad, an image with the current scenario, that this note: Help Default \ Checklists \ 9.9 disappeared in quicksave
or in the current state in order to be replaced by:

BEGIN_ENVIRONMENT
..........................................
Help CurrentState_img
END_ENVIRONMENT

The initial checklist help online is no longer available.

 

[Swigert]

To summorize my general tastes for the beta, I leave you this Star Trek GIF.

 

[martins]

Orbiter Beta SVN commit #5

Further bug fixes:

• Bug fix: vessel shadows: not rendered at simulation start for idle vessels [ref: http://www.orbiter-forum.com/showthread.php?p=465544&postcount=104]
• Bug fix: surface impact not calculated at elevations > 10km [ref: http://www.orbiter-forum.com/showthread.php?p=466558&postcount=144]

 

[martins]

2. The issue where the cursor disappears if the right mouse button is let up when over another window occurs in the latest beta. The steps to reproduce are the same as described in the link above, but instead of the F4 menu, just move the mouse over any other window.

I can't reproduce this problem anymore, in either fullscreen or window mode. Does anybody else still have this?

 

[meson800]

I can't reproduce this problem anymore, in either fullscreen or window mode. Does anybody else still have this?

I can reproduce in both fullscreen and window mode on revision 5, even after SVN update and copying of Install/orbiter.bin to orbiter.exe

Reproduction steps:

1. In external view, hold down right mouse button and rotate.
2. Alt-tab to an already-open Windows Explorer window, and release the right mouse button.
3. Alt-tab back into Orbiter. The cursor has disappeared

Orbiter.log shows nothing, but here it is:

**** Orbiter.log
Build Apr 29 2014 [v.140429]
Timer precision: 3.31068e-007 sec
Found 0 joystick(s)
Devices enumerated: 6
Devices accepted: 5
[ ] RGB Emulation (SW)
[ ] Direct3D HAL (HW)
[x] Direct3D T&L HAL (HW)
[ ] Direct3D HAL (NVIDIA GeForce GTX 650) (HW)
[x] Direct3D T&L HAL (NVIDIA GeForce GTX 650) (HW)
Module AtlantisConfig.dll .... [Build 140410, API 140412]
Module AtmConfig.dll ......... [Build 140412, API 140412]
Module DGConfigurator.dll .... [Build 140410, API 140412]
Module ScnEditor.dll ......... [Build 140410, API 140412]
--------------------------- WARNING: --------------------------
Scenario watcher thread timed out without returning.
---------------------------------------------------------------

Specs:

• Windows 7 Home Premium
• Intel I-5 Processer
• DirectX 11
• NVIDIA GeForce GTX 650

 

[jroly]

I used to run orbiter from my ssd, but with the larger textures will have to go on hard disk, will this impact rendering?

I never checked before, I only had orbiter on SSD to speed loading times.

 

[jedidia]

I used to run orbiter from my ssd, but with the larger textures will have to go on hard disk, will this impact rendering?

It shouldn't affect rendering, but will definitely affect loading times. I don't know exactly how the LOD is handled, so it might be that the visual terrain will build slower on a slower disk, but it's not neccessarily so.

 

[Phoenix]

I have been looking into generating normal maps from the elevation files and it seems that the header size for these files is 100 bytes, not 76 as stated in surfmgr2.cpp.

Any news on using the better elevation data (not LOLA) for the moon?

 

[martins]

I have been looking into generating normal maps from the elevation files and it seems that the header size for these files is 100 bytes, not 76 as stated in surfmgr2.cpp.

Yes, you are correct. A few more fields have been added since that comment was written. I'll correct it.

Any news on using the better elevation data (not LOLA) for the moon?

Not yet. I've been a bit busy with other things. But I'll look into it soon.

 

[kamaz]

Any news on using the better elevation data (not LOLA) for the moon?

Huh?

LOLA is the best lunar DEM there is... max resolution is 1024 pixels per degree, which translates to 30m per pixel at the equator, and gets better as you go north or south. Although, it seems that for the purposes of Orbiter, it does not make sense to go above 64 pixels per degree -- the lunar terrain is relatively smooth.

I was actually using LRO and Kaguya data to create maps of lunar terrain, so I know what these datasets are capable of. They are nothing short of amazing. In polar areas, I had to do massive data reductions to be able to render the terrain at all.

 

[Phoenix]

Huh?

LOLA is the best lunar DEM there is... max resolution is 1024 pixels per degree, which translates to 30m per pixel at the equator, and gets better as you go north or south. Although, it seems that for the purposes of Orbiter, it does not make sense to go above 64 pixels per degree -- the lunar terrain is relatively smooth.

I was actually using LRO and Kaguya data to create maps of lunar terrain, so I know what these datasets are capable of. They are nothing short of amazing. In polar areas, I had to do massive data reductions to be able to render the terrain at all.

I didn't know there was 1024ppd LOLA data, but I doubt it is really that good.

I have to say that the elevation data derived from Wide Angle Camera (WAC) stereo images is much better than equivalent resolution LOLA data. There are many areas in the LOLA data where the data has been interpolated because there weren't any radar "shots". In Orbiter, I see this interpolation as ugly north to south running artefacts.

When I was doing my own terrain rendering, I had to blur this LOLA data to make it look half decent. That was before I discovered WAC data. Maybe LOLA data has improved since then, but my flights over the moon in Orbiter tells me it hasn't. I immediately recognised the rendering problems as being LOLA created.

I reckon the highest resolution WAC data, which is 100m, would look cleaner and more detailed than 30m resolution LOLA data, especially at the equator where radar shots are spaced out more.

Here are some images showing the problem with LOLA data. The striations you see run North to South and are areas where data has been interpolated:

 

[orb]

clbkVCMouseEvent position bug

There's some bug in reported virtual cockpit mouse event position in the new betas.

Observed in DeltaGlider / DeltaGlider-S VC (in 140429):

• `VECTOR3 p` passed to the DeltaGlider::clbkVCMouseEvent callback contains strange random values, like: p.x = 15077.875701074023, p.y = -2197.6205172770815; p.x = 584944677.82401514, p.y = 77558039.784314543, etc. (and p.z is 0.0):
  
  
  1. side buttons of both MFDs don't function,
  2. elevator trim will be only moved in one direction (either up or down, not depending on where it's pressed in the control area),
  3. throttle can't be set, but only jumps between min. and max. position when the left mouse button is pressed in the control area.

 

[martins]

Orbiter Beta SVN commit #6

More bug fixes:

• Bug fix: exhaust stream particles were stuck at sea level altitude when generated below [ref: http://www.orbiter-forum.com/showthread.php?p=466098&postcount=138]
• Bug fix: mouse click positions misregistered in virtual cockpit mode [ref: http://www.orbiter-forum.com/showthread.php?p=467478&postcount=175]

 

[Marg]

Marg

I have spent more than a week using this amazing new Orbiter BETA.
I did not try any of the betas after 2010 P1, so that was new.
Breathtaking views! Especially in the western part of US, where I installed high res textures. I flew from Edwards AFB to Colorado canyon, then to San Fransisco area, and in many other places, felt addicted to download some other areas - Indian ocean islands etc., also my native Europe.
Moon also amazing... Very impressive, huge leap for the Orbiter! :thumbup:
What I have noticed so far:
Very positive things:
1) no pixels - squares anymore, everything seems to be filtered;
2) particle streams are not rendered beneath the ground (or now it`s elevation) level! And that`s important, it was very annoying to see them rendered below the ground during the launches;
3) no FPS problems on my PC (7 years old - 1 GB RAM, Geforce 700GS, Intel Core 2 Duo);
4) really good looking buttons on the top of the screen.
Minor bug:
1) in camera tab, FoV - slider for degrees 59 and 60 degrees is on the same position...
Observations:
1) I noticed that areas, which are not covered by hires tiles yet, have even lower resolution textures than "normal". Unfortunately Latvia is in there (as well as Finland, most of Sweden), I hope it will not be too far away in queue of procession - just 2 "squares" in north Europe.
2) could it be possible to reference ground camera to local elevation? It does not matter so much on Earth, but on the Moon most of the landing sites are below "0" level, so camera stops going down and I still look to spacecraft from above.
Future:
It`s just for consideration:
1) Just thought it could not be bad to have sun "blinding" effect, not necessarily with lens effect, but just this shiny\blinding feeling;
2) Sorry for shameless thought for the future - as many US missions ended up in the ocean, and water covers ~70% of Earth, what if below, say 500 m, wavy appearance of water could be introduced\activated. Of course, always the same, calm sea\ocean, without anything advanced.
By the way - I tried to install SCA - shuttle carrier aircraft. It flew! But it had understandable compatibility problems on the ground, it behaved like ground is the water easily going upside down upon contact, as it was submerged. I was fun. That`s when I remembered about the water.

I say nothing about the clouds - because I am satisfied, yes, roughly "cirrus" apearance is enough for me.
P.S. Sun glare\glint off the water is a bit flickering, not very much, but some flicker exists.

 

[jroly]

I am getting slow download speeds on the moon & mars texture packs.

I thought someone said they are seeding at gigabit speeds?

 

[Quick_Nick]

I am getting slow download speeds on the moon & mars texture packs.

Are you downloading through the torrent? I'm getting over 400kB/s for the Mars torrent. (suddenly 1.3MB/s as I type this)
I think I'll leave Vuze up when I can over the next week. I've got beefy upload rates to offer.

Also I just read that your edit. Yeah, not quite gigabit but also not crazy slow.

 

[blixel]

I am getting slow download speeds on the moon & mars texture packs.

I just turned my client back on. Should help seed for up to 10Mbit/sec.