Was ist da schief gelaufen?

[Sonyfreak]

Die folgenden 2 Screenshots wurden dem Spiel Lineage2 entnommen. Das Spiel lief auf einer Radeon 9000 Mobility mit aktuellen Treibern. Mir ist bei den Bildern aufgefallen, das die Bodentexturen scheinbar nicht richtig gefiltert werden(beim 1.Bild ist mir klar, das sie nicht gefiltert ist). Auf einem anderen Notebook mit Nvidia Grafikkarte war die Textur hingegen korrekt gefiltert. Nun wollte ich fragen was da schief gelaufen ist.
Auf dem 1.Bild ist der im Spiel aus- und einschaltbare Texturfilter ausgeschalten, auf dem 2.Bild eingeschalten.

ausgeschalten
http://img189.exs.cx/img189/8707/ohne2xi.png

eingeschalten
http://img189.exs.cx/img189/6766/mit1in.png

Vielen Dank im Vorhinein!

mfg.

Sonyfreak

[Exxtreme]

Du hast anscheinend den bilinearen Texturfilter deaktiviert. Dann rendert die GraKa nur noch Klötzchentexturen.

[Sonyfreak]

Naja - im Spiel ist nichts ausgeschalten und in anderen Spielen wie UT2003 oder auch Far Cry lieferte das Spiel die korrekte Filterung. Das ist für mich insofern erstaunlich, da UT2003 und Lineage2 die selbe Engine nutzen. Die Filter waren im ATI Treiber auf maximale Qualität geschalten.

mfg.

Sonyfreak

[Demirug]

Bin mir nicht sicher ob ich die Frage richtig verstanden habe.

Beide Bilder sind von der R9000 und auf dem Notebook mit dem nvidia Chip sah es besser aus?

[Sonyfreak]

Auf dem Notebook mit der Nvidia Grafikkarte (420go) war die Textur korrekt gefiltert sofern ich das bewerten kann. Sie war ganz normal Trilinear gefiltert.

mfg.

Sonyfreak

[aths]

Offenbar kann man im Spiel den Texturfilter ausschalten, und hat dann nur Point Sampling.

Wenn ich das noch anmerken darf: Es heißt eingeschaltet und ausgeschaltet - mit t.

[Kampfwurst87]

es gibt mehrere textur modis

die hießen ungefähr so AFAIK:
linear_nearst
linear_linear
nearst_nearst

bei einen der drei kam sollche blockbildung

[Sonyfreak]

Das Spiel wurde aber von dem Laptop mit Nvidia Graka, auf den mit der ATI Graka übertragen. Nachher wurde nichts mehr an den Einstellungen im Spiel verändert. Die Texturen an der Kleidung der Charaktere wurde übrigens auch bei der ATI Karte richtig gefiltert.
Könnte es sich um einen Fehler im Programm handeln, oder ist es irgendein Befehl den die Graka nicht versteht?

mfg.

Sonyfreak

[Maniac16]

Genau die selben Probleme hatte ein Freund von mir mit seiner Radeon 9600Pro. Er hat Counter.Strike auf Lan gezogen und irgendwie kam die Graka net ´damit klar, es hat immer irgendwelche Grafik-Fehler gegeben!!!
Läuft das Spiel vielleicht auf OpenGL??? Wenn ja, dann kann man es mit der Ati9000 vergessen weil die mit OpenGL net klarkommen!!!

[Sonyfreak]

Nein, Lineage2 ist ein DirectX Spiel genau wie UT2003 da die beiden Spiele die selbe Engine verwenden. Aber es ist trotzdem interessant, das die Karte scheinbar noch bei anderen Spielen auch Probleme macht.

mfg.

Sonyfreak

[Neomi]

Auf dem zweiten Bild ist der Filter definitiv an. Es ist zwar sehr grob, aber es gibt doch Zwischenstufen zwischen den Texeln, die in Bild 1 zu sehen sind. Den Effekt kenne ich, das liegt an den Texturkoordinaten selbst.

