Was zur Megascenery
 

Der Text soll nur zur Info sein. Zweifelsohne die Scenery mag ein Sahnestückchen sein. Marc schrieb in seinem Bericht das bei dieser Fotoscenery sehr schön Defaultairports passgenau mit der Fotoscenery harmonieren und das dies auf die Qualität der Scenery zurückzuführen ist.

Ich denke es dürfte eher Zufall sein, das es passt. Denn wir wissen ja das MS im Ausland siehe Position Straßen, Seen usw. gerne schlampt. Denn bei Real Germany sehen wir oder können es gar anhand topografischen Materal nachmessen das diese Scenery 100Tig positioniert ist. Dennoch sehen wir hier Abweichungen zwischen Fotoairport und programierten FS und ADDON Airports. Fehlerquelle hier die programmierten MS Airports bzw. ADDONS, da sich natürlich Designteams gern an den Positionen der Defaultairports orientieren. Was ja jetzt bei unserem AFCAD Problem im FS2004 sogar starke Vorteile bringen würde. Sollte MS in den Staaten genauso geschlammpt haben, hätte das Megasceneryteam künstlich Ihre Texturen verfälschen müssen, was schnell ginge aber aus meiner Sicht eher unwahrscheinlich ist. (Kann man natürlich nicht ausschliessen, ich denke aber eher nicht das sie dieses gemacht haben)

Zum Thema Autogen. Wir hatten damals bei Real Germany mal die Diskussion ob man bei einer großflächigen Fotoscenery Autogen realisieren kann. Ich habe damals gesagt mit bisherigen Mitteln die uns zur Verfügung stehen eindeutig nein. Denn hier müßte jede Fototextur mit dem SDK Tool Attonator geöffnet werden und dann an die entsprechenden Positionen wo Häuser stehen diese manuel positioniert werden. Bei Bäumen ähnlich. Da kann für eine stark bebaute Textur schon mal mehr als eine Stunde bei drauf gehen. Bei Waldtexturen eher kein Problem, da man da recht willkürlich arbeiten kann. Bei zehntausenden von Texturen einer Fotoscenery ist so was natürlich nicht möglich. Es sei denn man hätte ein Bildanalysetool welches 100tig arbeiten würde. Zusätzlich den Autogencode komplett geknackt und könnte anhand der Bildanalyse diese ganzen Vorgänge automatisch laufen lassen. Nun wenn man sich alle Verfügbaren Screens der Megascenery anschaut sieht man das hier nicht dieser Weg gegangen wurde. Es wurden verschiedene Footprints erstellt. Diese haben aber nichts mit der jeweiligen Textur direkt zu tun. Man weist diese Autogentexturen immer wieder den Fototexturen zu. z.B Gebäudefootprints bei Texturen die Gebäude enthalten. Natürlich alles nicht passgerecht. Fällt aber nicht so stark auf da große Ballungsgebiete dankbar sind bei so einer Realiserung. Das selbe bei Wald.(Ich schliesse nicht aus das man bei markanten Gebäuden in Fototexturen auch mal genau anhand der Textur gearbeitet hat) Mit dieser Technik bekommt man zwar Autogen aber eben nicht auf dem Niveau von dem wir damals geredet haben. So was wäre zwar auch für Real Germany möglich. Nur bei unseren Verhältnissen mit vielen kleinen Dörfern eben auch in dieser Variante wesentlich aufwendiger als bei der Megascenery. Bei kleinen Dörfern fällt es auch viel stärker auf wenn hier Gebäude falls stehen. Übrigends auch der Grund warum Marc da Autogen hatte wo keines sein sollte. Wenn man nämlich an Stadtgrenzen bzw. Übergängen zu anderer Topografie nicht aufpasst fallen auch bei dieser einfachen Technik Fehler auf. (Bei ihm Autogenobjekte vor oder auf Startbahnen) Mich wundert es daher nicht das die Megascenery Macher selbst empfehlen Autogen zu deaktivieren. Klar bringt natürlich ohne Autogen zusätzliche Performance.

