Archiv verlassen und diese Seite im Standarddesign anzeigen : AA Alpha Textures
marco42
2005-07-20, 21:08:43
hi
was ich mich frage ist, was bei der Geforce 7800 so anders ist. alpha to coverage funktioniert ja schon seit laengerem(Humus beispiel) (http://www.humus.ca/index.php?page=3D&ID=61) . und das multisampling kann man ja auch pro batch enablen/disablen(zumindestens unter OpenGL). ist es vielleicht nur ein treiber feature? wieso wird es eigentlich so selten in spielen benutzt? oder ist das jetzt ein D3D problem?
marco
der größte unterschied ist dass die 7800 auch selektives SSAA auf alpha-texturen beherrscht, was noch mal einen deutlichen qualitätsschub gegenüber alpha-to-coverage bringt.
außerdem muss alpha-to-coverage vom spiel unterstützt werden, während die 7800 im prinzip alle spiele mit TAA verbessern kann.
imo braucht dieses feature in realen anwendungen auch nicht gerade wenig performance (der DXTweaker erzwingt imo alpha-to-coverage, was in szenen mit viel alpha-testing sehr viel leistung kostet)
G70 kann auch pro Batch statt RGMSAA RGSSAA verwendet, das ist eigentlich der primäre Unterschied.
marco42
2005-07-21, 02:07:30
der größte unterschied ist dass die 7800 auch selektives SSAA auf alpha-texturen beherrscht, was noch mal einen deutlichen qualitätsschub gegenüber alpha-to-coverage bringt.
außerdem muss alpha-to-coverage vom spiel unterstützt werden, während die 7800 im prinzip alle spiele mit TAA verbessern kann.
imo braucht dieses feature in realen anwendungen auch nicht gerade wenig performance (der DXTweaker erzwingt imo alpha-to-coverage, was in szenen mit viel alpha-testing sehr viel leistung kostet)
also es sollte eigentlich schneller sein, und es kann sogar besser aussehen. es kommt halt darauf an, wie scharf die kante ist. Bei alpha-to-coverage kann es sogar zu weniger flimmern kommen, da der alpha wert ja ueber die flaeche des pixels ermittelt wird, waehrend du bei supersampling ja samplest. du musst den coverage wert ja erst noch ueber das sampling ermitteln.
Ich weiß ja nicht, aber in der Praxis sieht TSSAA deutlich besser aus als TMSAA.
marco42
2005-07-21, 10:11:54
Ich weiß ja nicht, aber in der Praxis sieht TSSAA deutlich besser aus als TMSAA.
also bei dem demo von humus sieht das bei mir sehr gut aus. ich glaube, die alpha channel vieler texturen sind einfach nicht optimal.
Asmodeus
2005-07-21, 14:13:49
also bei dem demo von humus sieht das bei mir sehr gut aus. ich glaube, die alpha channel vieler texturen sind einfach nicht optimal.
Und genau da liegt meiner Meinung nach der große Vorteil. Ich z.B. habe auf Arbeit auch an die 10.000 Texturen rumliegen, die über einen Alphakanal verfügen. Und für fehlerfreies alpha to coverage müsste da bei vielen Texturen nochmal Hand angelegt werden. Bei TSSAA hingegen brauch ich das Feature nur zuschalten. Wobei ich bei der 7800 momentan sowieso nur auf SSAA setze, da ich die Leistung einfach genial finde. Wenn ich auf einer 6800 Ultra bei SSAA und einer Auflösung von 1024x768 einen Einbruch der Framerate auf 25 Prozent zu verzeichnen hatte, so habe ich jetzt nur einen Frameratenrückgang um knapp 25 Prozent. Und bei alpha to coverage wäre noch zu bemerken, dass bei großflächigen Texturinhalten (eben größer als dünne Gitterzaunstrukturen) leicht dieser "Dithereffekt" auftreten kann, was auf jeden Fall immer schlechter als SSAA oder TSSAA aussieht.
Gruss, Carsten.
DaBrain
2005-07-21, 14:26:58
Bitte korrigiert mich wenn ich falsch liege, aber etwas ältere Karten unterstützen doch gar kein alpha to coverage, oder?
Wenn das so ist wäre das ein guter Grund es nicht zu verwenden, weil das Content dann gleich zweimal vor liege müsste.
Einmal für Karten, die alpha to coverage unterstützen, und einmal für Karten, die dies nicht tun.
So aufwändig ist es aber auch nicht einen Alpha Kanal für alpha to coverage bearbeiten.
Lässt sich sogar mit einem Batch lösen. (Wobei man wenigstens zwischen Zäunen und anderen Alpha Texturen unterscheiden sollte.)
Asmodeus
2005-07-21, 14:32:05
Bitte korrigiert mich wenn ich falsch liege, aber etwas ältere Karten unterstützen doch gar kein alpha to coverage, oder?
Wenn das so ist wäre das ein guter Grund es nicht zu verwenden, weil das Content dann gleich zweimal vor liege müsste.
Einmal für Karten, die alpha to coverage unterstützen, und einmal für Karten, die dies nicht tun.
So aufwändig ist es aber auch nicht einen Alpha Kanal für alpha to coverage bearbeiten.
Lässt sich sogar mit einem Batch lösen. (Wobei man wenigstens zwischen Zäunen und anderen Alpha Texturen unterscheiden sollte.)
Gut, die Frage ist, was du jetzt unter einer älteren Karte verstehst. Alpha to coverage gibt es schon seit OpenGL 1.3, über glSampleCoverage(), später kam dann noch glSampleCoverageARB() hinzu. Wo jetzt dort genau die Unterschiede liegen, zwischen der 1.3 Implementierung und der ARB Implementierung kann ich allerdings nicht sagen.
Gruss, Carsten.
Bitte korrigiert mich wenn ich falsch liege, aber etwas ältere Karten unterstützen doch gar kein alpha to coverage, oder?
Alles ab NV20 und R300 unterstützt Alpha to Coverage.
Gut, die Frage ist, was du jetzt unter einer älteren Karte verstehst. Alpha to coverage gibt es schon seit OpenGL 1.3, über glSampleCoverage(), später kam dann noch glSampleCoverageARB() hinzu. Wo jetzt dort genau die Unterschiede liegen, zwischen der 1.3 Implementierung und der ARB Implementierung kann ich allerdings nicht sagen.
Gruss, Carsten.
Andersrum, glSampleCoverageARB() war zuerst da, mit OpenGL 1.3 wurde die Multisample-Extension zum Core-Feature erhoben. Die Funktionalität ist exakt dieselbe.
Asmodeus
2005-07-21, 14:54:40
Andersrum, glSampleCoverageARB() war zuerst da, mit OpenGL 1.3 wurde die Multisample-Extension zum Core-Feature erhoben. Die Funktionalität ist exakt dieselbe.
Ok, das klingt irgendwie auch logischer :rolleyes:
Was mich noch interessieren würde, ist schon bekannt, wie man die neuen TxxAA Modi unter OpenGL, also von der Programmierseite her ansprechen kann?
Gruss, Carsten.
DaBrain
2005-07-21, 15:39:59
Gut, die Frage ist, was du jetzt unter einer älteren Karte verstehst.
Bewußt schwamming formuliert um Unwissen mit Ungenauigkeit zu überdecken. :biggrin: :rolleyes:
also bei dem demo von humus sieht das bei mir sehr gut aus. ich glaube, die alpha channel vieler texturen sind einfach nicht optimal.Alpha Channel? Es geht um Alpha Testing und da gibt's nur transparent oder nicht.
Was soll da nicht optimal sein?
Die Mipmaps beispielsweise. Oder man verlässt sich auf einen Alpha-Vergleich == 1.0, und bekommt dann mit A2C plötzlich einen schwarzen Rand, weil die Texel mit Alpha gleich 0 auch alle schwarz sind...
Die Mipmaps beispielsweise. Oder man verlässt sich auf einen Alpha-Vergleich == 1.0, und bekommt dann mit A2C plötzlich einen schwarzen Rand, weil die Texel mit Alpha gleich 0 auch alle schwarz sind...Das ist auch das Problem mit Alphatesting, wenn ich das richtig sehe. Jedenfalls erinnere ich mich an ältere Benchmarks, deren Alpha-Texturen am Alpha-Rand immer ins schwarze liefen.
Demirug
2005-07-21, 19:42:44
Das ist auch das Problem mit Alphatesting, wenn ich das richtig sehe. Jedenfalls erinnere ich mich an ältere Benchmarks, deren Alpha-Texturen am Alpha-Rand immer ins schwarze liefen.
Ja das ist immer ein Problem. Für Alphatesting Texturen braucht man ein anderes Verfahren für die Mipmap erzeugung anstelle des üblichen Boxfilters.
marco42
2005-07-22, 19:33:49
Alpha Channel? Es geht um Alpha Testing und da gibt's nur transparent oder nicht.
Was soll da nicht optimal sein?
es ging um die texturen. wenn der alpha wert die abdeckung bestimmt, dann sollte der an den kanten schoen interpoliert sein. wenn da nur eine harte kante ist bringt es gar nichts. da ich da selbst noch nichts mit gemacht habe, will ich mich da aber lieber nicht zu weit aus dem fenster lehnen.
hab ich etwas falsch verstanden, wozu braucht man hier noch alpha testing?
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.