Archiv verlassen und diese Seite im Standarddesign anzeigen : AF à la Radeon - Textursampling
Xmas machte mich darauf aufmerksam, dass das hier Unsinn ist:
Die Radeon bis Radeon9000 sampelt aber nur in glatten 90°-Winkeln. (Aus der Textur werden nur "gerade Reihen" statt "Schrägen" gelesen.) Dadurch sind die Zugriffe auf den Speicher besonders günstig zu gestalten, was sich in erhöhter Geschwindigkeit äußert. Wäre optimalerweise ein 80°-Winkel nötig, kann durch Oversampling in 90°-Richtung noch eine recht gute Qualität geliefert werden. Schwierig sind 45°. Hier nutzt das Oversampling letztlich gar nichts, da durch die fehlende Winkel-Anpassung überwiegend Texel gelesen würden, die gar nicht mehr im zu renderndem Pixel liegen. Die Hardware muss die AF-Stufe hier automatisch verringern, und bei genau 45° sogar auf 1x zurückschalten, was bei diesen Winkeln sich darin äußert dass gar kein Oversampling mehr vorgenommen wird.
Die Radeon9700 (und ihr kleiner Bruder 9500) beherrschen als zusätzliche Winkelstufe 45°, zeigen in der Mitte zwischen 0 und 45° bzw. 45 und 90° aber auch wieder Schwächen.Er bemerkte, dass die AF-Filterung bei der Radeon von der Lage des Polygons abhängt. Das stimmt offenbar. Kann nicht mal einer (hallo zecki) ein Programm schreiben und den Einfluss der Lage von Polygon sowie Textur-Ausrichtung in Bezug auf AF klären?
zeckensack
2002-09-26, 00:50:28
Ist die Frage die, ob die reine x/y-Position des Dreiecks auf dem Bildschirm (bei gleicher 'Lage') das AF beeinflußt ???
Am besten wäre ein Quadrat mit Textur (inkl. MIP-Mapping), dass man in allen drei Achsen routieren und verschieben, und auf Wunsch die MIP-Level anzeigen kann. Meine konrete Frage ist, ob Xmas' Bemerkung (dass die "Dreh-Lage" des Polygons Einfluss auf die Filterung hat) meine Beschreibung von ATIs AF nun falsifiziert, oder lediglich eine zusätzliche Einschränkung darstellt.
zeckensack
2002-09-26, 00:56:35
Also ja? :D
Ööhm, heute nicht mehr ;)
zeckensack
2002-09-26, 01:56:48
Ach nö. Ich bin jetzt müde und hau mich ins Bett :P
/me wartet gespannt auf zeckis Ergebnisse...
zeckensack
2002-09-26, 15:41:53
/me ist gerade nach Hause gekommen und liest kurz mal die Foren durch, bevor er anfängt
/me guckt nervös auf die Uhr.
zeckensack
2002-09-26, 19:48:33
/me beendet das bugfixing am Glide-Wrapper (beliebige Kombinationen aus Chroma Keying, Blending und Alpha Test sollen endlich funzen) extra um für aths was neues anzufangen :naughty:
/me freut sich wie ein Schneekönig.
zeckensack
2002-09-26, 21:22:12
/me präsentiert
Programm
http://home.t-online.de/~zsack/TexCube.exe
dazu passend das GLUT-Toolkit (http://www.xmission.com/~nate/glut/glut-3.7.6-bin.zip), ohne läuft's nicht. Einfach die DLL ins gleiche Verzeichnis schmeißen (oder gleich in Windows\System)
Ist wieder mal ultraprimitiv. Die linke Maustaste verschiebt, die rechte Maustaste rotiert, beide gleichzeitig gedrückt verhelfen den geneigten Nutzer zu einer Zoomfunktion.
Die wundervolle Optik erklärt sich durch eine Textur mit eingefärbten Mipmap-Levels.
Source:
http://home.t-online.de/~zsack/muh.cpp
edit:
/me bedauert wie üblich die kurze Verzögerung durch T-Online, kann aber nicht's dran ändern :D
edit2:
/me hat gerade nochmal die Maussteuerung etwas entschärft, und bietet das Ergebnis diesmal komplett mit Source und VC6-Projektdatei, und ganz in verträglichen Kleinbuchstaben gehalten hier (http://home.t-online.de/~zsack/texcube.zip) nochmal neu an.
edit3:
/me stellt mit Entzücken fest, daß T-Online jetzt auch endlich so weit ist =)
Exxtreme
2002-09-26, 21:46:32
/me fragt sich was das Proggi eigenlich tut. Man sieht zwar schön die MipMap-Level aber einen Zusammenhang sehe ich irgendwie nicht.
Gruß
Alex
zeckensack
2002-09-26, 21:48:54
Jau, deswegen hat
/me auch gerade nochmal die Texturen etwas sinnvoller gestaltet. Maximaler Kontrast in allen Miplevels.
http://home.t-online.de/~zsack/texcube.zip
Und was mein Programm genau machen soll, das muß mir aths erst noch verraten ;)
zeckensack
2002-09-27, 01:04:44
aths,
Ich bin mir ziemlich sicher, daß das noch nicht alles gewesen sein kann. Im Vergleich zu XMas' Tunneltester sieht man bisher einfach nichts weltbewegend neues.
Jetzt wo die Basis steht, welche Funktionen fehlen?
Originally posted by zeckensack
aths,
Ich bin mir ziemlich sicher, daß das noch nicht alles gewesen sein kann. Im Vergleich zu XMas' Tunneltester sieht man bisher einfach nichts weltbewegend neues.
Jetzt wo die Basis steht, welche Funktionen fehlen? Ich möchte eins zur R200 wissen: Kann sie für AF "schräg" aus der Textur sampeln, oder immer nur komplett in u- oder v-Richtung?
zeckensack
2002-09-27, 01:45:28
Aha :)
Dann sollte ich wohl eine Textur zusammenbasteln, die sowas sichtbar macht. Irgendwelche Vorschläge? :|
Oder vielleicht reicht's auch schon aus, wenn ich die Texturkoordinaten entsprechend rotiere ???
*mal versuchen geht*
zeckensack
2002-09-27, 02:03:23
Erstaunlich :naughty:
Die Miplevel verschieben sich bei gleicher Lage auf dem Bildschirm durch unterschiedliche Texturkoordinaten :|
Zum Verfahren:
Ich habe eben mittels Texturmatrix die Texturkoordinaten rotieren lassen. Dabei verändert sich AFAIK die 'Größe' der Textur (in Texturkoordinateneinheiten gemessen) nicht. Die Rotation erfolgte um die Z-Achse im Texturkoordinatenraum, ohne zusätzliche Skalierung, dh daß IMO das Pixel/Texel-Verhältnis davon nicht betroffen sein darf. Was wiederum hieße, daß sich auch die Miplevel-Auswahl nicht ändern sollte.
Da bin ich aber ehrlich gesagt nicht wirklich sicher.
Sieht so aus (Bilder bei T-Online, kann dauern)
Variante 1
http://home.t-online.de/~zsack/TexCube_16xAF_1.png
Variante 2 (Absolut gleiche Kameraeinstellung, nur die Texturen wurden rotiert)
http://home.t-online.de/~zsack/TexCube_16xAF_2.png
Das dürfte eigentlich meine Theorie stützen, oder?
zeckensack
2002-09-27, 02:26:18
Originally posted by aths
Das dürfte eigentlich meine Theorie stützen, oder? Ich denke schon. :)
Ich will erstmal noch ein paar andere Texturen ausprobieren. Ich habe immer noch Bedenken, daß ich mit dem konstanten Pixel/Texel-Verhältnis falsch liegen könnte.
... gibt es neue Erkenntnisse?
zeckensack
2002-09-27, 18:27:56
Bisher nicht. Ich hab's heute noch nicht angefaßt, und habe jetzt auch nicht mehr viel Zeit dafür (Kohlenstoffeinheiten und sowas).
Ein Kommentar von Filter-Guru XMas zu den bis hierhin aufgestellten Überlegungen wäre schön :wink:
Unregistered
2002-09-30, 10:35:09
LOL verstehe nur BAHNHOF ;D
TheRealTentacle
2002-09-30, 19:21:33
Originally posted by zeckensack
aths,
Ich bin mir ziemlich sicher, daß das noch nicht alles gewesen sein kann. Im Vergleich zu XMas' Tunneltester sieht man bisher einfach nichts weltbewegend neues.
Jetzt wo die Basis steht, welche Funktionen fehlen?
(habe R200)
Vieleicht eine Kugel? In einer holen Kugel kann mann alle möglichen Winkel sehen! + FPS Counter!
Ich habe in einer HL Testmap mal einen solchen X-nas Tunnel nachgebaut, und bin zum schluss kekommen, das das seitliche Straven die Mip-Maps, und deutlich die FPS verändert! Es kann natürlich an der Uralten HL Engine liegend, aber bei einen Virtel Tunnel ist mir aufgefallen, das jemehr ich an dessen Polygone Strave, Die FPS sinken! (4xFSAA, 16xFA, Nah dran: 60 FPS, Ca. 1 Meter entfehrnt: 80 FPS) Aber mit FSAA könnte es die Speicherbandbreite sein, und da der XMAN sagt, das die Speicherzugriffe was damit zutun haben, währe für mich ein als leihe ein logischer zusammenhang erkennbar!
Wenn ihr wollt, gebe ich auch Screens + bsp map, aber wirklich neues gibed es nicht! Ich kann ja mal ne große Kugel mappen (Wenn das mal keine illegalen Surfaces gibt :D)
Mir ist noch etwas aufgefallen! Die grenzen zwischen den AF - Stufen haben bei Supersampling FSAA keine Zwischenstufen (durch Subpixel) ?!? Ich dachte bei SSFSAA werden die Texturen auf der doppelten Auflösung gefiltert, und dass ist eigendlich so! ? Wenn aber die Stufen keine Zwischenschritte aufweist, hat ATI dort auch optimiert?
Wie gesagt, ich bin leie, nicht schlagen, wenn da was falsches steht :D
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.