Wie gesagt alles nur zur Information. Passgenaues Autogen ist und bleibt bei einer Fotoscenery nahezu unmöglich für Deutschland/Europa.

wozu autogen?
Durch die Fototexturen und v.a. die wahnsinnig hohe Mesh-Auflösung
ist jeder noch so kleine Hügel ausgebildet - und das wirkt so plas-
tisch, so dass man getrost auf autogen verzichten kann

zum Thema Airports in der Megascenery:
hier wurden keine Texturen verfälscht oder verschoben, denn es gibt
speziell kleinere Airports, die schon mal mit der Landebahn in einen
Highway "stechen" - aber was solls, es ist trotzdem ein Quantensprung

das einzige, was wohl teilweise gemacht werden musste, ist dass auch
v.a. kleinere Airports auf "Fundamente" gesetzt wurden, d.h. das Mesh
hier an die Default Airports angepasst wurde, sonst würden die wohl
in der Luft schweben-wahrscheinlich gibt es noch keine Möglichkeit,
die Airport-Lage (Höhe) zu ändern

Wozu Autogen?

Darüber hatten wir schon mehrfach Diskussionen. Der eine legt auch bei einer Fotoscenery Wert darauf der andere nicht. Das gleiche gilt für landebare Wasserflächen der eine hätte sie gern bei einer Fotoscenery der andere braucht sie nicht. Das selbe für Jahreszeiten bzw. Nachtetxturen. Nur wenn es schon mal da ist, denke ich ist es ein Pluspunkt. Da könnte der ein oder andere gleich sagen. Warum kaufe ich den FS wenn es da bessere Simulationsmöglichkeiten gibt die aber keinerlei Scenery bieten.

Wer braucht schon Traffic usw. Wer braucht Airportgebäude usw . für eine Simulation. Das wäre ein endloses Thema und ist halt Geschmackssache.

Nein die Airports wurden nicht auf Fundamente gesetzt. Airports haben aufgrund der Technik nur eine feste waagerechte flache Oberfläche wie eine Glasscheibe mit einer festen Höhe die beim programmieren vorgegeben wurde. In der Realität hat natürlich auch ein Airport Steigungen und Unebenheiten. Dieses ist bisher nicht darstellbar im FS. Es sei denn man verzichtet auf diverse Techniken beim Airport was wir natürlich nicht wollen. Das Mesh hat wenn es sehr gut programmiert ist natürlich reale Höhen. Es trifft dann leider auf diese flache Oberfläche des Airports mit eigener Höhenangabe. Das ist der Grund warum hier Podestähnliche Effekte auftreten bzw. diese Airportfläche in einer Senke verschwinden kann. Das Mesh zieht sich nämlich im Randbereich an diesen Flattenflächen hoch oder runter. Ist die Abweichung zwischen Flattenhöhe und Mesh sehr stark fällt es natürlich auch stark auf. Das original Mesh des FS hat nur eine geringe Auflösung es gibt nur weiche Rundungen in der Oberfläche ergo fallen hier kaum solche Effekte auf.

Hallo Joachim,

wieder mal ein interessanter Beitrag von Dir. Ich gebe Dir recht, die Diskussion über Foto- oder Autogen oder Kombinationen von beidem ist in diesem Forum weitgehend erschöpfend behandelt. Ist im Endeffekt in der Tat Ansichtssache, was man als Simmer bevorzugt.

Zu den Plätzen und deren Positionierung. Da ist mir jetzt im Rahmen eines Updates aufgefallen, daß zum Beispiel am Platz Konstanz (EDTZ) der Platz im 2004 gut 1000m nach Süden " verlegt" wurde. Frag mich nicht warum, real ist dort nichts geändert worden. Mich würde mal interessieren, ob andere Simmer solches auch feststellen konnten.

Gruß
Rolf

Gehört zwar nicht zu diesem Thema, aber gibt es eine elegante und einfache Möglichkeit sämtliche Referenzpunkte der Objekte einer bgl Datei um ca. z:B 50 m südlich zu verschieben?
Horst

