Flackern von Bodentexturen an Airports nur wenn außerhalb dieser gestartet wird

[JOBIA]

Habe lieber einen neuen Thread wegen des Themas aufgemacht.

Original geschrieben von Börnie
Frühschicht eingelegt?

Wie Du richtig schreibst: schaut alles nach diesem Area16N Flatten-Befehl aus. Die Symptome sind exakt die gleichen. Ausserdem hat Stefan ganz eindeutig sehr viele Daten seiner Flugplätze aus der Vorgängerversion übernommen und eben nicht nach der neueren Designmethode (G-max glaub ich heisst die, nicht wahr?) errichtet.

Naja, ich kann so halbwegs damit leben. Hauptsache das mit den Meshes ist soweit durch die vorgenommene Umgruppierung behoben (und damit gleich für andere Regionen auch).

Liebe Grüße

Bernd

Ne Frühschicht nicht. Das ist meine normale Zeit wenn ich mich mit dem Flusi beschäftige. Sonst bleibt mir nichts. Abends ist es in der Regel nur mal kurz hier ein Posting setzen.


Mit GMAX hat das übrigends nichts zu tun. GMAX ist im wesentlichen ein Objektdesigntool also für 3 dimensionale Formen. Aber auch da gibt es natürlich ältere Techniken im FS die aber in der Regel keine Probleme machen außer das sie etwas mehr Performance schlucken.

Bei dieser Problematik mit dem Flackern geht es mehr um spezifische Designtechniken die nur der Flusi benötigt. Aber dieser erwähnte ältere Area16N Flattenbefehl und der zugehörige Runwaybefehl aus dem FS2002 sind ein wesentliches Hauptproblem an dieser Geschichte.

Wobei der Area16N Flattenbefehl noch nicht mal von Stefan kommen muss.

Theoretisch könnte dieser auch durch die ATP2004 oder eine andere Scenery für diesen Airport kommen, muss aber nicht.


Ärgerlich ist es trotzdem da man den Bug eigentlich leicht beseitigen kann.

Sollte allerdings ein weiteres Addon verstrickt sein muss dieser Produzent zusätzlich mit einbezogen werden.

Ich habe auch die Mail mit dem Sachverhalt die ich damals an ein betroffenes Team geschickt habe gefunden.

Ev. werde ich die auf Anonymität abändern und hier rein setzen.

Dann kannst Du oder andere die solch ein Problem mit einem Addon haben auf diesen Link verweisen. Ich stelle mich natürlich für weitere Hilfe zur Verfügung. Nur von mir aus (bin ja Außenstehender) möchte ich da keinen Addonproduzenten drauf ansprechen ohne seine Scenery zu besitzen.

[JOBIA]

Ich habe mich entschlossen doch nicht meine E-Mail an ein betroffenes Addon Team als Basis zu nutzen. Ich habe das noch mal neu verfasst und werde es ev. zusätzlich auf meine Homepage hochladen. So eine Dokumentation hatte ich als ich damals im FS2002 nach diesen Bugs geforscht habe schon mal auf meiner Homepage gehabt. Die war aber recht komplex zumal der FS2002 diese Problematik durch Programmierfehler des FS2002 beinflusst hat. Die Doku ging daher runter bis in den BGL Byte Code um die Problematik zu demonstrieren. Dieser Text soll etwas einfacher sein. Er ist nicht nur für Designer gedacht. Auch Anwendern kann dieses Wissen nicht schaden denn es ist ein schönes Beispiel dafür das ein Addon Produzent nicht unbedingt für Fehler seiner Scenery verantwortlich sein muss.

Anwender die solch fehlerhafte Scenerien haben können ev. diesen Link mit der Problematik an den betroffenen Addon Produzenten weitergeben.

Denn momentan besitze ich kein Addon mit diesem Verhalten. Da würde es doof aussehen wenn man sich persönlich als nicht Betroffener einmischt. Für weitere Fragen würde ich natürlich zur Verfügung stehen wenn es gewünscht wird.


Zuvor kurz ein paar erklärende Begriffe.

1)Flattentechniken sind Techniken um ein waagerechte feste Oberfläche zu erzeugen.

2)Mesh die 3 dimensionale Erdoberfläche. Der Ausdruck Meshclinging bedeutet dem Meshverlauf folgend. Bei Texturen trifft dieses nur zu wenn es sich um Bodentexturen programmiert über Landclasstechnik bzw. die SDK kompatible Custom Fotoscenerytechnik handelt (letztere hat eine Basis zur normalen Landclasstechnik). Weiterhin die hier nicht interessierende VTP Polytechnik.


