Zusi-Forum

Mipmaps sollte ich eigentlich schonmal irgendwo erklärt haben - konnte aber gerade nichts finden. In Kürze: Eine Textur wird nicht nur in ihren Original-Maßen bereitgehalten, sondern auch in kleineren Abmessungen, also z.B. 512x512, 256x256, 128x128 usw. bis 1x1
Wenn die Pixel auf den Schirm gezeichnet werden, ermittelt DirectX automatisch, welche Textur gerade am besten zur Darstellungsgröße des Dreiecks paßt und holt seine Farbinformation aus dem entsprechenden Mip-Map-Level. Vorteil: I.d.r. bessere Darstellung, da weniger Aliasing-Flickern durch übermäßige Skalierung auftritt und wohl etwas bessere Performance, da bedarfsweise kleinere Texturen zum Einsatz kommen.

Bei Gelegenheit werde ich das Thema noch etwas erweitern, im Moment sei aber erstmal auf ein "Abfallprodukt" des Mipmappings verwiesen, angeregt durch das hier:
http://zusiforum.eisenbahn-seiten.de/vi ... php?t=6730


Man sieht einem Objekt auf dem Bildschirm nicht ohne weiteres an, welche Mipmap-Stufe für welche Pixel verwendet wird. Durch eine speziell präparierte Textur läßt sich das ändern. Diese Beispieltextur wurde aus unterschiedlich gefärbten Mipmapleveln von Hand zusammengesetzt (das TextureTool aus dem DirectX-SDK ermöglicht das).
Durch die Verwendung markanter Farben sieht man so auf den ersten Blick, welche mipmap-Stufe zum Einsatz kommt. Hier zunächst ein Screenshot der Miniaturvorschau im Explorer, um die Farben den Auflösungen zuordnen zu können (die 8x8 ist weiß).



Wenn man den E-Wagen vom Andi "Funki" dann mal im Mesh-Viewer lädt und in durchaus respektabler Größe auf den Schirm bringt (immerhin 600x600 Pixel und damit größer als praktisch alle Führerstands-Fenster), sieht man, daß bereits erhebliche Teile der Wand schon nur noch mit der 128er Textur belegt werden. Nur für die grünen Bereiche wird wirklich die 512er Auflösung benutzt.



Mit dieser Methode kann man recht elegent nach Ressourcenfraß suchen. Wenn also recht nahe Flächen bereits mit niedrigen MipMap-Stufen gezeichnet werden, dann ist hier eine unnötig hohe Texturauflösung am Werke.

Hier die Test-Textur:

http://www.zusi.de/zusi3/512_dx1.zip


Carsten

Ich führe das Thema etwas fort.

Im folgenden Bild sieht man links einen Bahnsteig, der mit der rechts oben eingeblendeten Textur belegt ist. Zu sehen ist die 256er Textur, so wie man sie wohl aus dem Gefühl heraus bauen würde. Beim Laden werden die Mipmaps automatisch generiert.

Der rechte, identische Bahnsteig ist mit der schon bekannten Testtextur belegt (s. ein Beitrag höher).


(klick aufs Bild=groß)

Durch den spitzen Blickwinkel ergibt sich ein Effekt, der mich in dieser Stärke auch überrascht hat. Selbst direkt vor der Lok kommt nur die 32er-Mipmapstufe zum Einsatz. Diese ist übrigens links neben der Originaltextur in ihrer Originalgröße eingeblendet.

Es folgen dann in kurzer Abfolge die 16er, 8er usw. bis am Ende nach bereits wenigen dutzend Metern nur noch die grüne 1x1-Textur zum Einsatz kommt. Diese hat natürlich nur noch einen einzigen Farbwert und damit keine strukturierte Oberfläche mehr. Am linken Bahnsteig erkennt man das analog an der einfarbigen, grauen Fabe (auf Höhe der grünen Fläche am rechten Bahnsteig). Diese graue Fläche wirkt hier sehr unnatürlich, sieht es doch ein einer deutlichen Verfärbung gegenüber den höher aufgelösten nahen Bereichen aus. Grund ist der Automatismus bei der Mipmapgenerierung, welcher einen ungünstigen Farbwert für die 1x1er ermittelt.
Einzige Möglichkeit, hier gegenzusteuern, ist die manuelle Erzeugung der 1x1-Mipmap-Stufe mit dem Texturetool unter Einbau einer besser passenden Farbe.

