WCM Forum - Einzelnen Beitrag anzeigen - globale Lösung Flackerproblem verschiebt sich

JOBIA · 27.03.2003, 18:06

Hallo Raker One

Nein Du hast bei einem jungfräulichen FS 2002 kein LOD11 Mesh drauf.

Die Probleme hängen aber zusammen. Unten ist ein Bild des Testverfahrens welches jeder austesten kann, wenn er das LOD Raster des Mesh kennt.

Grundsätzlich muß man sagen dieses Flackerproblem der Taxiways ist vermutlich ein BUG des FS2002 in der Programmierung. Bzw. die Technik des Flattens also wie man eine Fläche die durch das Mesh 3dimensional ist flach bekommt hat sich zum FS2000 geändert. Die Runwaytechnik inkl. der Höhe die diese hat ist auf FS2000 Technik geblieben. Leider hat die Runway ein anderes Verhalten zum neuen Flatten Polygon als früher im FS2000, da der FS2002 eine andere Flattentechnik nutzt. Dieses ist das Grundproblem für das flackern. Ob dieses Problem ein Bug ist bzw. sogar von Microsoft gewollt ist kann ich nicht sagen. Dieses Verhalten läßt sich nämlich für tolle andere Sachen nutzen (daher kann es sogar Absicht gewesen sein) Fakt ist aber wenn ungünstige Verhältnisse auftreten bzw. beim Programmieren geschlampt wurde tritt das flackern auf. Will man es beseitigen müssen alle FS2002 Airports überarbeitet werden oder wie bei dem ApronFix (bei Avsim) welches es für einige FS Airports gibt auf die alte Flattentechnik des FS2000 zurückgegriffen werden. Bei meinen Experimenten habe ich noch eine andere globale Lösung gefunden, welche dieses Problem mindert bzw. beseitigt. Das alles zu Erklären ist extrem kompliziert und geht ohne Bilder nicht. Diese globale Lösung hat aber auch Auswirkungen auf das Mesh. Daher habe ich bevor ich die Lösung bekannt geben wollte Mesh Tests gemacht. Hierbei habe ich ein neues Problem festgestellt, darum geht es in diesem Thread. Ich habe entdeckt das ich bei dem Mesh welches definitiv in LOD11 erstellt wurde gar nicht alle ca 19m ein Höhenpunkt entdecken konnte. Soll heißen bei mir sieht es so aus als wenn der FS einen zusätzlichen BUG hat. Er ist nicht in der Lage LOD11 überhaupt darzustellen. Mit der Lösung die ich für das Flackern habe, stellt er aber auf einmal auch LOD11 dar. Nur die Frage ist ob diese Daten nicht verfälscht sind. Zunächst einmal muß aber erst geklärt werden ob bei anderen LOD11 dargestellt wird. Vielleicht ist ja bei mir ein Bug. Daher unten ein Demobild eines LOD9 Mesh welches das Testverfahren erläutert. Das es LOD9 ist habe ich zuvor zusätzlich anhand der Rohdaten ermittelt. Was zeigt uns das Bild. Ich habe mal die Höhenpunkte mit roten Linien verbunden. Man sieht jetzt die einzelnen Polygone (Dreiecke) Wenn wir jetzt mal die Verzerrung des LOD Rasters die ich auf meiner Homepage beschreibe außer acht lassen, wären zwei Höhenpunkte die die gleiche Höhe haben durch eine ca 76m langen Linie verbunden bei einem LOD 9 Mesh. Hätte das Mesh hier eine extreme Steigung wäre die Linie natürlich länger. Deshalb habe ich ja geschrieben, das man nach den kürzesten Linien fahnden soll. Ich habe mal so eine Stelle im Mesh ausgesucht auf die die nahezu kürzeste Verbindung zutreffen sollte. Wie man sieht hat der Lear eine Spannweite nahezu 15 m ( auch in den Daten der Lear Dateien des FS2002). Das sieht man auch an den Pixeln (die eckigen Flächen) der Bodentextur. Diese haben das Rastermaß LOD13 also ein Pixel ca 4,77m. Kontrolle 4,77m x 3 = 14,31m. Die Spannweite des Lear deckt nämlich ziemlich genau 3 Pixel ab. Der Beweis das die Maßstaäbe stimmen. Jetzt ist die rote Linie zwischen den Höhenpunkten hier wenn man die Breite der Spannweite des Lear darauf projeziert bzw. die Pixel einfach mal durchzählt ca 5 x der Spannweite des Lear also ca. 75m lang. Das paßt zu LOD 9 mit der Rasterweite 76,4m. Das Testverfahren kann man also dazu benutzen was der FS maximal LOD mäßig darstellt unabhängig davon wie hochauflösend das Mesh selbst programmiert wurde.