Als Bodentextur, die wohl sehr große Flächen überspannt, werden die Texturkoordinaten hin und wieder ziemlich groß, falls keine Punkte dubliziert werden, um wieder bei 0 anzufangen. Wenn dann z.B. in einem Dreieck die u-Werte um 8190.0 herum betragen, bleibt als Floatwert (23 Bit Mantisse) etwas in der Richtung 1.999 * 2^12 übrig. Also fallen 12 Bit der Mantisse für den Vorkommateil weg, 11 Bit bleiben für den Nachkommateil. Damit müssen dann noch einzelne Texel adressiert werden. Ist die Textur 512x512 Texel groß, werden demnach von den verbleibenden 11 Bit schonmal 9 für den Vorkammateil des Texels benötigt. Gerade einmal zwei Bit bleiben für den Nachkommateil, um zwischen benachbarten Texeln zu interpolieren. Vier Zwischenstufen sind das. Steigen die Koordinaten über 8192.0 (ich wüßte allerdings jetzt nicht, welche Karte das unterstützt und ob es überhaupt eine tut) oder ist es eine 1024er Textur, bleiben nur noch zwei Zwischenstufen. Allerdings nicht wirklich Zwischenstufen, denn jeder Texel für sich ist ja auch eine. Das Ergebnis sieht dann aus wie Pointsampling bei einer Textur eine Auflösungsstufe höher.

Es sollten im Spiel auch Stellen zu finden sein, an denen die Texturen in einer Richtung sauber gefiltert werden, orthogonal dazu jedoch nicht, da u und v getrennt voneinander interpoliert werden und eine Komponente daher unabhängig von der anderen "entarten" kann.

[Spasstiger]

Läuft das Spiel vielleicht auf OpenGL??? Wenn ja, dann kann man es mit der Ati9000 vergessen weil die mit OpenGL net klarkommen!!!

Was für ein Schwachsinn ...

[Oblivion]

Läuft das Spiel vielleicht auf OpenGL??? Wenn ja, dann kann man es mit der Ati9000 vergessen weil die mit OpenGL net klarkommen!!!


Wo hast den das her?

Jede "halbwegs neue" (alles relativ ;D ) kann OpenGL

[Xmas]

Ich würde auch davon ausgehen dass es an der fehlenden Präzision der Texturkoordinaten liegt. Das erklärt dann auch, wieso es auf dem NVidia-Chip besser aussieht. Der verwendet nämlich FP32 für Texturkoordinaten, die R2xx-Generation nicht.

[Nazar]

Das Spiel wurde aber von dem Laptop mit Nvidia Graka, auf den mit der ATI Graka übertragen. Nachher wurde nichts mehr an den Einstellungen im Spiel verändert. Die Texturen an der Kleidung der Charaktere wurde übrigens auch bei der ATI Karte richtig gefiltert.
Könnte es sich um einen Fehler im Programm handeln, oder ist es irgendein Befehl den die Graka nicht versteht?

mfg.

Sonyfreak

Verstehe ich das richtig?
Du hast "einfach" mal das Spiel "rüberkopiert"?

Wenn ja, dann könnte da schon der Fehler liegen!
Die Engine erkennt bei der Installation die Grafikkartentreiber.... ein einfaches kopieren auf ein System mit gänzlich anderen Treibern "müsste" Probleme geben.. zumindest würde ich da mal nachforschen.

[Neomi]

Ich würde auch davon ausgehen dass es an der fehlenden Präzision der Texturkoordinaten liegt. Das erklärt dann auch, wieso es auf dem NVidia-Chip besser aussieht. Der verwendet nämlich FP32 für Texturkoordinaten, die R2xx-Generation nicht.

So simpel ist das nicht. Diese fehlende Präzision dank hoher Koordinatenwerte habe ich auf einer Radeon 9000 gesehen, alles ab R300 sah aber soweit in Ordnung aus. Auch ATI verwendet FP32 für Texturkoordinaten, solange sie nicht erst im Pixelshader generiert werden. Meine Beispielrechnung mit der Genauigkeit war schon für FP32, um das zu umgehen gibt es andere Tricks. Wenn z.B. u-Werte von 8188.4, 8189.2 und 8191.9 für ein Dreieck ermittelt werden, kann man sie zu 0.4, 1.2 und 3.9 zurechtstutzen und darüber interpolieren.

[Sonyfreak]