Nur diese Techniken folgen jeder beliebigen unebenen Oberfläche einwandfrei. Sie haben allerdings den Nachteil das die Bodenauflösung nur ca. 4,77m pro Pixel betragen kann. Für Details wie Taxiwaylinien usw. eindeutig zu wenig. Wer will schon 4,77m breite Taxiwaylinien haben.

Andere Fotoscenery- oder Bodentexturzuweisungstechniken über Polygone die oft in Airportnähe eingesetzt werden sind nicht meshkompatibel können dafür aber quasi mit beliebig hoher Bodenauflösung zur Anwendung kommen. Details sind so eindeutig sichtbar. Sie setzen in der Regel ein ebenes Polygon als Bezugsoberfläche voraus. Wenn man Glück hat schaffen es solche Texturzuweisungstechniken halbwegs einer unebenen Oberfläche zu folgen. Ein stabiler Zustand ist es allerdings nicht so das es bei unebenen Flächen zum flackern kommt.

Handelt es sich um waagerecht positionierte Bodentexturen die über ein Polygon definiert werden benötigen diese als Basisuntergrund ein waagerechtes Flattenpolygon. Einmal um flackern dieser Textur über einem unebenen Untergrund zu verhindern, weiterhin um zu verhindern das ein Flugzeug durch diese Textur auf ein ev. höhenmäßig tieferliegendes Mesh hindurchsacken kann.

3) LOD Level
Beim Mesh z.B gibt es eine Basisauflösung in der es programmiert ist. Bei LOD9 wären das ca. alle 76m ein Höhenpunkt. Der FS verbindet diese Höhenpunkte dann optisch durch feste Oberflächen es entsteht eine real wirkende Erdoberfläche.

Es gibt nun aber mehrere LOD Level. LOD10 hat z.B die doppelte Auflösung wie LOD9 also ein Rasterabstand von ca. 38m. Folglich hätte LOD8 ca. 152m Rasterabstand.

Der FS kann ein LOD9 Mesh aber auch mit niedrigen LOD Leveln darstellen. Er benutzt z.B vom LOD9 Mesh mit 76m Rasterabstand nur jeden zweiten Wert. Also nur jeden Wert alle 152m. Diese Dynamik die er verwendet kann man nur über Testfiles beweisen. Irgendwann greift er dann aber auf eines seiner niederwertigen Default Basismeshfiles zurück. Diese sind von vorneherein mit niedrigerem LOD Level programmiert.

4) MIP Level
Ähnlich LOD Level nur hier gilt der Sachverhalt für Texturen.



Kommen wir zu dem eigentlichen Problem warum z.B an Airports Bodentexturen flackern.

Speziell zu der Problematik das es oftmals nur dann auftritt wenn wir den Airport aus der Ferne anfliegen. Starten wir in der Nähe des Airports oder direkt auf diesem haben wir keine Texturprobleme.




Hier die Dokumentation mit ein paar Bildern des Problemes.

Ich habe eine Testscenery programmiert die dieses Problem auf einfache Weise optisch demonstrieren soll.

Diese Testscenery befindet sich an einem realen FS2004 Defaultairport.
Sie besteht aus 3 BGL Files.

1) Eine Exclude BGL Datei. Diese dient wie bei anderen Addon Airports auch dazu den Default FS2004 Airport optisch zu löschen. Man findet dann eine optisch leere Fläche vor. Es bliebt übrigends das Rasenpoly des Defaultairports erhalten. Dieses müsste über ein VTP Excludebefehl excludiert werden. Das habe ich mir geschenkt da dieses Rasenpoly für die Demonstration nicht stört.

2) Eine Flatten BGL. Diese benötigt ein Addon Airport damit seine über Polygonflächen zugewiesenen Bodentexturen (z.B Apron , ev. hochaufgelöste Fotoscenery die nicht meshclinging sind) als Basisoberfläche ein flache waagerechte Bezugsfläche erhalten durch die z.B ein Aircraft nicht durchsackt. Ohne Flattenpoly würde ein Aircraft wie durch eine Wolke durch eine Bodentextur hindurchschweben wenn das Poly im FS auf eine feste Höhe programmiert wird die über dem Mesh liegt. Bei unebener Fläche könnte wie gesagt ein Texturflackern auftreten.

[JOBIA]

Ich habe hier den sogenannten älteren Area16N Flattenbefehl verwendet. Es gibt wie gesagt auch neuere Flattentechniken bzw. den ganz alten Flatteneintrag den man in der Scenery.cfg setzen kann. (Wobei ich nie getestet habe ob dieser Flatteneintrag in der Scenery.cfg auch so ein Phänomen auslösen kann)


