FSX Scenery-Objects

[Walter_W]

Ich versuche mich etwas über das Scenery Erstellen schlau zu machen. Dabei habe ich festgestellt, dass in einer Scenery-Bgl mehrere Objekte oder auch lediglich ein Einzelnes enthalten sein können.

Was sind die Gründe für diese unterschiedlichen Möglichkeiten?

Der Workflow zur Erstellung ist mir klar, jedoch nicht die Vor-/Nachteile der beiden Möglichkeiten.

 

Gruss Walter

[opabst]

Mit welchen SDK beschäftigst Du dich denn, da gibt's ja durchaus Unterschiede?

[Walter_W]

Oliver,

mit dem Original MS SDK Environment Kit, bzw. dem Library Creater XML von Arno Gerretsen.

 

Gruss Walter

[rolfuwe]

Einzelobjekte aus AddonScenerien oder Bibliotheken können auch als Einzelobjekte in andere Scenerien übernommen werden. Die Objekte einer Scenery kann man dann einzeln positionieren u. skalieren.

Wenn ich mir einen Luftwaffenstützpunkt basteln will u. mir z.B. die Shelter aus der Scenery Jüterbog gefallen, kann ich die gleich z.B. in Holzdorf einsetzen. Jüterbog ist dann meine Bibliothek u. ich "klaue" mir die Schelter.

 

Man kann natürlich auch einen Flugplatz als ein komplettes Gmax-Model erstellen, aber dann kann ich davon einzelne Gebäude nicht an anderer Stelle nutzen u. nachträglich als User ohne Quelldateien u. Gmax nichts ändern.

Es hat alles Vor- u. Nachteile, aber ich als unzufriedener User, bevorzuge die Einzelobjekte, weil ich damit mal schnell etwas für den Eigenbedarf zusammenstellen kann.

Optimal sind Airport-Addons aus:

AFD.BGL, der Flugplatz, mit RWY, Taxiway, Abstellplätze, usw.

CVX.BGL, Ground, Flatten, LC-Polygone

Object:bgl, Gebäude, alles was so herum steht.

Damit kann der User ohne Probleme herumbasteln. Die CVX hat man evtl. schnell selber gemacht.

[opabst]

Oliver,

mit dem Original MS SDK Environment Kit, bzw. dem Library Creater XML von Arno Gerretsen.

 

Gruss Walter

 

Ok, wir sprechen also von BGLCOMP bassierten BGL's, nicht BGLC basierten.

BGLCOMP (also XML Sources) können ja verschiedene Typen von Daten enthalten und BGLCOMP kompiliert daraus dann die BGL Datei:

