Warnung: Use of undefined constant MYSQL_NUM - assumed 'MYSQL_NUM' (this will throw an Error in a future version of PHP) in ..../includes/init.php (Zeile 156)

Warnung: Use of undefined constant MYSQL_ASSOC - assumed 'MYSQL_ASSOC' (this will throw an Error in a future version of PHP) in ..../includes/init.php (Zeile 156)

Warnung: Use of undefined constant MYSQL_BOTH - assumed 'MYSQL_BOTH' (this will throw an Error in a future version of PHP) in ..../includes/init.php (Zeile 156)

Warnung: Use of undefined constant VB_FRAMEWORK - assumed 'VB_FRAMEWORK' (this will throw an Error in a future version of PHP) in ..../includes/functions.php (Zeile 8101)

Warnung: Use of undefined constant archive_postsperpage - assumed 'archive_postsperpage' (this will throw an Error in a future version of PHP) in ..../archive/index.php (Zeile 456)
Helipack 4 von ICARO [Archiv] - X-Plane Schweiz

PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Helipack 4 von ICARO



Dietmar
27.10.2011, 14:54
Hallo Fan's!

In den letzten Ausgaben vom FS-Magazin und von Flight wurden die Helipacks von ICARO für den MSFS besprochen.
Beide Beiträge sind vom selben Autor. Diese Heliplätze auf Krankenhäuser, BUK und BPol wurden als sehr gelungen bewertet. Ebenfalls enthalten sind Heliplätze aus Österreich, Schweiz, Luxemburg, Niederlande und Dänemark.

Ich habe nunmehr versucht, durch Konvertierung diese Szenerie auch für den X-Plane nutzbar zu machen.

Was ist dabei herausgekommen?

Erst einmal ca. 900MB heruntergeladen.
Beim ersten Konvertierungsversuch nach etwa 1 Stunde abgebrochen und überlegt, ob man diese riesige Datenmenge nicht nach Länder bzw. Bundesländer und einer Basisszenerie aufspalten sollte. Aber schnell gemerkt, dass es so nicht geht. Einzelne Szenerieabschnitte greifen auf Libraries zurück, die aber leider als solche nicht gekennzeichnet sind.

Nun also wieder alle Dateien genommen und angefangen zu konvertieren. Mein nicht langsamer PC rödelte nun 7 Stunden und 10 Minuten herum und gebar eine Heliszenerie von sageundschreibe 4,3GB. Diese kollossale Größe kommt überwiegend durch die Texturen zustande.
Die Designer haben für fast alle Gebäudeflächen eine eigene Textur von unfaßbarer Größe gewählt, wobei in fast allen Fällen 256x256 Pixel völlig ausgereicht hätten. Aber sei's drum.

Jetzt geschaut was sich da tut. Also den X-Plane gestartet und Orte angeflogen, wo ich die Position der Heliplätze kenne. Was ich gesehen habe, hat mich gewundert. Die Plätze waren da, auch die Gebäude, Bäume usw. - aber die standen zusammen mit anderen Gebäuden des "global overlays" irgenwie so durchdrungen in der Gegend herum.

Warum dieses? Ganz einfach! Die haben nix excluded!

Ich kenne einige dieser Entwicklerleutchen, sind eben ein kleines, feines eingeschworenes Grüppchen, die sich nur für Helis und deren Plätze interessieren. Die schalten einfach ihr "Autogen" im MSFS aus und ab geht die Post. Anderes braucht nicht dargestellt zu werden und ist in deren Augen überflüssig. Das kann man so machen, keine Frage, das will ich auch nicht kritisieren!

Nur im X-Plane, wo auch noch andere Dinge gezeigt werden sollen, geht das nicht.

Also den OverlayEditor angeworfen, der verabschiedete sich zuerst mal und verwies auf eine log-Datei. Viel heraus zu bekommen war da aber auch nicht. Also die apt.dat (dort steckt der Fehler) besehen und festgestellt, dass man die eigentlich gar nicht braucht. Also gesperrt.

Nun klappt's auch mit dem OverlayEditor. Jetzt alle 1°x1° Kacheln, sind genau 64 Stück händisch nach den Heliports durchsucht und dort jeweils ein Objektexclude gesetzt. Nicht zu groß, aber auch nicht zu klein.

Das war Arbeit für einen ganzen Tag! Jetzt stehen die Gebäude allein dar und sehen auch sehr gut aus. Frameeinbußen habe ich nicht festgestellt.

Leider stimmen die Koordinaten (ist eben MSFS) nicht so ganz - sind bis ca 100 Meter verschoben. Sieht man deutlich wenn die Straßen von OSM zugeschaltet werden. So schlimm ist das auch nicht, denn die Wälder von Corinne tun das auch.

Was jetzt zuerst aber gar nicht geht, ist das landenwollen auf den Dächern der Gebäude - obwohl das Symbol auf dem Dach deutlich sichtbar ist.

Das könnte korrigiert werden. Nur müsste dann mit dem WED auf jedes Dach ein Heliplatz eingefügt, aber vorher die genaue Höhe und die Abmessungen des Daches bestimmt werden.

Sisyphos läßt grüssen! Nicht mit mir. Da schleich ich mich doch sofort von dannen! http://www.clicksmilies.com/s1106/sport/sport-smiley-009.gif

WoDi
27.10.2011, 16:17
Hallo Sisyphos,