Irgenwer hatte da mal ein Tool geschrieben, war es nicht sogar Falko Dienstbach. Weis es nicht mehr ganz genau. leider reicht dieses in den meisten Fällen nicht. In der Regel muß nämlich oft die ganze Scenery etwas gedreht werden, das ging mit dem Tool nicht soweit ich mich erinnern konnte. Als nächstes bleibt bei den Großairports, das die Taxiways/Runways oft nicht die Breite der Fotoscenery haben und schon sieht man wieder was. Ich persönlich würde die Lösung den Airport aus der Fotoscenery zu eleminieren bzw. rauszuarbeiten vaforisieren. Hiermit könnte man optisch die besten Ergebnisse erreichen. Zusätzlich löscht man noch Rasenpolys alter Technik durch Bearbeitung der BGL oder einfach durch Ersatz der Rasentextur durch eine transparente Tauschtextur. (da diese bekanntlich bei einer Fotoscenery aufgrund Ihres Layers vorhanden bleiben) neue VTP Rasenpolys verschwinden eh). So würde sich ein Airport optimal in eine Fotoscenery einbetten lassen. Wer mit einem Fotoprogramm umgehen kann für den ist das ein Kinderspiel. Die betroffenen Texturen die man bearbeiten muß kann man auch schnell ermitteln. Dafür gibt es Tools.

Es war vermutlich das Tool von Falko welches Du meinst. Ich habe nachgeschaut er hatte da mal was programmiert. Es hat aber einen Nachteil es benötigt den SCASM Code. Die Verfügbaren Dekompiler bringen aber zuviele Fehler in die Scenery ein. Ganz speziell wenn neue Taxilinebefehle auf FS2002 Standard verwendet werden.

Außerdem dürfte es bezüglich AFCAD nicht funktionieren. Damit wäre zwar der Airport verschoben der Verkehr aber nicht.

Airports des FS2004 sind damit eh außen vor, sie lassen sich bisher nicht dekompilieren da sie so wie es aussieht eh nichts mit alten Codes am Hut haben. Man munkelt ja das sie über XML programmiert wurden und es einen neuen Kompiler geben wird. Es sei denn Du hast hier ganz was anderes gemeint was ich nicht kenne. Auf jeden Fall denke ich dürfte es beim FS2004 keine Möglichkeiten geben bevor das SDK erschienen ist.

Daher wie gesagt meiner Meinung nach eine optische 100% Anpassung über Manipulation der Einzeltexturen der Fotoscenery. Einfach und gut.
Oder über ein spezielles Rasenpoly welches man an die Fotoscenery anpasst. Vorteil ohne Lizenzprobleme möglich. Nachteil etwas aufwendiger und auf keinen Fall besser.

Eigentlich werke ich an der Anpassung Wien von Loy und ATP und Loys Gebäude stehen alle etwas zu östlich.Wenn ich 85 Objekte in einer bgl habe, ist dies etwas langweilig. Möchte dies jedoch selber machen ohne dem Autor zu bitten. Man lernt halt am meisten dadurch. Daher meine Frage.
Horst

Langsam muß ich mir Gedanken machen. Aus deiner Frage "aber gibt es eine elegante und einfache Möglichkeit sämtliche Referenzpunkte der Objekte einer bgl Datei um ca. z:B 50 m südlich zu verschieben?" habe ich im schnellen lesen eine Antwort gemacht also "aber es gibt eine elegante und einfache Möglichkeit sämtliche Referenzpunkte der Objekte einer bgl Datei um ca. z:B 50 m südlich zu verschieben!"

Mit ander Worten Du kennst eine Lösung. Tja zu schnell von mir gelesen es war definitiv eine Frage von Dir.