Wer aber z.B mit dem Designtool Schiratti Control Center (SCC) Scenerien programmiert verwendet automatisch diesen Area16N Flattenbefehl. Es sei denn er löscht diesen und ersetzt ihn nachträglich durch einen neueren LWM Flattenbefehl.

Da ja dieses Problem im Forum bei den neuen FS2004 Austrian Airports genannt wurde gehe ich auch anhand der gezeigten Screenshots der AA (Taxiwayoptik usw.)davon aus das diese in weiten Teilen mit dem SCC programmiert wurden. Von daher ist fast davon auszugehen das der Area16N Flattenbefehl zur Anwendung kommt. Die alten AA FS2002 waren definitiv mit SCC programmiert.


3) Weiterhin eine Objekt BGL die nichts weiter als eine Runway enthält.
Es gibt 3 offizielle SDK Codes um eine Runway zu programmieren. Diese rühren aus verschiedenen FS Versionen. Diese von mir programmierte Runway hat genau wie der Area16N Flattenbefehl ein Problem der den Bug mit verursacht.

Programmiert man mit dem Designprogramm SCC erhält man genau diesen problematischen Runwaycode. Dieser Runwaycode hat das Problem (bei Höhendifferenzen) das wenn er ungeschützt über einem Geländemeshfile bzw. LWM Flattenpolygon liegt es zu einer festen Meshverbindung zur Runwayoberfläche kommt.

Der aktuelle Runwaycode des FS2004 sowie auch der ganz alte aus dem FS2000 SDK haben das
Problem nicht. Diese schweben bei Höhendifferenzen schlimmsten Falls in der Luft.

Nicht das wir uns falsch verstehen. Alles was man mit dem SCC programmiert ist offizielle SDK Technik. Dieser Bug tritt auch nur ein wenn bestimmte Konstellationen bzw. zusätzlich Höhenabweichungen vorliegen.


Was zeigen uns meine Scenery BGLs im FS. Ich erwähnte zuvor das dieses Problem nur auftritt wenn die Höhendefinitionen von einander abweichen. Um die Problematik optisch darzustellen arbeite ich bewusst mit extrem verfälschten Höhenwerten.

1)Das Mesh hat in unserem Fall ein mittlere Höhe ca 700m.

2)Das Area16N Flattenpolygon erzeugt eine waagerechte Bezugsoberfläche für die Texturen damit nichts flackert. Dieses Flattenpoly habe ich auf 900m gelegt, so hebt es sich als Hochplateau vom übrigen Mesh ab so das wir es gut erkennen können.

3)Eine einzelne Runway programmiert im Code welcher im FS2002 aktuell war. Diese liegt auf 1000m und hebt sich optisch gut vom Flattenpoly bzw. dem Mesh ab. Die Runway bietet einem Aircraft durch Ihren Code bereits eine feste Oberfläche. Hier würde ein Flugzeug nicht durch die Runwaytextur sacken. (das ist aber nur weil es Microsoft so programmiert hat. Der ganz alte FS2000 Runwaycode hat diese Eigenschaft nicht)

Was zeigt uns das erste Bild im Anhang unten?

Das umliegende Mesh welches tiefer als das Flattenpoly liegt.

Man sieht noch das alte Rasenpoly des Defaultairports. Daran kann man auch erkennen das die excludierte Defaultrunway nicht in Nordrichtung gelegen hat. Ich habe meine Runway bewusst ausgenordet.

Man sieht das Area16N Flattenpoly im Bereich unter der Runway. Oder sagen wir es so, man kann die waagerechte 900m hohe Flattenoberfläche erahnen da sie sich sich vom Mesh abhebt.

Weiterhin sehen wir die Runway auf 1000m. Wie man sehen kann "schwebt" sie 100m über dem Flattenpoly. (Diese Eigenschaft hat sie aber nur wenn bei laden des Runwaybefehles ein aktives Area16N Flattenpoly als Unterlage erkannt wird). Das kann man auch an der B747 erkennen die rechts neben der Runway in der Luft schwebt. Oben in der Koordinatenzeile kann man sehen das sie sich auf 973m befindet.

Würde man jetzt Bodentexturen über eine Technik positionieren die nicht meshclinging ist, was fast immer der Fall ist wenn man hochaufgelöste Bodentexturen verwenden möchte dann würden diese auf der waagerechten Area16N Flattenfläche aufliegen. So wird es korrekt im Addon programmiert.

Die Texturen würden nicht flackern da die Oberfläche waagerecht ist.

Die Runway schwebt wie gesagt über dem Flattenpoly. Hätte der Addonproduzent die Runway nicht wie ich 100m über dem Flattenpoly programmiert sondern sie nur 10cm darüber würde das schweben kein Mensch bemerken. Allerdings würde das Flugzeug einen 10cm Hopser nach unten machen wenn man die Runway verlässt. In Konstellation mit AFCAD2 FS2004 Bodentechniken kann so bei Höhenabweichungen der Sceneryelemente auch zusätzlich das schweben oder einsinken von AI Flugzeugen enstehen.

Wie gesagt ich habe die Runway 100m höher gesetzt damit man die Problematik optisch erkennen kann.

Das Bild unten zeigt uns also den Zustand wie kein Texturflackern auftreten kann.

Dieses ist exakt die Situation die man bei Verwendung dieser Scenerybefehle erhält wenn man am Airport oder in dessen Nähe startet. Das Mesh wird in dieser Konstellation bei Aufsetzen des Fluges an diesem Problemairport bereits im höchsten LOD Level geladen. Erst danach lädt der FS den Area16N Flattenbefehl und anschließend die Runway. So sieht die Runway unter sich nur die Area16N Flatteninformation. Die Runway schwebt die Oberfläche unter ihr ist eben, es kann nichts flackern.

Das Bild runway1.jpg

[JOBIA]

Die nächsten Bilder werden uns zeigen was passiert wenn wir den Airport aus weiter Ferne anfliegen. Sprich die Konstellation wenn auf einmal Bodentexturflackern am Problemairport auftritt.

Da mit die ganze Materie was passiert besser rüberkommt simmuliere ich hier einen Anflug des Airports aus der Ferne. Diese Simulationstechnik die ich beschreibe verdeutlicht dieses besser als wenn wir ihn real anfliegen würden.

Zunächst mal befinden wir uns noch in der Konstellation wie man sie auf dem Screenshot zuvor sehen kann. Wir sehen die schwebende Runway und das flache Flattenpolygon.

Wir merken uns die Koordinate dieser Position. Das Flugzeug sollte dabei ausgenordet sein. Denn wenn wir uns später im Slewmodus bewegen braucht man so nur die Nordkoordinate zu beobachten.

Sind diese Bedingungen erfüllt bewegen wir uns im Slewmodus mit ""maximaler Geschwindigkeit"" von unserem Problemairport weg so das wir ihn nicht mehr sehen. Ich sage jetzt einfach mal ca. 70km.

Haben wir uns soweit wegbewegt bringen wir unserer Flugzeug in den Stillstand. Uns wird aufgefallen sein das es der FS nicht schafft die Landclassbodentexturen und sein Mesh vernünftig aufzubauen. Wir müssen jetzt warten bis er die Scenery korrekt aufbaut. ( Über den SceneryReload Befehl den man mit einer Tastenkombination belegen kann geht das in Sekundenschnelle aber lassen wir das)

Nehmen wir uns die Zeit und beobachten einfach was passiert. Wir sehen nämlich jetzt den dynamischen Aufbau der Scenerytechnik beim FS. Das Mesh ist noch in niedrigem LOD Level keine Geländedetails sind erkennbar. Unsere Bodentexturen sind nur eine farbliche Suppe. Auch Autogen existiert noch nicht. Nach und nach nehmen wir ein Zucken im Gelände war. Das Mesh baut sich in den jeweiligen LOD Leveln in Schritten langsam auf. Bodenunebenheiten werden immer detailierter. Das selbe trifft auf die Bodentexturen zu. Aus der Farbsuppe werden langsam in Schritten (je nach MIP Level der Textur, vergleichbar mit den LOD Leveln beim Mesh) Bodentexturen erkennbar die immer schärfer werden.

Autogen taucht auch irgendwann auf.

Im Prinzip sieht man jetzt das was der FS auf jedem Flug macht. Diese dynamische Technik nutzt er um Performance zu sparen. Nur beim Flug bemerkt man diesen dynamischen Aufbau nicht so stark da man sich relativ langsam bewegt. Der FS hat also fast alle Zeit der Welt um diese Vorgänge weit im Hintergrund wo der Anwender eh kaum Details wahrnehmen kann ablaufen zu lassen.

Diese dynamische Technik nutzt man im wesentlichen aus zwei Gründen.

1) Sie spart Rechnerperformance da nicht so viele Informationen dargestellt werden müssen die man eh in der Tiefe des Raumes nicht sehen könnte.

2)Beim zweiten Grund kann man das am einfachsten anhand der Texturen erklären. Würde der FS in der Tiefe des Raumes auch versuchen jeden höchst aufgelösten Level der Basistextur anzuzeigen hat man ein Problem. Je nach Grafikkarteneinstellung zeigt uns der Monitor z.B 1024 x 768 Pixel.
Die Grafikkarte könnte also optisch überhaupt nicht alle 256 x 256 Pixel einer Bodentextur anzeigen die optisch ev. 30km von uns entfernt ist.

Stark vereinfacht gesagt würde die Grafikkarte das versuchen (Filtertechniken außen vor) dann würde je nach Bewegung des Betrachters mal dieses Pixel dann mal ein anderes Nachbarpixel in einem Bereich unserer 1024 x 768 Grafik auftauchen. Da die Nachbarpixel aber sehr wahrscheinlich unterschiedliche Farbwerte haben nehmen wir das als starkes Bildflimmern wahr.

Daher verwendet man in der Tiefe des Raumes Texturvarianten der Basistextur mit niedriger Auflösung. Da gibt es dann je nach Format zu einer Basistextur mehrere Untertexturen die immer aufs neue in der Auflösung minimiert sind.

Das ganze kann in der jeweiligen Sonderbitmaptextur im Header der Bitmaptextur definiert sein. Deshalb können Standardgrafikprogramme diese Texturen in der Regel auch nicht anzeigen.

So ist jetzt unser Bild stabil und alles hat sich korrekt aufgebaut bewegen wir uns wieder mit maximaler Geschwindigkeit an die Koordinate die wir uns zuvor gemerkt haben.

Haben wir sie erreicht stoppen wir so schnell wie möglich.

Wieder ist die Scenery aufgrund der Dynamik noch nicht fertig aufgebaut.

Ich kann leider nicht beurteilen wie schnell aktuelle High End PCs arbeiten bei meinem Notebook mit 2,5GHz habe ich aber wenn es mit dem schnellen Anflug gut geklappt hat genug Zeit um die Vorgänge zu beobachten.


Ich sehe folgendes Bild.

Das Mesh ist im niedrigsten LOD Level vorhanden. Alles ist recht eben und schlecht aufgelöst. Ich kann aber erkennen das das Area16N Flattenpoly geladen wird. Diese 900m Hochebene ist zu erkennen.
Kurze Zeit später wird auch die Runway geladen. Siehe da sie schwebt da sie erkannt hat das zuvor unter Ihr ein Area16N Flattenbefehl aktiv war.

Diesen Zustand zeigt runway2.jpg im Anhang

[JOBIA]

Wie man sehen kann war das Mesh bereits im niedrigsten LOD Level vorhanden erst danach wurde Area16N Flatten aktiv danach erst die Runway.

Man sieht praktisch die Priorität des Ladeverhaltens.

Wir beobachten weiter. Wir sehen wieder ein Zucken im Mesh. Das Mesh hat in den nächsten LOD Level geschaltet. Dieses ist jetzt aber eine neue Information auf die der Runwaycode siehe ganz oben beim Thema Verhalten dieses Runwaycodes reagiert.

Peng es passiert. Auf einmal haben wir eine meshförmige Geländeverbindung zur Runway. Zuerst noch großflächig.

Dieser Runwaycode hat die Eigenschaft das er immer wenn er unter sich Mesh oder LWM Flatten erkennt diese Meshverbindung herstellt.

Genau das ist beim LOD Level schalten geschehen. Er nimmt nachdem das Area16N Flattenpoly geladen ist eine neue Meshinformation auf. Es ensteht dieses künstliche Meshgelände welches wie man unschwer erkennen kann eben nicht mehr waagerecht und eben ist.

Warten wir ab bis sich die Scenery komplett auf gebaut hat. Mit jedem LOD Level schalten wird diese Geländeverbindung in der Fläche kleiner dafür aber steiler.

Das sieht dann so aus wie in Bild runway3.jp

[JOBIA]

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.

[wazlaf]

Danke Jobia,

diese Erklärung hat bei mir viele Unklarheiten beseitigt und einen Verdacht bestätigt.

lg walter

[JOBIA]

Danke für das Lob.

Ich denke es macht Sinn dieses Problem hier im Softwareforum zu erläutern. Denn Flackern von Bodentexturen wurden schon öfters gemeldet. So findet man eine Lösung für das Problem über die Suchfunktion des Forums. Ev. trägt sich das so schneller an ein Addonteam mit so einem Problem.