Tja und genau da liegt der Kasus Knacktus. Habe ich ein LOD 11Mesh müßte nach obigen Testverfahren die kürzeste Verbindung zwischen zwei Höhenpunkten die ungefähr die gleiche Meereshöhe haben ca 19m lang sein. Sprich eine rote Linie müßte ca 4Bodenpixel abdecken, bzw. der Lear müßte mit seiner Spannweite ca. 3/4 der Strecke abdecken.

Das ist bei dem LOD11 Mesh aber nicht der Fall. Daher wäre es interressant wie das bei MIG 21 seinen Mesh Files aussieht. Ob er bestätigen kann ob bei Ihm diese Linien entsprechend LOD Raster seines Grand CanyonMesh im Verhältnis zur Spannweite des Lear stehen. Sollte dieses nicht der Fall sein wissen wir das es Quatsch ist hochauflösende Mesh Files zu machen, da sie nicht dargestellt werden. Weiterhin, das meine globale Lösung nicht nur das Flackerproblem beseitigt sondern den Zugriff auf höher vorliegende Mesh Files überhaupt ermöglicht. Wobei ich dann natürlich prüfen muß ob diese Daten wirklich den programmierten Höhendaten entsprechen. Sollte dieses nicht der Fall sein, gehört auch meine Lösung in die Tonne. Dann gibt es keine globale Lösung für das Problem, welches bedeuten würde entweder damit zu leben, bzw. das Apron Fix weiter zu nutzen und dessen Authoren mitzuteilen wo weitere Fehler entdeckt werden. Diese würden dann Ihr Apron Fix um weitere alte FS2000 Flattenpolygone erweitern um das Problem zu beheben.

