Wir sehen der Polygoncode beschreibt exakt die kleinen Straßen. Dort wo die Straßen schmal sind sind die Einzeldreiecke auch schmal. Bei der runden Abfahrt sind sie breiter. Auch sehen wir hier, dass der Polygoncode wirklich die jeweiligen Gegenrichtungen der Fahrbahnen als Einzelpolycode definiert. Nur so ist es möglich, dass sich die Gegenfahrbahnen auch mal wie beim Autobahnkreuz von einander entfernen. Noch etwas sehen wir hier.
Es handelt sich um einen idealen Polygoncode. Besser und performanceschonender kann man es nicht umsetzen.
Wir wissen die kürzeste Verbindung zwichen zwei Punkten ist eine Gerade. Das bedeutet in Kurvenradien benötige ich viele Definitionspunkte, auf der geraden wenig.
(Achtung zu weit dürfen die Punkte bei Geraden aber nicht auseinander liegen)
Auf jeden Fall kann man sagen, dass nicht jeder Addon Code der mit irgendwelchen Tools erzeugt wurde optimal ist. Da finden sich auf geraden Strecken viel zu viele Definitionspunkte.
Fairerweise muss man sagen, dass auch das Rohdatenmaterial eine Rolle spielt. (ob ich Rasterkarten oder schon vectorisiertes optimales Material aus der Fahrzeugnavigation habe)
Die AROE verwendet bereits optimales Material.
Was jetzt kommt, ist extrem wichtig. Hätten wir normale Straßen wie man sie an Airports findet, also mit Mittellinien (hochaufgelöste Texturen) usw., dann würde der FS so einen Polygoncode wie oben gezeigt auch wirklich an die Grafikkarte weiterliefern. Dann könnten wir die tollsten Texturen verwenden.
Allerdings müsste der FS dann auch sagen, wie die Position des Polygoncodes im 3D Raum sein soll. Also in welcher Höhe die Straße zu liegen hat.
Wir wissen aber der VTP Code ist so ausgelegt, dass er kompatibel zu jeglichem Addonmesh sein soll. Zum Mesh könnten wir auch 3D Gelände sagen. In meiner Doku splitte ich Mesh und 3D Gelände auf. Das 3D Gelände nenne ich Terrainpolygonmodell.
Dieser oben gezeigte VTP PolygonCode wird nämlich von der Grafikkarte als solches überhaupt nicht verarbeitet. Den VTP Polygoncode muss man sich wie einen Platzhalter auf der Erdoberfläche vorstellen. Der VTP Polygoncode reserviert innerhalb der Landclassbodentexturen (die auf dem Mesh liegen) innerhalb seiner Polygonfläche quadratische ca. 4,7m x 4,7m große Einzelpixel für spätere graue Straßentexturpixel.
Wer sich mal ein grobes Schachbrett vor Augen führt möge darüber mal einen schräges Lineal legen. Es wird immer Bereiche geben wo mal mehr Fläche eines schwarzen Quadrates unter dem Lineal liegt und mal mehr außerhalb des Lineals.
Genau so muss man sich das vereinfacht bei den Straßen vorstellen. Unsere Straßen sind nur meshkompatibel wenn deren Texturpixel eine Ehe mit den meshclinging Landclassbodentexturpixeln eingehen.
Mit anderen Worten die Terrainengine tauscht grüne Wiesenpixel gegen graue Straßenpixel aus. Das ganze abhängig von der bestrichenen VTP Straßenpolyfläche. So hat man das Problem, dass des öfteren auch mal kein graues Straßenpixel zur Anwendung kommt sondern ein normales Landclasstexturpixel. Das ganze wird umso kritischer umso schmaler der VTP Polygoncode ist bzw. wenn er schräg verläuft oder nicht halbwegs ins Raster des Terrainpolygonmodells passt.
Mit diesem Sachverhalt möchte ich eine weitere Aussage machen. Wenn der VTP Polygoncode der Straße vereinfacht gesagt nur als Platzhalter für zu tauschende Texturpixel dient, dann wird er doch im optischen Terrain welches die Grafikkarte erzeugt nach dem Tauschprozess nicht mehr benötigt?
Genau so ist es nämlich.
Wir finden im Terrainpolygonmodell nur noch die Dreiecke des Terrainpolygonmodells vor. Der VTP Polygoncode also dessen Dreiecke existieren nicht mehr. Nur die Pixeltauschung wurde durch ihn definiert.
Deshalb unten mal zwei Screenhots bei denen keine Texturfilterung aktiv ist. Ohne Texturfilterungen können wir wirklich jedes ca. 4,7 x 4,7m große Einzelpixel der Erdoberfläche erkennen. Wir sehen auch das unsere eckigen Bodenpixel nach Nord ausgerichtet sind wie im Schachbrettbeispiel. Zuerst die Situation im Default FS.
|