Auch eine Neuinstallation des Spieles hat die Filterung nicht verändert. Also dürfte es nicht am übertragen des Spieles liegen. Falls es ein Problem mit den Texturkoordinaten und fehlender Genauigkeit ist: Warum funktioniert es dann bei Spielen mit der selben Engine ohne Probleme?

mfg.

Sonyfreak

[Neomi]

Falls es ein Problem mit den Texturkoordinaten und fehlender Genauigkeit ist: Warum funktioniert es dann bei Spielen mit der selben Engine ohne Probleme?

Weil das keine Frage der Engine, sondern eine Frage des Contents ist. Andere Engines haben genau das gleiche Problem, wenn sie derart große Texturkoordinaten erlauben.

[Sonyfreak]

@Neomi Vielen Dank für die Erklärung!

Das heißt, dass die Textur deshalb auf der Nvidia Grafikkarte besser aussieht, weil diese die Texturen mit höherer Präzision filtert. Wurde die Präzision bei den neueren ATI Karten erhöht oder kann das auch bei neuen Karten (R300-R420) passieren, dass solche Texturen nicht korrekt aussehen?

mfg.

Sonyfreak

[Neomi]

Das heißt, dass die Textur deshalb auf der Nvidia Grafikkarte besser aussieht, weil diese die Texturen mit höherer Präzision filtert.

Nein, keine höhere Präzision. Texturkoordinaten sind wie Vertexdaten eigentlich immer FP32, auch bei inzwischen richtig alter Hardware. Die Radeon 9000 nutzt FP32 dafür, ebenso wie z.B. auch die Radeon 7500.

Wurde die Präzision bei den neueren ATI Karten erhöht oder kann das auch bei neuen Karten (R300-R420) passieren, dass solche Texturen nicht korrekt aussehen?

Es werden wohl lediglich Tricks verwendet, die eine höhere Präzision für den relevanten Teil erlauben. Es macht z.B. keinen Unterschied, ob man zwischen 8188.0 und 8191.0 interpoliert oder zwischen 0.0 und 3.0, solange man zum Sampling des Texturwertes nur den Nachkommateil benötigt. Bei der zweiten Möglichkeit bleibt allerdings deutlich mehr Präzision übrig für den relevanten Teil. Irgendetwas in der Richtung muß es sein.

[Xmas]

So simpel ist das nicht. Diese fehlende Präzision dank hoher Koordinatenwerte habe ich auf einer Radeon 9000 gesehen, alles ab R300 sah aber soweit in Ordnung aus. Auch ATI verwendet FP32 für Texturkoordinaten, solange sie nicht erst im Pixelshader generiert werden.
Ja, ab R300. Hier geht es um eine Mobility Radeon 9000.

Meine Beispielrechnung mit der Genauigkeit war schon für FP32, um das zu umgehen gibt es andere Tricks. Wenn z.B. u-Werte von 8188.4, 8189.2 und 8191.9 für ein Dreieck ermittelt werden, kann man sie zu 0.4, 1.2 und 3.9 zurechtstutzen und darüber interpolieren.
Die Werte für die Eckpunkte werden ja nicht "ermittelt" (außer beim Clipping), sondern vorgegeben. Und dabei benutzt man keine Werte die höher sind als sie es müssten. MaxTextureRepeat für R2xx ist übrigens 8 IIRC.

[Neomi]

Ja, ab R300. Hier geht es um eine Mobility Radeon 9000.

Was genau meinst du? FP32 gilt jedenfalls nicht erst ab dem R300.

Die Werte für die Eckpunkte werden ja nicht "ermittelt" (außer beim Clipping), sondern vorgegeben. Und dabei benutzt man keine Werte die höher sind als sie es müssten. MaxTextureRepeat für R2xx ist übrigens 8 IIRC.

Hab heute noch nachgeschaut, mein Bürokollege hat vorerst eine Radeon 9000 im Rechner. MaxTextureRepeat ist 2048, glücklicherweise nicht durch die Texturauflösung geteilt (was ja bei NV zumindest bis zur GF 4 Ti noch anders war).

Texturwerte kann man ziemlich gut zur Laufzeit ermitteln. Eine planare Projektionsmatrix pro Texturlayer kann mächtig viel Speicher sparen. Natürlich nur für Landschaften, bei Objekten geht das natürlich nicht. Und auch, wenn diese Werte fest vorgegeben sind, werden sie wohl von einem Editor per Projektion ermittelt worden sein. Eine manuelle Eingabe konkreter Koordinatenwerte dürfte zumindest bei Landschaften doch sehr selten sein.