Zur Klarstellung: Es ist keine Macke von DirectX, daß es schon so schnell quasi untexturiert wird. Diese Erscheinung ergibt sich einfach zwangsläufig aus der Geomtrie. Man kann mit entsprechenden Befehlen die Mipmapgrenzen verschieben (im nächsten Betrachter wird das wohl drin sein) und sieht dann deutlich, daß sich zwar die Mipmap-Übergänge nach hinten verschieben, es aber nicht zu einer besseren Darstellung kommt. Die Fläche ist dann zwar am Ende nicht mehr einfarbig, aber dafür wird sie nach zufälligem Muster mit irgendwelchen Pixeln belegt, was bei Bewegung zu entsprechendem Flimmern führt - Aliasing live eben...

Und noch ein kleine Anmerkung am Rande. Bei dem Güterwagen oben waren die Mipmap-Stufen scharf getrennt, Zusi verwendet hier einen Filter für sanftere Übergänge, was der MS-Meshviewer offenbar nicht macht.

Carsten

Klitzkleine Frage, da auf diese Beiträge bisher keinerlei Reaktion kam: Ist sowas von Interesse, hilft es denjenigen, die sich mit dem texturierten Modellbau befassen? Oder ist es zu speziell bzw. unverständlich? Wenn Fragen bestehen, kann ich gerne versuchen, diese zu klären.
(besteht ja immer die Gefahr, daß man selbst irgendwann so tief im Thema steckt, daß man manches schon als selbstverständlich voraussetzt...)

Carsten

Hallo Carsten,

ist der beschriebene Effekt nicht völlig normal, dass man bereits in kurzer Entfernung die Struktur der Oberfläche nur noch eingeschränkt oder verschwommen wahrnimmt.

Wenn ich mich an Situationen am Dortmunder Bahnsteig erinnere, verwäscht sich die Plattenstruktur der Bahnsteigpflasterung bereits nach einigen Metern.

Ich sehe denn Effekt als unkritisch an.

Wie sehen es denn unsere Vielreisenden, wie Michael P. zum Beispiel ?

tschüs...

Jürgen aus Dortmund

Jürgen_Verheien hat geschrieben:Ich sehe denn Effekt als unkritisch an.

Ich glaube, du hast Carstens Botschaft missverstanden. Es geht nicht um ein Problem, sondern darum, dass man als Modell- oder Streckenbauer die Texturgröße nicht übertreiben muss, weil sie ab einer bestimmten Größe grundsätzlich runtergerechnet werden.
Ich finde das durchaus beachtenswert.

Mir ging's überhaupt erstmal darum, ob Verfahren (und am Ende dann natürlich auch die Konsequenzen) verstanden werden und jemanden interessieren.

Carsten

Hallo,

ich muss zugeben, dass ich den Sinn des bunten Güterwagens im ersten Beitrag nicht so recht verstanden habe. Ich wollte mich auch nicht outen
Für mich klingt das irgendwie logisch und unlogisch zu gleich. Direct X versucht Speicher und Rechenzeit mit kleineren Texturvarianten zu sparen. Ok, sehe ich ein. Aber wenn ich 3 verschiedene Texturen benutze, muss ich doch immer damit rechnen, dass es aussieht, als hätte ein schlechter Tapezierer drei verschiedene Tapetenbahnen aneinander geklebt. Für mich wäre es logischer, wenn der 1. Wagen mit 512x512, der 2. Wagen (da weiter entfernt) mit 128x128, der 3. Wagen mit 64x64 usw. beklebt würde. Aber ich muss es ja nicht logisch finden

Man sieht an den Beispiel mit dem Bahnsteig, dass riesige Texturen nicht immer sinnvoll sind, da sie eventuell garnicht dargestellt werden (können). Den linken Bahnsteig mit den Abstufungen finde ich auch nicht sehr schön.
Das alles klingt nach noch mehr Arbeit, wenn man für jede Textur auch noch 3-4 kleinere Varianten erstellen kann/darf/soll.

Mal eine kleine Verständnisfrage am Rande. Ich habe eine Textur mit 256x256. Was passiert wenn eine Fläche mit z.B. 50x32 Pixel texturiert werden soll ? Nimmt dann Direct X einfach die 32x32 Pixelvariante und zerrt die entsprechend passend auf die Fläche hin ?