Da ich aus einem anderen Thread von Dir interpretiere das Du die nicht unerheblichen Fehler eines Scenerydekompilers offensichtlich akzeptierst. (Ich nicht. Was nützt es mir wenn z.B gelbe Taxiwaybegrenzungen auf Großairports hinterher ca. 1Meter neben dem Taxiway auf dem Rasen liegen, schwankt natürlich je nach BGL. Dann die anderen Fehler die z.B entstehen. Ist aber eine andere Sache.)

Wie gesagt da Du es akzeptierst für deine persönlichen Zwecke, könnte hier das Tool von Falko eine Hilfe sein. Es nennt sich SCMOVE und ist auf seiner Page unter

http://home.t-online.de/home/Falko.D...ch2/DowDiv.htm

zu finden. Da findet man übrigends auch das Tool zur E00 Konvertierung welches in der vorletzten FXP bezüglich italienischer Railwaystrecken erwähnt wurde. Die E00 Dateien sind übrigends kostenpflichtig und meiner Meinung etwas zu grob. Zur Anmerkung. Diese von Sergio sich verjüngenden Linien der Railways die er bei dem ADDON bemängelt hat, kann man mit Kenntnissen des Codes verhindern.

Servus Joachim

- Da ich aus einem anderen Thread von Dir interpretiere das Du die nicht unerheblichen Fehler eines Scenerydekompilers offensichtlich akzeptierst.

Verstehe ich nicht ganz (meinst du Scsam?)

Tue ich nicht, sonst würde ich mich damit nicht beschäftgen, sondern den nächste Update kaufen.

Falco Dienstbachs Programme kenne ich zwar, aber der Link ist sicher für Interessierte gut.


Horst

Nein SCASM meine ich nicht damit, denn SCASM ist ja kein Dekompiler sondern ein Kompiler der aus einem speziellen Textcode SCA die BGL erstellt. Ich beziehe mich auf diesen Text von Dir aus einem aktuellen Thread:

"Ausgangspunkt SDK 2002 derzeit leider noch hier:
http://www.microsoft.com/games/flig...wnloads_sdk.asp
Werkzeug findest du hier:
http://www.scenery.org/design_utilities_a.htm
Dann analysierst du die BGL Datei und stellst sie in Textformat dar. Anschließend löscht du alles was du nicht brauchst und compelierst es wieder in eine BGL Datei. "



Eine BGL Datei dürften die wenigsten mittels FS2000/2002SDK analysieren können und in ein Textformat nämlich hier in den SCASM SCA Code umstellen können. Ergo sprichst du mit dem Werkzeug offensichtlich ein Tool an, welches in der Lage ist eine BGL zu dekompilieren und z.B in den SCA TextCode zu übersetzen. Einen Scenerdekompiler halt. Dann soll der User hier das was er nicht benötigt (insofern er diesen SCASM Textcode SCA interpretieren kann) löschen. Anschließend soll er diesen manipulierten Code jetzt mit dem erwähnten SCASM Kompiler von Manfred in eine neue BGL kompilieren.

Genau das hast Du mit deinem Text beschrieben, bei mir jetzt nur genauer aufgedröselt. Also nutzt Du doch einen bestehenden Scenerydekompiler. Und diese bestehnden haben halt doch größere Fehler die ich nicht akzeptieren würde.

Mit da Du Fehler des Scenerydekompilers akzeptierst meinte ich eben folgendes. Der Programmierer der ein ADDON produziert erledigt dieses in grafischer Form z.B über das SCC (Schiratti Control Center). Beim Kompilieren werden aus grafischen Vektordaten enstrechend dem was man programmiert (Poly, Runway, Strasse usw.) bei der Kompilierung zunächst der nicht ganz leicht verständliche SCASM Texcode SCA erzeugt. Hier bei entstehen zum Teil erste geringfügige Fehler (Rundungen) bei der Vektorumsetzung. Im SCASM Code selbst lässt Manfred Moldenhauer (der Entwickler von SCASM) unter anderem komfortable Dezimalwerte mit Nachkommastelle zu. Wenn dann aber dieser SCASM Textcode SCA in die BGL mittels SCASM kompiliert wird, muß er in einen entsrechenden SDK kompatiblen Code kompiliert werden. Hier sind keine Dezimalreste zulässig. Es werden jetzt Dezimalreste oft in bestimmte Fractionalteilerwerte umgerechnet um in ein bestimmtes Byteschema zu kommen welches wie gesagt die wenigsten User verstehen würden. Eben dieses Byteformat und noch ein paar andere komplizierte Sachen werden in der Regel im Scenery SDK beschrieben mehr nicht. Daher können die wenigsten mit einem SDK etwas anfangen außer in der Regel Programmierer die Designtools programmieren. Es gibt auch ein paar leichter zu verstehende SDKs die dann aber auch nicht diesen Informationsinhalt haben.