[Xmas]

Was genau meinst du? FP32 gilt jedenfalls nicht erst ab dem R300.
Soweit mir bekannt ist schon.

Hab heute noch nachgeschaut, mein Bürokollege hat vorerst eine Radeon 9000 im Rechner. MaxTextureRepeat ist 2048, glücklicherweise nicht durch die Texturauflösung geteilt (was ja bei NV zumindest bis zur GF 4 Ti noch anders war).
Ja, da habe ich mich geirrt, MaxTextureRepeat ist 2048, zumindest in der ersten Phase, in der zweiten dann 8 (wegen MaxPixelShaderValue). 2048 deutet aber nicht auf FP32 hin.

Texturwerte kann man ziemlich gut zur Laufzeit ermitteln. Eine planare Projektionsmatrix pro Texturlayer kann mächtig viel Speicher sparen. Natürlich nur für Landschaften, bei Objekten geht das natürlich nicht. Und auch, wenn diese Werte fest vorgegeben sind, werden sie wohl von einem Editor per Projektion ermittelt worden sein. Eine manuelle Eingabe konkreter Koordinatenwerte dürfte zumindest bei Landschaften doch sehr selten sein.
Ich weiß nicht genau was du damit sagen willst. Das ändert aber nichts daran dass die Werte generell nicht größer angegeben werden als nötig.

[Crushinator]