27.03.2003, 18:06	#10
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	Hallo Raker One Nein Du hast bei einem jungfräulichen FS 2002 kein LOD11 Mesh drauf. Die Probleme hängen aber zusammen. Unten ist ein Bild des Testverfahrens welches jeder austesten kann, wenn er das LOD Raster des Mesh kennt. Grundsätzlich muß man sagen dieses Flackerproblem der Taxiways ist vermutlich ein BUG des FS2002 in der Programmierung. Bzw. die Technik des Flattens also wie man eine Fläche die durch das Mesh 3dimensional ist flach bekommt hat sich zum FS2000 geändert. Die Runwaytechnik inkl. der Höhe die diese hat ist auf FS2000 Technik geblieben. Leider hat die Runway ein anderes Verhalten zum neuen Flatten Polygon als früher im FS2000, da der FS2002 eine andere Flattentechnik nutzt. Dieses ist das Grundproblem für das flackern. Ob dieses Problem ein Bug ist bzw. sogar von Microsoft gewollt ist kann ich nicht sagen. Dieses Verhalten läßt sich nämlich für tolle andere Sachen nutzen (daher kann es sogar Absicht gewesen sein) Fakt ist aber wenn ungünstige Verhältnisse auftreten bzw. beim Programmieren geschlampt wurde tritt das flackern auf. Will man es beseitigen müssen alle FS2002 Airports überarbeitet werden oder wie bei dem ApronFix (bei Avsim) welches es für einige FS Airports gibt auf die alte Flattentechnik des FS2000 zurückgegriffen werden. Bei meinen Experimenten habe ich noch eine andere globale Lösung gefunden, welche dieses Problem mindert bzw. beseitigt. Das alles zu Erklären ist extrem kompliziert und geht ohne Bilder nicht. Diese globale Lösung hat aber auch Auswirkungen auf das Mesh. Daher habe ich bevor ich die Lösung bekannt geben wollte Mesh Tests gemacht. Hierbei habe ich ein neues Problem festgestellt, darum geht es in diesem Thread. Ich habe entdeckt das ich bei dem Mesh welches definitiv in LOD11 erstellt wurde gar nicht alle ca 19m ein Höhenpunkt entdecken konnte. Soll heißen bei mir sieht es so aus als wenn der FS einen zusätzlichen BUG hat. Er ist nicht in der Lage LOD11 überhaupt darzustellen. Mit der Lösung die ich für das Flackern habe, stellt er aber auf einmal auch LOD11 dar. Nur die Frage ist ob diese Daten nicht verfälscht sind. Zunächst einmal muß aber erst geklärt werden ob bei anderen LOD11 dargestellt wird. Vielleicht ist ja bei mir ein Bug. Daher unten ein Demobild eines LOD9 Mesh welches das Testverfahren erläutert. Das es LOD9 ist habe ich zuvor zusätzlich anhand der Rohdaten ermittelt. Was zeigt uns das Bild. Ich habe mal die Höhenpunkte mit roten Linien verbunden. Man sieht jetzt die einzelnen Polygone (Dreiecke) Wenn wir jetzt mal die Verzerrung des LOD Rasters die ich auf meiner Homepage beschreibe außer acht lassen, wären zwei Höhenpunkte die die gleiche Höhe haben durch eine ca 76m langen Linie verbunden bei einem LOD 9 Mesh. Hätte das Mesh hier eine extreme Steigung wäre die Linie natürlich länger. Deshalb habe ich ja geschrieben, das man nach den kürzesten Linien fahnden soll. Ich habe mal so eine Stelle im Mesh ausgesucht auf die die nahezu kürzeste Verbindung zutreffen sollte. Wie man sieht hat der Lear eine Spannweite nahezu 15 m ( auch in den Daten der Lear Dateien des FS2002). Das sieht man auch an den Pixeln (die eckigen Flächen) der Bodentextur. Diese haben das Rastermaß LOD13 also ein Pixel ca 4,77m. Kontrolle 4,77m x 3 = 14,31m. Die Spannweite des Lear deckt nämlich ziemlich genau 3 Pixel ab. Der Beweis das die Maßstaäbe stimmen. Jetzt ist die rote Linie zwischen den Höhenpunkten hier wenn man die Breite der Spannweite des Lear darauf projeziert bzw. die Pixel einfach mal durchzählt ca 5 x der Spannweite des Lear also ca. 75m lang. Das paßt zu LOD 9 mit der Rasterweite 76,4m. Das Testverfahren kann man also dazu benutzen was der FS maximal LOD mäßig darstellt unabhängig davon wie hochauflösend das Mesh selbst programmiert wurde. Tja und genau da liegt der Kasus Knacktus. Habe ich ein LOD 11Mesh müßte nach obigen Testverfahren die kürzeste Verbindung zwischen zwei Höhenpunkten die ungefähr die gleiche Meereshöhe haben ca 19m lang sein. Sprich eine rote Linie müßte ca 4Bodenpixel abdecken, bzw. der Lear müßte mit seiner Spannweite ca. 3/4 der Strecke abdecken. Das ist bei dem LOD11 Mesh aber nicht der Fall. Daher wäre es interressant wie das bei MIG 21 seinen Mesh Files aussieht. Ob er bestätigen kann ob bei Ihm diese Linien entsprechend LOD Raster seines Grand CanyonMesh im Verhältnis zur Spannweite des Lear stehen. Sollte dieses nicht der Fall sein wissen wir das es Quatsch ist hochauflösende Mesh Files zu machen, da sie nicht dargestellt werden. Weiterhin, das meine globale Lösung nicht nur das Flackerproblem beseitigt sondern den Zugriff auf höher vorliegende Mesh Files überhaupt ermöglicht. Wobei ich dann natürlich prüfen muß ob diese Daten wirklich den programmierten Höhendaten entsprechen. Sollte dieses nicht der Fall sein, gehört auch meine Lösung in die Tonne. Dann gibt es keine globale Lösung für das Problem, welches bedeuten würde entweder damit zu leben, bzw. das Apron Fix weiter zu nutzen und dessen Authoren mitzuteilen wo weitere Fehler entdeckt werden. Diese würden dann Ihr Apron Fix um weitere alte FS2000 Flattenpolygone erweitern um das Problem zu beheben.