New Orbiter SVN commit (r.71, Oct 14 2017)

[martins]

Wait, we have an Orbiter Beta 2017 already? That was fast.

No. We have a beta that was committed in 2017. Subtle semantics, but big difference. In fact, it shouldn't really be called a beta. Just call it a commit.

 

[GLS]

The second one is a bit more intricate. The elevation grid Orbiter uses for computing vessel elevations, shadow normals, etc. is not necessarily the same as used for rendering the surface. For example, at high altitude, Orbiter doesn't use the highest available resolution tiles for computing altitudes, because that would require loading a new tile at each frame for each vessel. Even at low altitudes, the tile resolution may be capped to avoid too many reloads. However, this may require more fine-tuning. The question has come up before, and it's on my to-do list.

OK, so what we see and what the vessel "fells" might be 2 different surface resolutions, right? So if it's a feature and not a bug, for me to do a terrain elevation edit, and avoid that feature, I'd have to (somehow) propagate that edit up to the root tile, correct?

---------- Post added at 11:48 PM ---------- Previous post was at 11:40 PM ----------

(The thread about help files made me remember this one) I noticed that in the Extra > Debugging Options window the help button does nothing.

Not related to that, when those option windows are open, Orbiter disapears from the Alt-Tab menu, except for the Vessel Configuration windows. Using W7.

 

[martins]

OK, so what we see and what the vessel "fells" might be 2 different surface resolutions, right? So if it's a feature and not a bug, for me to do a terrain elevation edit, and avoid that feature, I'd have to (somehow) propagate that edit up to the root tile, correct?

Well, it's kind of a bug, but one I haven't yet managed to avoid without loss of performance. But yes, all elevation edits done on high-resolution tiles should always be propagated down to the root, or at least as far as they make a difference, otherwise you'll get errors in both visuals and elevation computations. Tileedit propagates changes down automatically, but other tools may require doing it manually.

 

[DaveS]

Any progress patching these bugs?

Click area notification failing?

RMS End Effector attachment point deviation

Cloud microtextures are not working in Orbiter 2016

 

[GLS]

Sub-atomic issue: the texture list in the Base.cfg file has a Cape21 entry, but no such texture exists.

 

[GLS]

There appears to be a time offset in relation to the scenario save and load. When loading the scenario seems to start with the seconds of the (UTC) display clock in x.0, even if I save the scenario when the seconds were x.5 or someting else (via 0.1x time accel). :uhh:
Between the save and a paused load, the MJD advances 0.01s (and that matches the dt of first timestep call), so the issue doesn't seem to be MJD precision. :shrug:

---------- Post added at 11:38 PM ---------- Previous post was at 08:42 PM ----------

I can't see the Apollo landing site labels when I have "cache first, then archive" option selected. With "archive only" it all shows up.

 

[kuddel]

I can't see the Apollo landing site labels when I have "cache first, then archive" option selected. With "archive only" it all shows up.

Shouldn't that be fixed by revision 69?

Revision: 69
Author: martins
Date: 2017-09-01 03:15:09
Message:
Bug fix: new style surface labels would not render when quadtree policy was set to cache+archive
New style surface labels: font size adapted to distance and level
----
Modified : /Modules/Server/orbiter.exe
Modified : /Orbiter_ng.exe
Modified : /Orbitersdk/lib/Orbitersdk.lib
Modified : /Orbitersdk/lib/orbiter.lib
Modified : /orbiter.exe

At least it works for me

 

[GLS]

Shouldn't that be fixed by revision 69?

Revision: 69
Author: martins
Date: 2017-09-01 03:15:09
Message:
Bug fix: new style surface labels would not render when quadtree policy was set to cache+archive
New style surface labels: font size adapted to distance and level
----
Modified : /Modules/Server/orbiter.exe
Modified : /Orbiter_ng.exe
Modified : /Orbitersdk/lib/Orbitersdk.lib
Modified : /Orbitersdk/lib/orbiter.lib
Modified : /orbiter.exe

At least it works for me

Yes, labels show up, but the landing sites don't (and maybe others). :shrug:

 

[kuddel]

I'm pretty sure you've got the according Label.tree files, right?

 

[GLS]

I'm pretty sure you've got the according Label.tree files, right?