So bis hierhin haben wir nun den Weg der Erstellung eines Sceneryaddons beschrieben. In diesem Weg kann ein Scenerydesigner aber schon selbst ein gewisse Fehlerquelle von z.B Rundungsfehlern eingebaut haben. Es sei denn er hat Dezimalreste so geschickt angegeben das es bei der Umsetzung in Fractionalwerten zu möglichst wenigen Fehler gekommen ist.


Jetzt kommst Du mit dem Analysieren ich gehe jetzt davon aus da Du auf Tools verweist, das Du einen Scenerydekompiler meinst der diesen Textcode erstellt. Und eben genau diese bisher verfügbaren Dekompiler arbeiten wieder sehr ungenau sie haben ev. sogar absichtlich starke Fehler beim Dekompilieren drin. Sie setzen z.B Fractionalwerte nicht sauber in Dezimalreste die jetzt z.T 5 stellig sein müssten nicht sauber um. Oder sie dekompilieren generell bei gewissen Information falsch. Und schon hast Du beim Textcode selbst schon starke Fehler drin. Da wurstelst Du jetzt noch drin rum veränderst ev. etwas. So nach getaner Arbeit nimmst Du Dir den bearbeiteten Textcode und kompilierst ihn mit SCASM wieder zu einer BGL und schon hast Du etliche Fehler drin die zunächst vielleicht nicht stören aber doch je nach Sceneryinformation stark negativ auffallen. Das meinte ich mit akzeptieren von deiner Seite denn exakt diesen Vorgang hast Du in deinem Text mit wenigen Worten beschrieben. Da Du dieses akzeptierst und dann den SCA TextCode vorliegen hast könntes Du dann mit SCMOVE die Scenery verschieben offensichtlich aber nicht drehen falls dieses nötig wäre. Wie der Rest abläuft weist Du ja offensichtlich. Ich kann wie gesagt niemanden empfehlen die Fehler eines Scenerydekompilers zu akzeptieren. Man sollte sich dann das SDK anschauen und selbst den Byte Code verstehen lernen um für private Zwecke (nur da ist es zulässig) was zu ändern.

Muss ich dir absolut zustimmen und gebe dir natürlich recht. Man merkt diese Ungenauigkeiten relativ bald und dies ist ja sicherlich nicht Sinn und Zweck von Änderungen und man kann dies ja sehr schön überprüfen.
In seinem Fall dachte ich käme er sehr schnell zu einen Erfolgerlebnis, es handelt sich ja nur um ein Gebäude.
Welchen einfachen Weg würdest du im vorschlagen, um die bgl Datei zu ändern?
Horst

Um die BGL zu ändern. Für jemanden der keine Ahnung vom SDK und der Bytestruktur hat bleibt wohl nur diese Möglichkeit. Nur dann sollte man mindestens ein bischen Ahnung vom SCASM Code haben sonst ist auch das mit dem Dekompiler/Kompiler auch fast sinnlos. Ich habe diese Wienscenery nicht um die es da wohl geht. Gab es da nicht sogar einen Patch für. Ansonsten würde ich da wo es geht transparente Texturen empfehlen. Die lassen sich einfacher erstellen. Die BGL lädt zwar alle Objekte aber man sieht sie nicht. Ist der gleiche Effekt aber einfacher als in lizensierten BGLs rumpfuschen. Man stört damit niemanden ja man könnte die Transparenztexturen sogar weitergeben.

