unscharfe Straßen bei All Roads of Europe?

[JOBIA]

ich möchte noch eine Altlast zu diesen Threads mit ein paar Bildern aufbereiten.


Total verschwommene Texturen

und


fehlende Texturen um Frankfurt durch AROE?

Es wurde ja schon mehrfach bemängelt, dass einige Straßen bei der AROE schlecht erkennbar sind bzw. unscharf wirken.

Man sollte wissen, dass der FS in der Tiefe des Raumes minderwertige Bodentextur MIP Level (auf der Basistextur basierende Untertexturvarianten mit weniger Pixeln pro Fläche verwendet. Diese wirken natürlich unschärfer).

Das gilt dann natürlich auch für die Straßen. Denn es handelt sich hierbei um Straßen in sogenannten VTP Code (Vector Terrain Polygon).

Diese VTP Straßen haben ähnlich unserer großflächigen Gewässer in LWM Technik (LandWaterMask) die Eigenschaft, dass sie, falls sie so programmiert wurden jederzeit unabhängig vom verwendeten Meshfile dessen Oberfläche folgen können (meshclinging). Solche Straßen können Berg ab oder auch Berg auf laufen.

Das können die Straßen mit Mittellinien die wir z.B oft an Airports finden nicht. Sie benötigen eine feste Bodenpolygonbezugsfläche mit eigenen Höhenprofil.

Diesen VTP Straßen haben also einen riesen Vorteil, wir können sie überall ohne Probleme verwenden. Wo ein Vorteil ist, ist auch ein Nachteil. Der Nachteil liegt in der geringeren Bodenauflösung. Sie haben einen direkten Bezug zur Landclasscenery und daher definiert ein einzelnes Pixel eine reale Fläche von ca. 4,7m x 4,7m.

So sind natürlich keine Mittellinien darstellbar. In der Tiefe des Raumes wird durch die MIP Level Technik die Auflösung sogar noch schlechter.

Sollte etwa dieser Bereich in der Tiefe des Raumes bei den AROE Straßen als unscharf bemängelt werden?

Haben wir z.B das Problem, dass unsere Bodentexturen im Vordergrund aufgrund PC Belastung unscharf werden, dann kommen natürlich im Vordergrund schon minderwertige MIP Level zur Anwendung. Das bedeutet selbst im Vordergrund haben wir keine Bodenauflösung ca. 4,7m. sondern viel schlechter. Dieses gilt dann natürlich aufgrund des direkten Landclassbezug auch für die VTP Straßen.

Wird dieses bemängelt?

Ist der Mangel dann überhaupt berechtigt?

Aus diesem Grund gilt es zunächst mal nachzuweisen was überhaupt bemängelt wird.

Ich habe einem Anwender Teile meiner Doku inkl. Testscenerien geschickt. Wie von mir vermutet wurden auch Teile der Straßen als unscharf bemängelt die im höchsten MIP Level also mit ca 4,7m pro Pixel vorliegen.


Ich habe dem Anwender mitgeteilt, dass dieses FS konstuktionsbedingt und damit als normal anzusehen ist.

Warum, bin ich bisher schuldig geblieben. Das möchte ich hiermit nachholen.

Schauen wir uns doch mal zwei Screenshots an exakt identischer Position im FS2004 an. Es ist bekannt, dass im Default FS die Straßen recht ungenau platziert sind. Daher werden wir sehen, dass die Autobahnen zur AROE auch von der Position abweichen. Die AROE ist in dieser Hinsicht erschreckend genau. Weiterhin liefert sie qausi jede Straße die es gibt. Sogar kleinere Feldwege sind umgesetzt. Das ganze ist auch korrekt klassifiziert. Die Gründe dafür dürften mittlerweile bekannt sein. Es handelt sich um Material welches unter anderem in der Fahrzeugnavigation in Verbindung mit GPS Systemen zum Einsatz kommt. Da kommt es auf jeden Meter drauf an. Da die Navigationssysteme in der Regel bei einer Routenplanung natürlich wissen müssen ob kürzeste, schnellste bzw. Mautstraßen oder ähnliches genutzt werden dürfen ist es logisch, dass diese Basisrohdaten genau definieren was Autobahn, Bundesstraße, Kreisstraße, Landstraße usw. ist.

Bei einem anderen Straßenaddon konnte man sehen wie es aussieht, wenn man dieses einfach unterschlägt und jede kleinere Straße unter Verwendung der Default FS2004 Straßentexturen umsetzt.

Einfach grausam. Es ist nur noch eine durch graue Linien zerstörte Erdoberfläche. Das hat nichts mehr mit Realismus zu tun. Genau so verhält es sich nämlich im Default FS. Nur da stört es nicht, weil eben nur Autobahnen und ganz wichtige andere Strecken mehr oder weniger schlecht umgesetzt sind.

Unten der Screenshot der Defaultscenery mit den recht monströsen Defaultstraßen, deren Breite nichts mit der Realität zu tun hat. Die Screenshots wurden ohne weitere Manipulation erstellt. Texturfilterung ist wie bei Neuinstallation des FS aktiv.

Wir sehen Autobahnkreuze gibt es nicht. Durch die Filtertechniken wirkt es aus nächster Nähe nicht ganz so scharf (das ist normal) Unsere Straßen haben aber halbwegs weiche Ränder.

[JOBIA]

Schauen wir uns exakt die selbe Stelle mit der AROE an.

[JOBIA]

Leider sind die Defaultstraßen so ungenau, dass keine direkten Vergleiche möglich sind. Wir sehen oben links eine Ecke eines Autobahnkreuzes. Realistische Radien bei den Autobahnabfahrten der AROE. (Gibt es im Default FS schon mal garnicht). Die Straßentexturen oben links sehen bei der AROE realistischer hinsichtlich Farbgebung und Struktur im Gegensatz zum Einheitsgrau der Defaulttexturen aus. Besser wirkt das dann, wenn man sich mehr von der Erdoberfläche entfernt. Noch etwas schönes kann man erkennen. Die rechte und linke Spur der Autobahnen entfernen sich im Bereich des Autobahnkreuzes etwas. Genau so wie man es in der Realität oft vorfindet.

Weiterhin sehen wir auch sehr schmale Straßen. Genau bei diesen tritt die Problematik ein, dass sie unscharf und manchmal aus nächster Nähe etwas fransig wirken. (wir befinden uns bei den Screenshots nahe an der Erdoberfläche) Wer mal im unteren Bereich ganz genau hinschaut wir feststellen, dass diese Fransen bei senkrechten (nordsüdgerichteten) Straßenstücken fast verschwinden, da sehen auch kleinere Straßen gut aus. (gilt auch für waagerechte Stücke westostgerichtet)

Man sollte ruhig mal einen Blick auf die Landclassbodentexturen richten. Man wird erkennen, wie breit real die Straßenzüge in den Luftbildelementen der Landclasstexturen sind (bei den Häusern und Feldwegen schauen). Da passen die AROE Straßen vom Maßstab sehr gut. Die Default FS2004 VTP Straßen (siehe der Screenshot zuvor) speziell alles unter der Kategorie Autobahn sind viel zu breit. (nicht jede Bundes/Landstraße hat solch extreme Breiten)

Wir sehen schon, die AROE arbeitet auch hinsichtlich Straßenbreiten sehr real.

Kommen wir jetzt zu dem eigentlichen Problem.

Ich erwähnte, dass nur unsere Straßen in VTP Technik meshkompatibel sind. Jeder andere Code würde optisch hinsichtlich Texturen vor sich hinflackern, in der Luft schweben oder im Boden versinken.

Man kommt nicht drum herum. Soll die AROE europaweit kompatibel zum FS sein, muss sie VTP Technik nutzen.

Damit gilt leider, dass die Bodenauflösung nie besser ein Pixel ca. 4,7m x 4,7m werden kann. So manch kleinere Straße ist real noch nicht mal 4,7m breit.

Der Default FS ignoriert das mit seinem Code und den zugehörigen Texturen einfach.

Nun ist es so, dass jede Textur die wir auf die Erdoberfläche aufbringen wollen Bezugspolygonflächen benötigt.

Ich zeige daher jetzt für obige Screenshots mal die Polygonmodelle. (jede 3D Oberfläche die später mit Texturen beklebt wird, setzt sich in der Regel aus vielen dreieckigen Einzelpolgonen zusammen)

Am besten man hält alle Bilder geöffnet zwecks besseren Vergleichs.
Wir sehen das Polymodell der Defaultstraßen

[JOBIA]

Die komplette Polygonfläche wird normalerweise mit einer Textur verkleidet. Der Anwender soll ja vereinfacht gesagt keine Polygonmodelle sondern eine normale Oberfläche sehen.

In der Mitte die rote Linie ist sozusagen die Mittelline des Straßencodes. Dunkelblau sehen wir die Polygondreiecke die unsere einspurig wirkende Bundesstraße definieren. Hellblau sehen wir die Polygondreiecke der Autobahnen. Wir sehen auch, es sind überhaupt keine zwei Spuren wie im Screenshot mit den Defaultstraßen vorhanden. Beide Fahrspuren werden durch eine Polygonfläche definiert.

Wie geht das?

Des Rätsels Lösung ist die Straßentextur, die später diese Polygonfläche verkleidet. Diese spezielle Linientextur ist im Prinzip nur eine Texturfläche. Sie hat zwischen Ihren beiden Fahrspuren einen Alphakanal also Transparenz definiert. Mit anderen Worten der Polygoncode wird nur mit einer einzigen Textur verkleidet die in der Mitte einen durchsichtigen Schlitz hat, wo man dann die darunterliegende Landclasstextur durch sehen kann. Es wirkt dann wie zwei Fahrspuren.

Anders sieht das bei der AROE aus.

Der Polygoncode der AROE

[JOBIA]

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.

[JOBIA]

Breitere Straßen also breiterer VTP Polygoncode bei den Default FS Straßen bietet natürlich größere Chancen, dass auch graue Straßenpixel auf der Erdoberfläche zur Anwendung kommen.





Der AROE Screenhot.

[JOBIA]

Wir sehen schmaler VTP Polygoncode bei Straßen bietet weniger Chancen auf Pixeltausch. Des öfteren bleibt auch ein grünes, braunes, ..... Landclasstexturpixel erhalten.

Das diese durch FS Terraintechnik bedingte Geschichte dem Anwender nicht so auffällt hängt mit der Texturfilterung zusammen. Weiterhin kaschiert der FS mit einer besonder Rauschüberlagerung.

Ahnlich dem Platzhalterverfahren für Pixel ist das übrigends bei der im FS2004 neu eingeführten Meshkomponente von VTP Code. Der VTP Code kann das Höhenmodell nur im Raster des Terrainpolygonmodell beeinflussen. Zu dieser ganzen Terrainpolygonmodellgeschichte kann man mehr irgendwann in meiner Doku lesen.

(Habe leider momentan so gut wie keine Zeit mehr für den FS)

Das erklärt übrigends auch das Verhalten von sogenannten VTP Exclude Code.

VTP Exclude Code ist nur auf diesen Tauschvorgang der Texturpixel möglich, der wird unterbunden. Die Beeinflussung des Terrainpolygonmodell leider nicht. Denn das muss aufgebaut sein bevor Texturen aufgebracht werden. Das ist meiner Meinung nach auch der Grund warum man z.B die Abflachungen von unseren VTP Linienstraßen im momentanen Zustand des FS nicht excludieren kann. Wir müssen zwecks kompletten Excludes das Laden des VTP Codes im Vorfeld verhindern durch deaktivieren der Dateien oder wir müssen global die Meshkomponente abschalten.

Auf jeden Fall dürften diese Bilder und der Text sehr gut erklären warum gewisse Stellen des Straßencodes der AROE kritisiert werden. Nur es ist nicht gerechtfertigt, es ist kein AROE Problem sondern ein FS Problem.

Hat man einen schwachen PC so das des öfteren minderwertige MIP Level zum Einsatz kommen, dann ist es ein PC Problem des Anwenders.

Das Problem hätte man nur durch breiteren Polycode bzw. breitere Straßentexturen minimieren können.

Ev. wäre man in den Bereich gekommen das eine Programmierung anhand GPS Daten nicht möglich ist.

(siehe Einzelspuren der Autobahn. Bei zu breiten Polycode gäbe es ev. zu starke Überlappungen der Texturen)


Das hätte weiterhin am Realismus geknabert. Kleinere Straßen hätten sich aufdringlich in die Scenery gedrängt (wir hätten eine unrealistische von grauen Linien überflutete Erdoberfläche).

Übrigends die Straßenzüge die in den Landclasstexturen selbst abgelegt sind unterliegen fast den selben Einschränkungen.

Wenn man bei AROE kritisiert, dann muß man eigentlich den ganzen FS kritisieren.

Ich hoffe mit diesem Text Aufklärung zur Thematik geliefert zu haben.

Man muss bei dieser Thematik eindeutig Kompromisse eingehen. Mir persönlich ist der Weg den man bei AROE gegangen ist lieber, als zu breiter Polycode inkl. zu breite Straßentexturen.

[Manna]

Danke Joachim,

ich finde Du hast Dir ja unheimlich viel Arbeit mit der Analyse der Probleme gemacht. Eine derartige Analyse hätte ich eigentlich von den Herstellern der Software erwartet, schließlich bekommen sie ja Geld für ihr Produkt. Danke noch mal für die große Mühe die Du Dir mit den Erklärungen gemacht hast.