Da ich nicht mal sinnvoll mit dem Gebäude-Eddi umgehen kann (hab irgendwie kein 3D-Vorstellungsvermögen), versuche ich eh ums Objektebauen für Zusi 3 rumzukommen und hoffe der neue Gleiseddi trifft meine Wellenlänge.

Ciao Michael

Michael Springer hat geschrieben:Für mich wäre es logischer, wenn der 1. Wagen mit 512x512, der 2. Wagen (da weiter entfernt) mit 128x128, der 3. Wagen mit 64x64 usw. beklebt würde. Aber ich muss es ja nicht logisch finden

Da der Wagenanfang des 2. Wagens näher am Wagenende des 1. Wagens liegt als das Wagenende des 1. Wagens vom Anfang des 1. Wagens entfernt ist, ist das nicht unbedingt logisch, solange die Übergänge nicht sprunghaft verlaufen (was laut Carsten[siehe: "Bei dem Güterwagen oben waren die Mipmap-Stufen scharf getrennt, Zusi verwendet hier einen Filter für sanftere Übergänge..."] wohl nicht er Fall sein wird).

Christoph

Also von Interesse ist das schon, allerdings z.Zt nur für Erbauer aus der Fahrzeugecke mangels Anwendbarkeit. Ich vermute das viele Streckenbauer z.Zt mehr an der Strecke Arbeiten, und erstmal da drauf warten, was die Konvertierung her gibt.

Ich persönlich werde dann auch erstmal den Schwerpunkt auf die Streckenfunktion legen, und dann auf die Landschaft.

Der run wird dann kommen, wenn die erste Beta da ist (So es Sie gibt), und die Verständnissfragen kommen.

Also ruhig die Info veröffentlichen, auch wenn "Andächtiges Schweigen" folgt

Hier war ja der Güterwagen, wie er nachher wirklich aussieht, also mit sinnvoll gestalteten Mipmaps:

http://zusiforum.eisenbahn-seiten.de/vi ... 721#127721

Da sieht man nichts zwischen den Übergängen.

