![]() |
![]() |
|
|
|||||||
| Simulationen Alles zum Thema Simulation |
|
|
Themen-Optionen | Ansicht |
|
|
#11 |
|
Inventar
![]() Registriert seit: 02.01.2002
Alter: 61
Beiträge: 4.238
|
Zu der Texturflackergeschichte noch mal. Es wurde hier im Thread erwähnt, dass doch ev. auch ein Mesh dafür verantwortlich sein könnte.
Ich hatte darauf geantwortet, dass dieses im Normalfall nicht sein kann, da die Airports immer ein Flattenpolygon besitzen, dass dafür sorgt, dass der Airport und dessen Texturen ein feste gesicherte Bezugsoberfläche unabhängig von irgendwelchen Meshfiles haben. Der FS 2004 benötigt so etwas, wenn AI Traffic und hoch aufgelöste Texturen wie bei EDDF zur Anwendung kommen sollen. Denn die Terraintechnik kann man aus dieser Sicht als unberechenbar bezeichen. Bei niemand kann sichergestellt werden, dass ein bestimmtes Mesh als Basisoberfläche vorliegt. Deshalb werden eigene Flattentechniken genutzt. Ich habe mal bei EDDF ein waagerechtes LOD10 Mesh unterlegt, welches auf 0 Meter Höhe liegt. Der Airport liegt um einiges höher. Zusätzlich habe ich Gewässer und Straßen deaktiviert, da sie Mesh beeinflussende Komponenten besitzen die hier verwirren könnten. Der Screenshot im Anhang zeigt die Auswirkungen des wesentlich niedrigeren Meshfiles. Wir können jetzt sehr gut die eigene Mega EDDF Flatteninformation sehen. Diese Flatteninformation hält den Airport unabhängig von meinem wesentlich tieferen Mesh auf fester Höhe. Ich habe sie rot umrahmt. Wir sehen auch das sie flächenmäßig ungewöhnlich groß gehalten ist. Ein Mesh kann den Airport zunächst also überhaupt nicht beeinflussen. Ich habe ein File mit DEM im Namen gefunden. Der Bytecode hat es gezeigt, es ist ein alter FS2000 AREA16N Flattencode, den man aufgrund des Namens mit dem Designtool SCC erzeugt hat. Hier kann ich folgende Aussage machen. Ich habe zu Anfangszeiten des FS2002 festgestellt, dass er grundsätzlich eine höhere Priorität gegenüber aktuellen LWM Flattentechniken des FS2002 und FS2004 geniesst. Weiterhin,dass es leider beim FS2002 / FS2004 ein Prioritätsbug gibt, wenn z.B zwei AREA16N Flattenbefehle flächenmäßig aufeinander treffen. Problem dabei: Flattencode kann man per Befehl nicht excludieren, also unwirksam schalten. Objektscenery schon. Was könnte das für folgen haben? Nun hat der Anwender z.B noch eine alte GAP FS2004 Version oder eine andere Scenery die auch EDDF enthält, dann existiert auch hier EDDF. (früher wurden bei GAP in der Regel AREA16N Flattencodes genutzt). Der neue Mega EDDF hat natürlich Excludefiles. Diese würden den alten EDDF Airport optisch excludieren. Der alte EDDF Airport käme optisch nicht zur Anwendung. Allerdings bliebe dessen AREA16N Flatten aktiv, welches sich nicht excludieren lässt. Jetzt kann der Priobug bei AREA16N zu schlagen. Wenn alte EDDF Airports mit Area16N Flatten Befehl und neue Mega EDDF Flatteninformation auf minimal unterschiedlichen Höhen liegen, kann es bei so einem Anwender zu Texturflackern kommen. Andere bei denen ein alter EDFF nicht aktiv ist, werden dieses Problem dann nicht haben. Auch ist ein AREA16N Flatten anfällig auf Wechselwirkungen. Siehe den damaligen Beitrag von mir. (Flackern von Bodentexturen nur wenn außerhalb des Airports gestartet wird) Unten der Screenshot, wo man sehr schön die eigene Flatteninformation von Mega EDDF sehen kann, die den Airport in der Regel unbeeinflussbar durch Meshfiles macht. |
|
|
|
| Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1) | |
|
|