den halben Berg bist Du doch schon oben? Oder?
Wenn ich so lese, was Du schon gemacht/erreicht hast dann frage ich mich, ob der ganze Aufwand es das wert ist für die Heliplätze. Und dann 4 GB! Mann oh Mann.
Aber ich glaube es ist die Herausforderung, die Dich treibt. Kann ich helfen?

Gruß
Dieter

Yves
27.10.2011, 17:19
Das könnte korrigiert werden. Nur müsste dann mit dem WED auf jedes Dach ein Heliplatz eingefügt, aber vorher die genaue Höhe und die Abmessungen des Daches bestimmt werden.
Hallo Dietmar,

Das ist doch nicht nötig! Soviel ich weiss, kann man doch die Oberfläche eines Objektes, also auch ein Gebäudedach "hart" machen, so dass der Heli nicht einfach runterplumpst.

Du musst allerdings im overlayeditor schauen, wie das Objekt genau heisst, es in einem Texteditor öffnen, unten die Eigenschaft "ATTR_hard" hinzufügen und das file sichern.

Das sollte klappen!

Gruss
Yves

Dietmar
27.10.2011, 17:22
Kann ich helfen?


Hallo Dieter,
nein, laß mal sein.

Das sind 465 Heliplätze.

Für einen Heliplatz brauchs du ca. 2 Stunden (trial and error), um die exakte Höhe zu ermitteln. Es gibt keine Möglichkeit die etwa auszumessen. Die Höhe darf nur bis max. 5cm abweichen, sonst sind die Kufen unterhalb des Landeplatzes - oder sie hängen in der Luft.

Dass die Ermittlung so lange dauert kenne ich von Freddy Hundertmarls ETHB Bückeburgszenerie, das mit dem Hubschrauberanbau. Das war Knochenarbeit.

Du kannst dir ausrechnen, wieviel Jahre du da werkeln dürftest! http://www.cheesebuerger.de/images/smilie/figuren/a045.gif

Und noch einen Nachtrag zu dieser Szenerie;
Einige Plätze haben sie nach Venezuela versetzt (+10-070) andere in den Pazifischen Ozean (+40-130). Die muss man löschen.
Im Verzeichnis "objects" befinden sich 32914 Dateien.
Noch fragen?

Dietmar
27.10.2011, 17:45
unten die Eigenschaft "ATTR_hard" hinzufügen und das file sichern.



Hallo Yves,
die X-Plane library doc sagt dazu folgendes:

Zitat
Hard Polygons

Normally polygons in your model are not sent to the X-Plane physics engine. This means you can fly right through buildings. By turning on 'hard polygons' X-Plane checks models for collisions. Two warnings about this:

* Hard polygons takes up RAM and CPU time; use this sparingly!
* Hard polygons work well for landing on an aircraft, but not well for horizontal collisions. In other words, if you taxi forward into a vertical wall that is 'hard' the resulting collision will not be well- modeled.

NOTE: If you have multiple LODs (explained below), hard polygons should only be used in the first, closest, most detailed LOD.

(In X-Plane 850 and newer, you can pick what "surface properties" a hard polygon has, for example, you can make your hard polygons react the same way as grass or snow. See the OBJ8 spec for more info on ATTR_hard.)

Typically hard polygons are used to make the tops of buildings part of the physics model so that helicopters can land on them.

PERFORMANCE: hard polygons increase CPU load because the physics engine must evaluate more surfaces. But more significantly, they increase RAM usage! Basically in the current implementation, while object data is kept in memory managed by the driver, the locations of hard polygons are kept separately in system RAM for the physics engine. Worse, these are kept per instance of your object, not once for every instance. So setting a commonly used object to be hard can have enormous RAM implications; use this attribute only when needed.
Zitatende



Das mit ATTR_hard ist mir auch bekannt. Allerdings klappte es mit ETHB nicht. Warum? Keine Ahnung. Hab es dann nach meiner Methode gemacht.

Bemerkenswert ist die Aussage "So setting a commonly used object to be hard can have enormous RAM implications; use this attribute only when needed."

Pro geladenen 6 Kacheln in das RAM, wären es so 50 - 60 Plätze.

Das wird dann auch wieder nichts.

Yves
28.10.2011, 09:28
Hallo Dietmar,

also ich würde - in Anbetracht der bereits geleisteten enormen Vorarbeit - noch nicht aufgeben.
Ich spreche übrigens nicht von Polygonen, sondern von Objekten, die "hart" sein sollen".

Das mit ATTR_hard ist mir auch bekannt. Allerdings klappte es mit ETHB nicht. Warum? Keine Ahnung. Hab es dann nach meiner Methode gemacht.
Vielleicht steht die Eigenschaft nicht an der richtigen Stelle? Zuunterst? Zweitunterst? Schau doch einmal bei einem bestehenden Heliplatz (Zermatt, Monaco etc.) nach, wo das genau stehen muss.


Bemerkenswert ist die Aussage "So setting a commonly used object to be hard can have enormous RAM implications; use this attribute only when needed."
Unter "commonly used" verstehe ich ein Objekt, das allgemein und öfters verwendet wird. Das ist bei einer Heliplattform nicht der Fall. Ein Versuch ist es doch wert, sonst war die ganze Vorarbeit für die Katz!

Liebe Grüsse
Yves

Cedric Loup
29.10.2011, 14:22
....sonst war die ganze Vorarbeit für die Katz!

Liebe Grüsse
Yves

Und dann freut sich die Maus, weil die Katz dann abgelenkt ist. Kicherman

Liebe Grüsse

Cedric