Yes, I have all three trees (say that 3x faster :rofl. They show up correctly in D3D9, so I'd say it's a MOGE issue.

 

[kuddel]

"multi name" locations in Label.tree

Hey Martin,

what is your data-source for the Label-Trees? I am asking because it seems that there are several places (geo-locations) that share multiple names.

For example the Tile "Earth\Label\12\000112\000429.lab" alone contains 62(!) city-names ('C') for the location [10.65000, 122.23333]:

C	10.65	122.23333		Valencia
C	10.65	122.23333		Uayang
C	10.65	122.23333		Tugura-ao
C	10.65	122.23333		Tigmalapad
C	10.65	122.23333		Tigbagacay
C	10.65	122.23333		Tig-apog-apog
C	10.65	122.23333		Tig-amaga
C	10.65	122.23333		Ticdalan
C	10.65	122.23333		Tatoy
C	10.65	122.23333		Saring
C	10.65	122.23333		Sapa-Miagao
C	10.65	122.23333		San Fernando
C	10.65	122.23333		Quirayan Sur
C	10.65	122.23333		Quirayan Norte
C	10.65	122.23333		Pungtud Naulid
C	10.65	122.23333		Pungtud Ilaya
C	10.65	122.23333		Pudpud
C	10.65	122.23333		Potrido
C	10.65	122.23333		Oya-oy
C	10.65	122.23333		Onop
C	10.65	122.23333		Nasonogan
C	10.65	122.23333		Narorogan
C	10.65	122.23333		Nam-o Ubus
C	10.65	122.23333		Nam-o Tacas
C	10.65	122.23333		Naclub
C	10.65	122.23333		Maringian
C	10.65	122.23333		Maninila
C	10.65	122.23333		Mambatad
C	10.65	122.23333		Madoyo
C	10.65	122.23333		Lumangan
C	10.65	122.23333		Lanutan
C	10.65	122.23333		Ipuro Barire
C	10.65	122.23333		Indag-an
C	10.65	122.23333		Ilog-ilog
C	10.65	122.23333		Igsoligue
C	10.65	122.23333		Igpuro
C	10.65	122.23333		Igpangdan
C	10.65	122.23333		Igpajo
C	10.65	122.23333		Igdulaca
C	10.65	122.23333		Igdalaquit
C	10.65	122.23333		Igcatambor
C	10.65	122.23333		Igbugo
C	10.65	122.23333		Igbita
C	10.65	122.23333		Guibuñgan
C	10.65	122.23333		Gines
C	10.65	122.23333		Frantilla
C	10.65	122.23333		Dingle
C	10.65	122.23333		Diday
C	10.65	122.23333		Dalite
C	10.65	122.23333		Calagtañgan
C	10.65	122.23333		Caitib
C	10.65	122.23333		Cadoldolan
C	10.65	122.23333		Cabangcalan
C	10.65	122.23333		Cabang
C	10.65	122.23333		Cabala-unan
C	10.65	122.23333		Bugtong Lamangan
C	10.65	122.23333		Buenavista
C	10.65	122.23333		Bolocaue
C	10.65	122.23333		Belen
C	10.65	122.23333		Bagumbayan
C	10.65	122.23333		Bacauan
C	10.65	122.23333		Aguiauan

Same location with different types should be no problem, but how to handle these cases?

BTW: There are many more "multi name" locations in the Label.tree, some of them could be verified by "humans who know", but for others we might not have that expertise...

 

[martins]

Hi Kuddel,

I'll dig the sources out for you tonight. I guess the problem is the insufficient position resolution. I *think* that this limitation is present in the sources and not artificially introduced by my processing, but I'll double check to be sure.

I had the same problem with planetary labels from the IAU (https://planetarynames.wr.usgs.gov/) where things like Apollo-astronaut named features are too close together for their provided position resolution and are all lumped into a single point.

If I can't find a solution for this, I could simply try to select a single label for any multi-assigned locations. For cities with population data I could use the most populous candidate, but for most of the small places, probably no population data will be available, so it will be a random choice.

 

[Face]

If I can't find a solution for this, I could simply try to select a single label for any multi-assigned locations.

What about rendering all single-point labels (of the current resolution) stacked around the point? Would it be too much overhead to scan the remaining text file for position duplicates? If so, would it help to change the format (together with the processing chain) so that single-point labels need to be defined sequentially?

 

[martins]

Yes, that could be a possibility. Although to accommodate 62 identically positioned labels you may have to scatter them pretty widely.

Alternatively, up to 4 identically placed labels could be accommodated without scattering, by just allowing for top/bottom left/right alignment of the labels relative to the marker. (which means the label renderer has to remember which positions are already occupied).

 

[kuddel]

My analysis of the "multi-lables" showed a huge number of those, the "62 example" was only the worst case.

For several places two labels are very well (and correct) as they represent a local name and its english name e.g.
Due to the fact that this forum can't show Korean characters, I've attached the query-result.

Those "multi-labels" are O.K. and should be rendered both (as two lines)

 

[kuddel]

For the record, here's a partial view of the "top 25" places
...their counts, and where to find them

 

[kuddel]

...AND....for the statistics lovers

[U][B]Grouped by lat, lng, lvl & type:[/B][/U]

76779 times  2 equal positions
11222 times  3 equal positions
 3186 times  4 equal positions
 1189 times  5 equal positions
  579 times  6 equal positions
  290 times  7 equal positions
  171 times  8 equal positions
  138 times  9 equal positions
   91 times 10 equal positions
   51 times 11 equal positions
   44 times 12 equal positions
   26 times 13 equal positions
   23 times 14 equal positions
   21 times 15 equal positions
   11 times 16 equal positions
   11 times 17 equal positions
    8 times 18 equal positions
    7 times 19 equal positions
    6 times 20 equal positions
   10 times 21 equal positions
    7 times 22 equal positions
    5 times 23 equal positions
    3 times 24 equal positions
    3 times 25 equal positions
    4 times 26 equal positions
    1 times 27 equal positions
    3 times 28 equal positions
    2 times 30 equal positions
    1 times 31 equal positions
    2 times 32 equal positions
    1 times 36 equal positions
    1 times 42 equal positions
    1 times 46 equal positions
    1 times 55 equal positions
    1 times 62 equal positions


[U][B]Grouped by lat, lng & lvl:[/B][/U]

82913 times  2 equal positions
13140 times  3 equal positions
 3861 times  4 equal positions
 1579 times  5 equal positions
  755 times  6 equal positions
  373 times  7 equal positions
  234 times  8 equal positions
  154 times  9 equal positions
  114 times 10 equal positions
   70 times 11 equal positions
   54 times 12 equal positions
   32 times 13 equal positions
   30 times 14 equal positions
   20 times 15 equal positions
   13 times 16 equal positions
   12 times 17 equal positions
    7 times 18 equal positions
    8 times 19 equal positions
    7 times 20 equal positions
   11 times 21 equal positions
    8 times 22 equal positions
    5 times 23 equal positions
    2 times 24 equal positions
    3 times 25 equal positions
    5 times 26 equal positions
    4 times 28 equal positions
    2 times 30 equal positions
    1 times 31 equal positions
    2 times 32 equal positions
    1 times 36 equal positions
    1 times 42 equal positions
    1 times 46 equal positions
    1 times 55 equal positions
    1 times 62 equal positions


[U][B]Grouped by lat & lng:[/B][/U]

94691 times  2 equal positions
16773 times  3 equal positions
 5266 times  4 equal positions
 2194 times  5 equal positions
 1017 times  6 equal positions
  517 times  7 equal positions
  300 times  8 equal positions
  182 times  9 equal positions
  141 times 10 equal positions
   91 times 11 equal positions
   57 times 12 equal positions
   40 times 13 equal positions
   30 times 14 equal positions
   28 times 15 equal positions
   15 times 16 equal positions
    6 times 17 equal positions
   13 times 18 equal positions
    9 times 19 equal positions
    7 times 20 equal positions
    6 times 21 equal positions
   11 times 22 equal positions
    8 times 23 equal positions
    1 times 24 equal positions
    5 times 25 equal positions
    3 times 26 equal positions
    1 times 27 equal positions
    3 times 28 equal positions
    2 times 29 equal positions
    3 times 31 equal positions
    1 times 32 equal positions
    1 times 33 equal positions
    1 times 36 equal positions
    1 times 38 equal positions
    1 times 43 equal positions
    1 times 47 equal positions
    1 times 55 equal positions
    1 times 62 equal positions

 

[martins]

Ok, so my source for the Earth labels (except the airport labels) is this:

http://download.geonames.org/export/dump/

The file I was using is allCountries.zip, from which I extracted everything with a 'P' (city), 'T' (mountain), 'H' (lake/river) and 'V' (forest) feature class.

 

[kuddel]

Ok, so my source for the Earth labels (except the airport labels) is this:http://download.geonames.org/export/dump/

I suspected this as source already.
Unfortunately there are some features -that I definitely know- are plain wrong,
others have many alternative names with no specific order, so selecting the "best two" on those would be kind of random...

As I already have the current Earth.tree as SQLite database, I tried some "clever" selection-algorithm on those massive alternatives:

1. Take the name with "most non-ANSI characters" as the first choice (longest local name; possibly having more information than a "shorter" one)
2. If (1) results in several equal elements, select the first in alphabetical order as first choice (arbitrary,... I know)
3. Take the name with the "most ANSI characters" as the second choice (longest "international" name; possibly having more information than a "shorter" one)
4. If (3) results in several equal elements, select the first in alphabetical order as second choice (arbitrary,... I know)

As this is just a dumb algorithm, the quality of rejection/acceptance of names is kind of questionable though

The example from my post however has so many so different names, that the algorithm will most likely select the wrong two :lol:

 

[GLS]

Question: are the particle streams supposed to be rendered (i.e. affect performance) even when they are not visible? I noticed I'm getting the "normal" FPS drop when they are rendered even when I zoomed out to several billion AUs. :uhh: