Hallo Wolfgang,

Das sind keine Texturfehler, sondern Meshfehler, die durch den Schattenwurf hervorgehoben werden. Slew mal auf Wasserhoehe und du wirst feststellen, dass der Rhein auf das Gelaende "aufgeklebt" ist und nicht horizontal oder geneigt geglaettet ist. Der Mississippi dagegen ist vermutlich auf eine bestimmte Hoehe gesetzt (Flatten) und hat daher keinen zusaetzlichen Schattenwurf auf dem Gewaesser.

Soweit ich weiss, ist das (mesh clinging) bei allen AROE Fluessen der Fall. Ultimate Terrain Europe bietet einen alternativen Modus an, wo die Fluesse geflattet sind, aber das kann dann andere Probleme bereiten, wie "Aquaedukte" oder "Canyons". Der ideale Weg ist, Fluesse als LWM3 Polys zu erstellen, d.h., mit geneigten Flaechen, aber das gibt es, soweit ich weiss, fuer Europa nicht.

Ciao, Holger

Zu

Ok, wenn Du das meinst.

Aber Du hast zuvor geschrieben:

"Nunja, das ist ein Problem, welches mit dem Nachladen der Texturen zu tun hat und weniger mit dem Wasser."

Diese Antwort bezog sich auf die farbige Geländekante die ich in Deinem Bild erkennen konnte. Die hat aber wie gesagt nichts mit Nachladen von Texturen zu tun wie ich oben schon erwähnte.

Hier sehen wir eindeutig das vereinfachte Weltmodell.

Erkennbare farbige Übergänge wirst Du nicht in Zusammenhang mit Nachladen von Texturen in Verbindung bringen können.

Ev. wird es klarer, wenn ich morgen früh auf Wolfgang seinen Beitrag antworte.

Habe jetzt keine Zeit mehr.

Zu

Habe mal Nummern in Deinem beitrag eingefügt auf die ich antworten will.

Fange mal willkürlich an.

Zu 8) Hat Holger schon was geschrieben.


Zu 7) Ja das ist in der Tat so, da diese Verfahren Wellengang zu simulieren über ein spezielles Verfahren mit Texturen arbeitet die nacheinander durchlaufen werden. Man kann nicht einfach wie das manche Gewässertexturproduzenten machen irgendwelche Wellenfotos nehmen und daraus so einen Set erstellen. Dann passt das nicht mit dem optischen Ablauf und es kommt immer rhytmisch zu diesem Effekt.


Zu 6)

Auch korrekt, da sind sehr viele Abläufe und Texturen in dieses Verfahren mit eingebunden.

Teilweise werden von machen Addons auch nur teilweise Änderungen durchgeführt. Man wollte ev. nur Änderungen an den Reflektionen die Gewässertexturen selbst wollte man nicht antasten.

Man geht hier vom Default Zustand aus.

Nur der ist ev. nicht mehr vorhanden, so das es jetzt optisch nicht mehr passt.

Oder was es auch oft gibt. Es wird alles komplett angeboten, aber in manchen Bereichen bietet jemand anderes etwas besseres an, was man aber nicht nutzt, da man nur dieses ein Packet nutzt wo ein Eelement nicht so gut ist.

So kann in der Summe hinten ein schlechtes Endergebnis haben.


5 lasse ich erst mal aus.

Zu 4)

Das entspricht meinem Link zu einem Beitrag aus 2003 den ich zuvor gesetzt hatte. Da ging es um den selben Parameter.

Zu 3)

Ein Problem was man mit Texturfiltern fast nicht in den Griff bekommt.

Hier kann nur der Regler Qualität Mip Zuordnung (MipBias in FS9.CFG)

oder der von Dir erwähnte MipMap Detail Level im Graka Treiber helfen.

Ursache hier feine Strukturen / Linien in den Texturen (z.B. dunkle Fensterfronten)

Wir haben zu wenig Pixel am Monitor zur Verfügung um diese Linien sauber darstellen zu können. Da sie oftmals waagerecht oder nahezu senkrecht verlaufen sind die Linien mal da, dann nicht. Das wäre noch nicht der Effekt. Wenn sie jetzt aber minimal schräg verlaufen, können einige Punkte der Linien dargestellt werden andere nicht. Da kommen dann anders farbige Nachbarpixel zur Anwendung. Da wir uns natürlich bewegen wechselt das ständig. Wir bekommen dann diese Moirée Muster.

Abhiilfe fast nur möglich wenn wir dafür sorgen, dass hier in der Tiefe des Raumes nur sehr minderwertige niedrig aufgelöste MIP Level der Textur zur Anwendung kommen.

Es sind dann nämlich auch nur sehr wenig Texturtexel in der Tiefe des Raumes darzustellen. Weiterhin sind diese gefährlich kontrastreichen Linien in den niederwertigen MIP Leveln selbst nicht mehr enthalten.


Achtung hier hat man hin und wieder Probleme bei Addons. Sie haben ein Texturformat gewählt welches MIP Level blockt. Dann reagiert diese Textur nicht auf solche Regelelemente wie MipBias.

Dann müsste man erst das texturformat ändern damit es geht.



Zu1

Du kannst jetzt MIP Stufe 1 ohne Qualitätseinbußen nutzen, was vorher nie ging. Ich vermute mal diese Aussage ist jetzt auf Bodentexturen bezogen.


Hier ist es in der Tat so, dass der Parameter MipMap Detail Level: im Grafikkartentreiber so etwas macht wie der Regler Qualität Mip Zuordnung (MipBias in FS9.CFG)

Von daher kann dieses einer der Gründe sein, warum Du jetzt bei Mip Stufe 1 noch ausreichende Qualität hast.

Ein weiterer Grund dafür kann auch Punkt 2) sein.

Der Grad der anisotropischen Filterung kann bei diesem Treiber ganz anders ausgelegt sein.

Das Bewertungsfenster ist mit 16x sehr hoch, geht also generell ziemlich tief in den Raum.

Weiterhin ist trilineare Filterung dazu gekoppelt.

Gerade bei den Texturfiltern backen viele Ihre eigenen Süppchen. So ist z.B 16x nicht immer mit 16x eines anderen Treibers vergleichbar.

Von daher liegen hier viele Qualitätsunterschiede vergraben. Im Gegenzug aber auch oft Performanceunterschiede.

Zu 5)

Hier zunächst ein Dokubild im Anhang. Am besten öffnen und nebenher geöffnet lassen.

Wichtig ist nur die linke Hälfte des Bildes. Sie zeigt uns eines der beiden vereinfachten Weltmodelle des FS2004 aus der Vogelperspektive.

Es handelt sich hierbei um das vereinfachte Weltmodell um das es vorher ging.

Dieses wird mittels eines speziellen Verfahrens generiert.

Dieses Modell hat keinerlei Bezug zu Texturen mit anderen Worten die Farben der Landmassen und Wassermassen wird nicht mittels Texturen erzeugt. Die Farben sind programmierter Code, sprich Bytes. Man sieht, es gibt auch hier farbige Variationen bei den Gewässern.

Was für eine farbe genutzt wird, hängt zusätzlich davon ab, welche Waterclassnummer im Default FS Waterclassfile definiert ist.

Man könnte also auch sagen, jeder Waterclassnummern ist per Code eine Farbe zugeordnet die dann im vereinfachten Weltmodell gezeigt werden soll.


Im Nahbereich sieht es etwas anders aus. Hier sehen wir richtige Waterclasstexturen. Hier ist es so das jeder Waterclassnummern eine Waterclasstextur zugewiesen ist.

Da kommen dann noch solche Geschichten wie Wellengangüberlagerung usw. dazu.

Im default FS ist es so, dass Microsoft die programmierten Farben des vereinfachten Weltmodells in der Summe an Ihre Waterclasstexturen usw. angepasst bzw. optimiert haben, so das es möglichst geringe Farbunterschiede gibt.


Texturdesigner haben aber keinen Zugriff auf die programmierten Farben des vereinfachten Weltmodells.

Wenn sie also Ihre Gewässertexturen in einer anderen Farbe als Microsoft erstellen, dann weichen die von denen des vereinfachten Weltmodells ab. Dann haben wir exakt diese harten farbigen Übergänge wie in den Screenshots zuvor.

Das es auf der Erde immmer schwankt und variieren kann, sollte auch klar sein. Wir haben wie man in meinem Bildanhang zuvor sehen kann, je nach zur Anwendung kommenden Waterclass verschiedene Farben auch im vereinfachten Weltmodell.

Jetzt kann es gut sein, dass bei einem Addon eine Textur zu einer Waterclassnummern X farblich nur geringfügig von der Default Textur abweicht. Wir werden kaum farbigen Übergänge zum vereinfachten Weltmodell haben.

Bei einer Waterclassnummern Y hat man die zugehörige Waterclasstextur farblich stark abweichend zur Defaulttextur erstellt.

Dann fällt es stark auf.

Nun wird man je nachdem wie die weltweite Waterclassverteilung ist Gegenden haben wo es mal stark abweicht und dann mal wieder nicht.


Es gibt im FS2004 60 Waterclassnummern siehe auch meine Landclass Steuertabellen.

Also auch 60 Waterclass Texturen. Jetzt kommt es halt darauf an wie diese 60 von den Defaulttexturen abweichen und wo auf der Welt sie zur Anwendung kommen.

Bleibt das im FSX auch so, mit dem Waterclass am vereinfachten Weltmodell? Denn das schränkt doch ziemlich ein bei neuen Texturen. Wäre es da nicht möglich, eine kleine MipMap der neuen Texturen für das vereinfachte Weltmodell zu nutzen?

Hallo Jobia (und alle anderen),

erst mal vielen Dank für deine ausführliche Antwort.
Gut zu wissen, daß meine "Probleme" weniger hausgemacht denn systembedingt sind. In FS-Sachen nicht ganz unbewandert (bin seit dem FS3 dabei, stehe also altersmäßig kurz vor dem Zwang zur Umetikettierung) hab' ich mir das schon gedacht, aber man wird angesichts vieler (und wie man manchmal zu spät merkt: weniger fundierter) Tipps und Beiträge in anderen Foren - irgendwann doch unsicher.
Mein Fazit: Wenn man aus einem programmiertechnisch schon nicht ganz schlichten Ausgangsprodukt immer mehr und meistens auch etwas erheblich Besseres macht, muß die Sache ja irgendwann an ihre Grenzen stossen. Da gibt's zum einen die qualitativ einwandfreien AddOns, die wirklich einen "Boah-Effekt" auslösen, andererseits die vielen kleinen Versuchungen, denen man immer wieder "ausgesetzt" wird: Man sehe sich nur die dowloadzähler bei Angeboten wie "new water textures", "improved autogen for xy", "replacement textures for xy" etc. an. Das zeigt zum einen das große Bedürfnis der Anwender, die Optik möglichst real zu haben - ein verständlicher Wunsch - wobei aber "real" immer eine sehr subjektive Kategorie ist: Der eine empfindet seine neuen Wassertexturen als das Nonplusultra, während das Auge des anderen ebendiese als zu dunkel, zu grau, zu grün oder was auch immer findet (siehe hierzu die Reaktionen auf das Farbdesign im neuen FSX).

Die Zahl der Downloads zeigt aber auch noch etwas anderes: Multipliziert man den Downloadzähler mit der Anzahl der gängingen Prozessor-, GraKa- und Treibervarianten, potenziert mit der Anzahl der bereits installierten AddOn's und nicht gelöschter Dateireste früherer Installationen, so kommt man quasi auf die Zahl der möglichen Fehler und damit auch wiederum auf die Zahl der Lösungsmöglichkeiten. Alles klar?

Jeder Simmer, der über das Stadium "C172-im-Standardflug-rund-um- Meigs" hinaus ist, kann sicher fundiert an einer philosophischen Diskussion um die Aspekte des "Spiels" MSFlugsimulator teilnehmen: Ein paar Wochen fliegt man standard-a/c's IFR, dann lädt man sich Unmengen von Flugzeugen auf die Platte und bastelt begeistert an deren Panels rum. Danach ein paar Wochen VFR - nun möchte man die Landclass rund um seinen Heimatort möglichst real haben und probiert nächtelang alle möglichen Tools dafür aus um nach weiteren Wochen zu erkennen, daß Szeneriedesign schwer frustrierend sein kann. Deshalb kauft man sich eine fotoreale Szenerie, ist gewaltig begeistert, nur um früher oder später - je nach Jahreszeit des Kaufdatums - festzustellen, daß es a) hier abends stockdunkel wird und b) der Winter nie kommt. Nächste Spielphase: Autogen für fotoreale Szenerie erstellen oder downloaden (Mein absoluter Respekt gilt den schweizer Simmern und deren Arbeiten dazu). Da mittlerweile die sozialen Kontakte nur noch rudimentärer Art sind, widmet man sich folgerichtig dem online-Fliegen und lädt dafür zunächst die Unmengen an notwendigen AI-Aircrafts nebst diversen "must-haves" runter. Spätestens jetzt ist dann die Kapazität der Festplatte am Ende - also bei dieser Gelegenheit gleich einen neuen Rechner kaufen und bei Phase 1 beginnen.


Okay: Das ist kein technischer Beitrag mehr, der dem Ausgangspost folgt, mehr eben eine ironische Betrachtung des Hobbies (Hobby??).
Aber diese drängte sich auf, nachdem ich die Werte aller TERRAIN-Parameter der fs9.cfg bald schneller hersagen konnte als die Vornamen meiner Kids, obwohl die Anzahl letzterer deutlich geringer ist als die der ersteren (thnx god!)

Auf jeden Fall Dank an die unzähligen kompetenten Simmer, die im Hochmoor der cfg-Dateien ständig neue Irrlichter entdecken, diese enträtseln und dann doch tatsächlich eine weitere und deutliche Verbesserung der FS-Darstellung bzw. des "Spielablaufs" ermöglichen.

Ich bin auf die ganze Problematik eigentlich so richtig erst seit der Installation der SwitzerlandProfessional gestossen - au weia, höre ich viele sagen. Richtig: Denn der Ehrgeiz, diese müsse doch auf einem nicht ganz schlappen System zünftig ablaufen, führte zu zahllosen Forenbesuchen und noch zahlloseren Downloads und Tweaks. Ein paar waren sehr gut, viele brachten gar nichts und nur die wenigsten waren nachteilig. Leider habe ich inzwischen so viele Backups von cfg- und Texturdateien wie es vermutlich Kühe in der Schweiz gibt und die Dateien sind - um beim Bild zu bleiben - alle ziemlich gleich gefleckt ;-)


Im Ernst und zum Schluß:
1. Dank dieses Forums ist mir (wieder) bewusst geworden, daß es eben unverückbare Grenzen im FS gibt (wörtlich wie im übertragenen Sinne). Man kann sich das zwar denken, vergisst es aber immer wieder angesichts der überwiegend unglaublichen Realitätsnähe, die oftmals möglich ist (FlyTampa!)
2. Hurra - ich bin mit den Problemen nicht alleine. "Intelligence inside - idiot outside" gilt nicht immer.
3. Wenn man lange genug sucht und irgrndwann die Spreu vom Weizen der Postings trennt, sind frappierende Verbesserungen möglich (siehe mein Beitrag zum Thema "Omega").
4. Fast alles gilt aber zunächst immer nur auf dem eigenen System und ist nicht ohne weiteres als generelle Empfehlung für alle Simmer multiplizierbar - Ausnahmen bestätigen die Regel.

Ich werde mich jetzt der völlig vernachlässigten Frage widmen, inwieweit unterschiedliche Mengen von Staub im PC-Lüfter die Darstellung der Berge im FS beeinflussen :-)))

Nein, war natürlich ein Schmarrn - Danke für eure Antworten: Sie waren entweder direkt bei der Problemlösung behilflich oder haben mich auf Seiten gebracht, die dann widerum weiterhalfen.

Last but not least: Wie auch immer der FSX auf den Markt kommen wird - das Internet wird um unzählige Textbeiträge wachsen, denn dem "Neuen" stehen ja all die eingangs erwähnten "Spielphasen" erst noch bevor - den virtual pilots auch :-))

Always three greens!
Wolfgang
5mls south of TULSI

Sehr, sehr schöner Beitrag Wolfgang er trifft den Nagel auf den Kopf. Genau so sieht es bei fast allen von uns aus.






Zu itsimon

Es gibt da ein paar Problemchen warum es nicht so einfach ist.

Bei einer DXT1 Textur hat der kleinste MIP nur noch 4 x 4 Pixel. Die Basistextur im Vordergrund hat 256 x 256 Pixel. Da die Basisinformation 256 x 256 Pixel für den letzten Mip auf 4 x 4 Pixel reduziert werden muss, ist dieses schon ein extremes Verhältnis.

Denn es bedeutet aus allen diesen 256 x 256 Pixeln muss man für die Tiefe des Raumes Farbwerte für 4 x 4 Pixel finden die unsere Basistextur mit 256 x 256 Pixeln repräsentiert.

Nicht einfach.

Aber es kommt noch dicker. Um den Bereich des vereinfachten Weltmodells mit MIP Leveln zu versorgen, würde der FS2004 gemäß momentaner Programmierung der Terrain Engine MIP Level benötigen die unter 4 x 4 Pixel liegen genau genommen sogar unter 1 x 1 Pixel, was ja nicht geht.

Der Vorteil beim vereinfachten Weltmodell ist auch, dass es keine Terrainsteuerdateien benötigt.

Beim FSX ist es ingesamt etwas anders.

(kann natürlich nur die Demo beurteilen, da ich kein Betatester bin)

Aber hier hat man als Basistextur 1024 x 1024 Pixel. Zwei Mips mehr.

Da hat man auch mehr zum rechnen in der Tiefe des Raumes.

Leider ist die Demo flächenmäßig sehr klein. Aber ich habe kein vereinfachtes Weltmodell mehr gesehen.

Habe aber aus Zeitgründen auch nicht weiter getestet, da es keinen Sinn macht, weil die Doku in der Fläche begrenzt ist, ich keine neuen SDK Tools habe. Die Betatester haben es da besser, sie haben nicht nur eine Beta sondern auch schon zumindest teilweise die SDKs und SDK Tools.

Sie können schon probieren.


Wie gesagt was ich momentan ohne Tests sehen kann, würde ich sagen gibt es das vereinfachte Weltmodell nicht mehr, was bedeuten würde, diese Probleme könnten behoben sein.

Das wäre sehr positiv im Sinne der Tauschtextur Addons. Auch im Sinne von Landclass Addons usw.