- Library-Objects (Modeldata) die alle Darstellungsinfos eines 3D-Objektes enthalten (als die MDL Datei, die man zuvor mittels xtoMDL erzeugt hat

- Scenery-Objekts, die die Library Objekte an eine Stelle platzieren

- Airport-Facility-Data, im Folksmund auch AFCAD/AFX genannt, beschreibt halt das Layout des Airports (Runways, Taxiway, Gates etc)

- Globale Nav-Daten, wie VORs, NDBs und Waypoints

 

All dies kann mittels XML-Tags in der Source definiert werden und wird dann ins BGL Format gespeichert.

 

Theoretisch kann man also alle 3D und Layoutdaten eines Airport mit einer BGL Datei abdecken oder für jeden einzelnen Teil eine eigene XML und somit BGL Datei erstellen.

Einen technischen Vor- oder Nachteil hat beides nicht wirklich, ausser dass bei einer Datei der FS nicht 100erte Files von der Platte lesen muss, nur wird das keinen spürbaren Zeitvorteil ergeben.

 

Die Vor-/Nachteile liegen also eher im organisatorischen Bereich, also zum Beispiel beim Handling im Designprozess, Betatest oder beim späteren Updaten.

Wenn ich hier immer extrem große Files austauschen muss, nur weil ein paar KB korrigiert werden, macht das wenig Sinn.

Es ist daher sinnvoller, das Projekt und seine BGL's nach Funktionen aufzuteilen, also

- Airport-Facility-Data, was sich schon automatisch ergibt, da man die mit Tools bearbeitet und hier ggf. Scenery Objekte garnicht gehändelt werden.

- Library Objekte, diese ggf. nach Art der Objekte sortiert oder Areas am Airport

- Scenery Placement, hier ggf. gruppiert nach Detailtiefe (Gebäude und Kleinkram getrennt), so kann man ggf. einzelne Files deaktivieren, wenn mal eng wird mit der Ablaufgeschwindigkeit.

 

So hat man nachher eine überschaubare Fileanzahl, macht es einfach im Handling.

 

Bei der Frage, wie man Modeldaten designed, also was man alles in eine MDL per Designprogramm reinpackt oder ob man jedes Gebäude/Objekt einzeln stellt, da muss man etwas Erfahrung sammeln. Eins ist aber klar, wenn man jede Objekt einzeln als MDL exportiert und platziert, dann freut sich zwar der Rolf-Uwe, weil er das Objekt "klauen" kann, nur die Performance der Scenery wird dabei dann definitiv auf der Strecke bleiben ;)

[Walter_W]

Ahaaaa, sooo ist das.

Dankeschön an RolfUwe und Oliver.

 

Eine Ergänzungsfrage noch:

Wenn ich an einem Flugplatz XXX eine Scenerie erstelle, packe ich eher alle MDL Objekte in diese eine Library BGL.

Sollte ich aber aus dieser BGL nur ein einziges Objekt im anderen Flugplatz YYY benötigen, so erstelle ich zweckmässiger eine einzelne BGL von diesem einzelnen Objekt, statt die Paket-BGL auch in diese Scenery zu übernehmen. Ist dies so?

 

Gruss Walter

 

PS: Nein klauen tue ich nicht, selber machen macht mehr Spass

[opabst]

Wenn Du "globale" Libraries machen willst, dann sollten die LIB BGL's und alle von ihr verwendeten Texturen in einem eignen Scenery/Texture Ordner liegen und gesondert in der Scenerylibrary angemeldet sein. Damit kann man diese Objekte dann aus verschieden Airportprojekten via Scenery-Objekt Placement BGL nutzen.

 

Aber, wenn Du deine Projekte rausgeben willst (Freeware oder Payware), dann solltest Du überlegen, ob es nicht sinnvoll ist, alle Objekte eines Projektes auch in dessen Verzeichnis zu belassen und mit einigenen GUID's unabhängig zu halten.

Das macht das spätere Handling einfacher, da Du sonst ja immer sicherstellen musst, das die Libraries immer auf dem letzten Stand beim User sind. Mit einem Installer kann man das ggf. sicherstellen, dass er neue Files nicht überschreibt, aber mit einfachen ZIP Files ist das blöd. Und man weiß ja nie, in welcher Reihenfolge der User die Scenerien installiert. Und für jedes Objekt eine eigene BGL zu machen, wird dann ggf. auch etwas viel Zeug, irgendwann macht der FS dann auch dicke Backen bei der großen Anzahl von Files die so entstehen könnten.

 

Der Vorteil global genutzter Lib's ist auch nur der Speicherplatz auf er Platte, auf den Memoryverbrauch der Scenery hat's ja keinen Einfluss, da eh meist nur ein Airport im Speicher ist, sofern sie nicht dicht beieinander liegen.

 

Ein weiterer Vorteil von Airportbezogenen Lib ist auch, dass man ggf. einfach mal eine Texture "lokal" anpassen kann, das 3D Objekt selbst aber gleich bleibt. In einer zentralen LIB wird ja nur eine Texture für alle Airports möglich.

 

Hat halt alles gute und schlechte Seiten.