Wir sehen in dem Bild zuvor die steile Meshverbindung. Wir sehen aber auch das das Area16N Flattenpoly im Umfeld der Runway noch aktiv ist.
Zuvor hatte ich geäußert das Bodentexturzuweisungstechniken die nicht meshclinging sind waagerechte ebene Basisoberflächen benötigen.
Wie man aufgrund des entstandenen Mesh unter der Runway erkennen kann ist hier nichts mehr eben. Und genau in diesem Bereich tritt dann je nach Sichtweise mehr oder weniger starkes Texturflackern oder Texturverschwinden ein.
Letzendlich ein Problem für die Grafikkarte da nicht mehr eindeutig definiert ist was oben und unten liegen soll. Es ensteht ein Z Buffer Problem.
Wie gesagt hier ist alles optisch durch die übertriebenen Höhendifferenzen sichtbar gemacht. Es reichen wie gesagt wenige Zentimeter aus um diesen Bug auszulösen. Nur das man nie vermuten würde was dahintersteckt.
Wie man sehen kann wende ich zum demonstieren keine flackerndenbehafteten Bodentexturen an da sie auf statischen Bildern eh nicht flackernd rüberkommen. Außerdem hättem sie die Sicht auf das Basisproblem versperrt.
Was das schlimme ist das der FS2002/2004 einen Prioritätsbug beim Area16N Flattenbefehl haben.
Beispiel:
Hat ein Addonproduzent z.B eines Einzelairports alles korrekt auf eine identische Höhe programmiert ist zunächst alles einwandfrei. Besitzt man noch eine andere Addon Airportserie die den selben Airport enthält kann es Probleme geben.
Ist in dieser Addonairportserie jetzt dieser eine Airport nicht so gut umgesetzt wird man diese Addonserie logischerweise niedriger in der Scenerybibliothek anmelden als den Einzelairport.
Das ist auch richtig so. Nur leider macht jetzt Area16N Flatten ein Problem.
Verwendet die Addonserie auch Area16N Flatten wird durch den Prioritätsbug dieser falscher Weise für die oben liegende Einzelscenery genutzt.
Ist dieser fälschlicherweise zur Anwendung kommende Area16N Flattenbefehl der Addonserie in der Höhe jetzt niedriger programmiert löst er den Bug aus.
Das wirkt dann für die Anwender ganz kurios. Der Bug tritt nur im Anflug auf nicht aber bei Start auf dem Airport. Einige Anwender können das Problem bestätigen andere wieder nicht weil sie eben dieses Fremdaddon nicht besitzen was den Fehler auslöst.
So geschehen auf dem Airport LOWS bei den AA FS2002 in Verbindung mit der ATP2002.
Zu dieser Problematik hatte ich vor 2 Jahren mal eine Doku geschrieben. Da zu komplex hatte ich sie wieder von meiner Homepage runtergenommen. Denn im FS2002 wurde dieses noch durch weitere Bugs im LWM2 BGL Code begünstig.
Übrigends kommt dann noch GAP1 dazu hätten wir in LOWI sogar zwei potentielle Fremdauslöserkandidaten.
Wie gesagt diese Probleme treten nicht auf wenn alle Addons identische Höhen verwenden.
Ich habe dieses Phänomen auch nur bei Verwendung dieses einen Runwaycodes bzw. Area16N Flatten feststellen können.
Ich schliesse aber nicht aus das noch andere Oberflächentechniken so ein Verhalten haben könnten.
Jetzt könnte jemand sagen ja warum nimmt man denn nicht gleich einen neuen LWM Flattenbefehl.
Anwort weil es nichts bringt. Denn über einem LWM Flatten hätte man den Bug sofort und immer.
Der Vorteil wäre hier nur das es ein stabiler Fehlerfall wäre der dem Addon Produzenten sofort auffällt. Außerdem pfuscht einem hier kein Fremdaddon rein, da LWM Flatten keinen Prioritätsbug hat. Das setzt aber vorraus das auch ein Fremdaddon LWM Flatten nutzt.
Wie gesagt Abhilfe gegen Texturflackern ist wenn immer alles eine Höhe hat.
Das ist natürlich nicht gewährleistet bei Fremdaddons.
Da Area16N Flatten die unangenehme Eigenschaft hat das diese Flattentechnik höher als LWM Flatten bewertet wird ist man selbst dann nicht vor diesem Problem gefeit wenn man selbst alles mit LWM Flatten produziert. Denn ein Fremdaddon welches mit Area16N Flatten daher kommt mauschelt sein Flattenpoly vor.
Nicht vergessen möchte ich das ein Designer zusätzlich mal ins SDK schauen sollte. Leider nützt das beim aktuellen FS2004 BGLCOMP SDK auch nicht mehr viel denn hier wird nicht mehr der Bytecode selbst beschrieben. Ein aktuelles Manko bei Microsoft. Es gibt nämlich mittlerweile verschiedene Techniken wie der FS Höhenangaben Bytemäßig in der BGL umsetzt.
Je nach Runwaycode bzw. Flattentechnik wird der Höhenwert mit Nachkommastelle den man der Runway im Designprogramm oder im Basisquellcode beigibt im Kompiler auf Werte umgesetzt die ins Raster des BGL Code (z.B Ganzzahl und Fractionalteilerwerte) passen. Im FS findet man dann eine ganz andere Höhe vor als man zuvor im Quellcode programmiert hat.
Schon hat man wieder eine Fehlerquelle.
Am besten fährt man wenn man diesen FS2002 Runwaycode nicht mehr verwendet. Alle anderen Runwaycodes schweben im schlimmsten Fall und lösen damit optisch keine großen Probleme aus.
Betroffen bzw. empfindlich auf Störungen sind daher vorwiegend Addons die noch diesen alten FS2002 Runwaycode verwenden.
Wie gesagt ich kann allerdings nicht sagen ob es noch andere Oberflächentechnikenbefehle gibt die auch diese negative Eigenschaft haben.
Ich hoffe das dieser Text dem Anwender das Problem erklärt hat. Ev. trägt er sich auch über betroffene Anwender an den ein oder anderen Addon Produzenten weiter.
Ich werde ihn auf jeden Fall in dieser Form irgendwann auch auf meine Homepage stellen.
Flackern von Bodentexturen im FS2004 kann bei Verwendung reiner FS2002 Scenerybefehle übrigends auch enstehen wenn man Bodenpolys nicht in ein gewisses Layerkorsett zwingt. Der FS2004 ist da pingeliger als der FS2002. Scenerien die im FS2002 noch liefen leiden ev. im FS2004 unter Texturflackern wenn sie auf FS2004 Defaultairportcode stoßen. Denn nicht alles an FS2004 Code kann man mit FS2002 Excludecode excludieren. Irgendetwas stört da.
Beseitigen kann man das Problem in dem man über den LayerCall( :Label layer ) SCASM Befehl eindeutige Zuweisungen bei den Bodenpolys erzeugt.
|