Nachteil wäre nur das sich die Performance nicht verbessert was der Fall wäre wenn man in der BGL Objekte löschen würde. Und natürlich das ein Flugzeug ev. in so ein unsichtbares Objekt crashen könnte wenn man sehr tief durch die Gegend fliegt.


Zu Flieger Horst noch mal Dein Text:
"Durch die Fototexturen und v.a. die wahnsinnig hohe Mesh-Auflösung
ist jeder noch so kleine Hügel ausgebildet - und das wirkt so plas-
tisch, so dass man getrost auf autogen verzichten kann"

Ich habe den LOD Level des Mesh noch nicht ermittelt er wird aber eh nicht höher LOD9 dargestellt, er kann sogar niedriger sein. Er ist also nicht wahnsinnig hoch, sondern wäre dann im üblichen Rahmen von ADDON Mesh Files. Der LOD Level scheint aber bei den Einzelteilen der Megascenery nicht überall gleich hoch zu sein. Auch habe ich mehrere Stellen gesehen wo man eindeutig Schattenwürfe in der Fototextur entdecken kann, hier müßte also ein hügelieges, zerklüftetes Gelände existieren. Tut es aber nicht es ist nur ein runder Hügel. Aber ansonsten hast Du recht im Gebirge passt Gelände und Schattenwurf sehr gut zusammen das sieht toll aus. Und ich habe aufgepasst ich habe meinen FS wieder so eingestellt das er Mesh überhaupt mit einer hohen Auflösung einstellt.

Denn hier kommt eine weitere Unverschämtheit der Megascenery. Es nimmt bei den Installer langsam überhand. (gut wenn man vorher das Handbuch ganz genau gelesen hätte, hätte man es vorher gewusst, schlecht wer da nicht gut Englisch kann) Denn was machen die hier ohne beim Installer groß drauf hinzuweisen. Es werden die FS9.CFG aller in XP angemeldeten User auf Ihre persönlichen Werte gesetzt um eine möglichst gute Performance im FS zu erzielen und das ohne wenigstens eine Sicherungskopie anzulegen. Das Mesh stellt man gleich auf einen schlechteren Wert ein. Ich denke da hätte man aber schon ein bischen deutlicher vor warnen können und mindestens eine Sicherungskopie anlegen können.

Ansonsten wen es interessiert. Die Megascenery ist meiner Meinung nach nicht auf dem Niveau der Real Germany was Texturen betrifft. Ein Umstand der auf das Rohdatenmaterial von Satelliten zurückzuführen sein dürfte. Wie sie im Vergleich zur Giga Scenery dasteht weis ich nicht da ich die GIGA nicht habe.

Zu den Nachttexturen. Es ist schon toll das es sie überhaupt gibt. Sie sehen auch toll aus. Haben zwar nicht das Niveau der Defaultnachttexturen hinsichtlich Position und Lichtquellen. Straßenoberflächen sind grünlich da wo kein Lichter stehen also Autos fahren würden. Haben aber mehr Farben als die Defaulttexturen und das ist realistischer als bei den DefaultFS Texturen. Die Nachttexturen passen allerdings nicht zu den Tagestexturen, kann man sehen wenn man die Texturüberblendung aktiviert (die sie natürlich auch abschalten) und auf eine Übergangszeit wie Morgengrauen geht. Dann sieht man nämlich das auch da wo große Gebäude stehen auf dem Dach die verschiedensten Lichtquellen unpassend rumstehen und zwar die selben die man sonst auch wo anders außerhalb von Gebäuden findet.

Aber wie gesagt wenn man daruf nicht achtet oder nur bei Tag oder Nacht fliegt bzw. die Texturüberblendung abschaltet sieht das schon toll aus.

Abweichungen bei Airports hinsichtlich Foto und Defaultairports gibt es aber doch einige genauso wie bei RG1.