Wenn man sich noch einmal an das Grundprinzip des Rendervorgangs erinnert (http://zusiforum.eisenbahn-seiten.de/vi ... php?t=6542), dann kann man dort auch das Problem ausfindig machen.
unter 2.b steht Farbwert des Pixels bestimmen, indem entsprechend je nach Abstand zwischen den Farbwerten der drei Vertices interpoliert wird und zusätzlich die entsprechenden Texturinformationen hinzugezogen werden
Knackpunkt ist hier die Texturinformation. Man muß dafür immer vom Pixel auf dem Bildschirm ausgehen, also der texturierungsvorgang geschieht im 2D. Die Fragestellung ist also: DX will z.B. das Pixel x=623/y=335 auf den Bildschirm malen - welche Farbe liefert die relevanten Textur für dieses Pixel? Dafür wird jetzt innerhalb des zugehörigen Dreicks und mit Hilfe seiner Texturkoordinaten der Punkt auf der Textur bestimmt, der die Farbinfo liefern soll. Jetzt nehmen wir mal ein Dreieck am Ende des Bahnsteigs, das mit vielleicht mit den Kantenlängen 5/4/3 Pixel auf dem Bildschirm liegt. Ohne Mipmapping wäre die Textur 256x256 Pixel groß. Jetzt greift der Algo an der errechneten Stelle in diese große Textur und erwischt je nach numerischem Zufall gerade ein Pixel auf dem hellen Pflasterstein oder eines auf der dunklen Fuge. Unser Pixel wird also andauernd zufällig heller und dunkler - und wenn das alle machen, flimmert es wie Hölle.

Nun hat DX zwar einen Texturfilter, man greift also nicht ein einzelnes Pixel aus der Textur sondern betrachtet die Pixel rundrum und interpoliert, aber das hilft nur, solange die Pixelabmaße der Textur in etwa so groß sind, wie das zu zeichnenden Dreieck (in Pixeln auf dem Bildschirm).

Bei meinem Beispiel mit 256er Textur auf 4x5-Dreieck hilft kein Filter.

Darum also in erster Linie das Mipmapping. DX ist so in der Lage, für jedes Dreieck oder besser jedes einzelne Pixel die optimal passende Texturgröße zu benutzen.

Das alles klingt nach noch mehr Arbeit, wenn man für jede Textur auch noch 3-4 kleinere Varianten erstellen kann/darf/soll.

In der Regel erstellt man nur die Textur in der Ausgangsgröße und läßt die einfacheren Mipmaplevel autom. berechnen. Nur wenn das zu Artefakten führt, muß man ggf. Mipmaps korrigieren.

Mal eine kleine Verständnisfrage am Rande. Ich habe eine Textur mit 256x256. Was passiert wenn eine Fläche mit z.B. 50x32 Pixel texturiert werden soll ? Nimmt dann Direct X einfach die 32x32 Pixelvariante und zerrt die entsprechend passend auf die Fläche hin ?

ja, so etwa - also es nimmt (für jedes einzelne Bildschirmpixel) die Textur, für die gerade am wenigsten zu skalieren ist.

Der farbige Güterwagen ist nur ein kleiner Trick, um überhaupt mal sichtbar zu machen, wie das Mipmapping arbeitet.

Carsten

@Ralf: hat sich überschnitten, ich mache noch einen 2. Thread auf.

Edit: Diese Effekte lassen sich übrigens alle auch im Betrachter testen, erst recht, seit die fahrbare Kamera drin ist.

Carsten

Mal eine Frage:

Wie wirkt sich eigentlich "Anisotrope Filterung" auf diesen MipMap-Effekt aus?

Die Auswirkungen konnte ich gut bei TRS beobachten... vorher, also bei ausgeschalteter Filterung, verschwomm eine weiße Bahnsteigmarkierung nach wenigen Metern aus der Fst-Perspektive zu einer undefinierbaren weißen Brühe auf dem Bahnsteig. Nach einschalten der Filterung, auf 8-fach, bleibt die Linie auch bis auf etliche hundert Meter klar und deutlich eine Linie...
"Moderne" Garfikkarten unterstützen sowas ja eigentlich mittlerweile standartmäßig, "nicht-so-ganz-alte" Garfikkarten, wie meine GeForce4, kann man ja mittels Treiber-Aktualisierung mit dieser Einstellungsmöglichkeit nachrüsten...

Gruß

Andreas

Andreas (Funki) hat geschrieben:Wie wirkt sich eigentlich "Anisotrope Filterung" auf diesen MipMap-Effekt aus?

Und meine Frage dazu: was ist Anisotrope Filterung?

M.f.G. Christian

Christian Gründler hat geschrieben: Was ist Anisotrope Filterung?

Verbesserte Bildqualität auf Kosten der Leistung.

Christian Gründler hat geschrieben:

Andreas (Funki) hat geschrieben:Wie wirkt sich eigentlich "Anisotrope Filterung" auf diesen MipMap-Effekt aus?

Und meine Frage dazu: was ist Anisotrope Filterung?

Eine spezielle Technik moderner Grafikkarten, die Texturen über den Bereich einer Fläche hinweg verschieden stark zu filtern, damit Flächen, die "streifend" gesehen werden (z.B. Boden, Seitenwände) nicht matschig wirken.

Thomas Gabler hat geschrieben:Eine spezielle Technik moderner Grafikkarten, die Texturen über den Bereich einer Fläche hinweg verschieden stark zu filtern, damit Flächen, die "streifend" gesehen werden (z.B. Boden, Seitenwände) nicht matschig wirken.

Alles leider noch etwas unklar; gibt es evtl. Beispielbilder für diesen Effekt?

M.f.G. Christian

Wenn Du Die Texturfilter meinst, die kannst Du selbst testen. Ojekt als ls3 importieren und dann in den Mesh-Einstellungen den Texturfilter auf "Anisotrope Filterung" einstellen (hab's noch nicht verglichen)

Carsten

Hier ein Beispielbild:


*Edit*
Hier zwei Beispiele aus einem Spiel:
ohne aniso-Filter
mit aniso-Filter
(man betrachte den Fußboden im hinteren Bereich)

Das ist der Filter, den man auch im Betrachter einstellen kann. Sollte dann auch das gleiche Ergebnis liefern, macht ja die Grafikkarte/DirectX.

Carsten

Thomas Gabler hat geschrieben:Hier ein Beispielbild:

Hallo Tom,

dies abstrakte Beispiel gefällt mir besser als die anderen Bilder...

Es geht also um eine Schärfung der Konturen, und was dabei anisotrop ist, verstehe ich jetzt auch - es ist immer ein Vergnügen, von Dir (im besten Sinne des Wortes) belehrt zu werden .

M.f.G. Christian