Nein, keine höhere Präzision. Texturkoordinaten sind wie Vertexdaten eigentlich immer FP32, auch bei inzwischen richtig alter Hardware. Die Radeon 9000 nutzt FP32 dafür, ebenso wie z.B. auch die Radeon 7500. (...) Das (http://www.beyond3d.com/forum/viewtopic.php?p=213393&highlight=#213393) ist die Aussage eines ATI-Angestellten, und er bezieht sich auf R3XX Chips, wenn er meint daß nur der Vertexshader durchgehend mit 32 bit FP arbeitet. Daß er selbst nicht von FP24 bei Texturadressierung begeistert ist liest sich zwischen den Zeilen. ;)

[Neomi]

Soweit mir bekannt ist schon.

Ja, da habe ich mich geirrt, MaxTextureRepeat ist 2048, zumindest in der ersten Phase, in der zweiten dann 8 (wegen MaxPixelShaderValue). 2048 deutet aber nicht auf FP32 hin.

Es muß nicht wirklich zwingend FP32 sein, 2048 Wiederholungen von Texturen mit maximal 2048 Texeln in einer Richtung kann man auch mit einem Integer machen. 23 Bit (da Signed) reichen, um einen Texel zu adressieren, also nimmt man 32 Bit als Fixedpoint und hat noch 9 Bit (eher 8, eins sollte als Reserve bleiben um z.B. 2048 auch noch darstellen zu können) übrig für Nachkommastellen. Das könnte hinhauen, allerdings stelle ich mir die perspektivisch korrekte Interpolation ein wenig schwierig vor.

Ein sehr deutlicher Hinweis auf einen Floatwert ist jedenfalls die reduzierte Genauigkeit bei großen Zahlen, bei Fixedpoint-Integern würde das nicht passieren und außerhalb der Grenzen würde es gar nicht mehr hinhauen. Es könnte sicherlich auch FP24 sein. Da die Texturkoordinaten im Vertexbuffer aber eh als FP32 vorliegen (ja, ich weiß, ab DX9 bzw. DX8 speziell bei der XBox kann man sie auch packen) und FP32-Rechenwerke schon lange vor dem R200 in GPUs verbaut wurden (z.B. die fest verdrahtete Worldmatrix und ihre Schwestern), gehe ich einfach mal von FP32 aus.

Trotzdem sind das nur Vermutungen meinerseits. Was spricht denn gegen FP32?

Ich weiß nicht genau was du damit sagen willst. Das ändert aber nichts daran dass die Werte generell nicht größer angegeben werden als nötig.

Natürlich sollten sie nicht größer angegeben werden als nötig, manchmal passiert es aber einfach trotzdem. Das Ergebnis sind dann solche Ungenauigkeiten wie auf dem Bild zu sehen.

[Neomi]

Das (http://www.beyond3d.com/forum/viewtopic.php?p=213393&highlight=#213393) ist die Aussage eines ATI-Angestellten, und er bezieht sich auf R3XX Chips, wenn er meint daß nur der Vertexshader durchgehend mit 32 bit FP arbeitet. Daß er selbst nicht von FP24 bei Texturadressierung begeistert ist liest sich zwischen den Zeilen. ;)

Genau das meinte ich auch, hab's nur nicht so genau formuliert. Dependant Reads und anderweitig im Pixelshader generierte Texturkoordinaten können nicht genauer sein als andere arithmetische Berechnungen im Pixelshader.

Gibt es auch irgendwo eine offizielle Aussage zu der Präzision der Texturkoordinaten bei der R[v]2xx-Familie?

[Crushinator]

(...) Gibt es auch irgendwo eine offizielle Aussage zu der Präzision der Texturkoordinaten bei der R[v]2xx-Familie? Fixed Point 16 bit bei allen Shadern. Einmal (http://www.beyond3d.com/forum/viewtopic.php?p=217419) von von DaveBaumann, und einmal (http://www.beyond3d.com/forum/viewtopic.php?p=96219#96219) von einem weiteren ATi-Angestellten als Bestätigung, daß es auf alle Fälle höher als FX12 sei. Hier (http://www.beyond3d.com/forum/viewtopic.php?p=217504&highlight=#217504) und da (http://www.beyond3d.com/forum/viewtopic.php?p=217547&highlight=#217547) wird er noch deutlicher. ;)

[Neomi]

Fixed Point 16 bit bei allen Shadern. Einmal (http://www.beyond3d.com/forum/viewtopic.php?p=217419) von von DaveBaumann, und einmal (http://www.beyond3d.com/forum/viewtopic.php?p=96219#96219) von einem weiteren ATi-Angestellten als Bestätigung, daß es auf alle Fälle höher als FX12 sei. Hier (http://www.beyond3d.com/forum/viewtopic.php?p=217504&highlight=#217504) und da (http://www.beyond3d.com/forum/viewtopic.php?p=217547&highlight=#217547) wird er noch deutlicher. ;)

All das ist soweit klar, aber ich meinte nicht die im Pixelshader generierten Koordinaten. Daß die nur FX16 sind, bestreite ich nicht. Kleines Beispiel:

ps.1.1

tex t0
mov r0, t0

Mir geht es dabei nicht um die Präzision des Farbwertes, der nach dem Sampling in t0 steht. Mit geht es um die Präzision der Koordinaten, mit denen t0 gesampled wird.

Mit MaxTextureRepeat auf 2048 und MaxTextureWidth sowie MaxTextureHeight auf 2048 müssen 2048*2048 = 2^22 Zeilen und Spalten an Texeln adressiert werden können, was mit FX16 schonmal unmöglich ist. Um dann überhaupt noch bilinear filtern zu können (was noch ein paar zusätzliche Bits erfordert), ist also schon FX32 nötig, FP32 aber einfacher. Die Ungenauigkeit in den Screenshots zum Threadbeginn deutet auf ein Floatformat hin. FP24 ist zu wenig, da die Mantisse alleine schonmal 22 (bzw. 21 dank der impliziten 1) Bit benötigt, um bei Ausnutzung der Werte laut Caps noch einzelne Texel ansteuern zu können, mehr für eine Filterung.

[Xmas]

Trotzdem sind das nur Vermutungen meinerseits. Was spricht denn gegen FP32?
Dass ATI sowieso nur mit 6 Nachkommabits bilinear interpoliert und es auch sonst so mit der Präzision nicht so genau nimmt, ist ja bekannt (http://www.3dcenter.org/artikel/2003/11-21_b.php). Mehr Bits zu berechnen, als letztlich verwendet werden, ist nicht unbedingt sinnvoll.
Auch meinerseits gibt es bezüglich R2xx nur Vermutungen.

Ich habe mit meiner Mobility Radeon 9600 mal das lustige Experiment gewagt, ein Quad mit Texturkoordinaten von (2047.5, -0.5) bis (2048.5, 0.5) zu rendern. Die Textur ist 512x512, das ganze wurde stark vergrößert betrachtet, man sieht die einzelnen Texel. Das Ergebnis befindet sich im Anhang.

Man sieht deutlich dass es ein Float-Format ist, da sich die Präzision beim Überschreiten der 2048er-Grenze halbiert. Über 2048 können lediglich noch vier Stufen zwischen den Texeln ausgemacht werden. Da die Textur 512 Pixel breit ist, bedeutet das konkret: Die nächste, auf 2048 folgende darstellbare Zahl ist 2048 + 1/2048. Das ist allerdings eigenartig, denn IEEE754-FP32 bietet 23 Bit plus implizite 1, womit die nächste darstellbare Zahl 2048 + 1/4096 wäre. Dies ist also entweder ein Format ohne implizite 1 oder nur mit 22 Bit Mantisse. Was den Exponenten angeht, kann man nur raten, denn schon bei relativ kleinem Exponenten geht das Texturieren völlig vor die Hunde, 5 Bit sind da mehr als ausreichend.

[Neomi]

Dass ATI sowieso nur mit 6 Nachkommabits bilinear interpoliert und es auch sonst so mit der Präzision nicht so genau nimmt, ist ja bekannt (http://www.3dcenter.org/artikel/2003/11-21_b.php). Mehr Bits zu berechnen, als letztlich verwendet werden, ist nicht unbedingt sinnvoll.

Och, ein oder zwei Bit genauer darf es doch sein, sollten schon noch zusätzlich berechnet werden, sonst sind nur vier oder fünf Nachkommabits wirklich zu gebrauchen... ;)

Man sieht deutlich dass es ein Float-Format ist, da sich die Präzision beim Überschreiten der 2048er-Grenze halbiert.

Ja, genau wie vermutet. Mit der Ausnahme, daß ich so ein Bild auch erst beim 4096er-Übergang vermutet hätte.

[Xmas]

Ja, genau wie vermutet. Mit der Ausnahme, daß ich so ein Bild auch erst beim 4096er-Übergang vermutet hätte.
Schon beim 1024er-Übergang sieht es ähnlich aus, eben mit doppelt so vielen Stufen. Immerhin ist es da aber noch nicht so verbogen.

NVidia (6600GT) rechnet wie erwartet noch ein Bit genauer, eben mit IEEE754-FP32. Es gibt also jenseits der 2048 noch 8 Zwischenstufen, wenn auch nicht ganz gleichmäßig verteilt.

Frag mich aber bitte nicht wo die Diagonale herkommt, die läuft bei NVidia genau in die andere Richtung (und ist auch weniger verschoben).

[Neomi]

Schon beim 1024er-Übergang sieht es ähnlich aus, eben mit doppelt so vielen Stufen. Immerhin ist es da aber noch nicht so verbogen.

Ja, bei 512 auch, bei 256 ebenso. Ich meinte ja nicht die Streifenbildung allgemein, sondern die nur vier Abstufungen. Eben das fehlende Bit Präzision, das du auch schon angemerkt hast. ;)

Frag mich aber bitte nicht wo die Diagonale herkommt, die läuft bei NVidia genau in die andere Richtung (und ist auch weniger verschoben).

Also zeichnest du den Quad als Quad, nicht als zwei Dreiecke. Gut, dann muß es OpenGL sein, Direct3D kann ja keine Quads (außer der XBox mal wieder). ATI und nVidia zerlegen sich den Quad dann eben unterschiedlich in einzelne Dreiecke. Ich vermute mal, die Verzerrungen liegen an einer grenzwertigen Genauigkeit bei der Interpolation der Texturkoordinaten.

[Xmas]

Also zeichnest du den Quad als Quad, nicht als zwei Dreiecke. Gut, dann muß es OpenGL sein, Direct3D kann ja keine Quads (außer der XBox mal wieder). ATI und nVidia zerlegen sich den Quad dann eben unterschiedlich in einzelne Dreiecke. Ich vermute mal, die Verzerrungen liegen an einer grenzwertigen Genauigkeit bei der Interpolation der Texturkoordinaten.
Ach ja, die alte Baum-Wald-Geschichte... ;)