Archiv verlassen und diese Seite im Standarddesign anzeigen : G70 Transparenz-AA – Alpha-Kanten-Multisampling?
avalanche
2005-06-27, 12:57:20
Da ich bei den vielen G70-Transparenz-AA-Threads nicht mehr blicke, wo was steht, mache ich mal zu meiner eigenen Denkfehlervermeidung einen neuen auf... (tut mir leid, liebe Mods, aber ich wusste keinen anderen Ausweg mehr... ;))
Die ganze Geschichte um den neuen Anti-Aliasing-Modus bzw. der Technik-Artikel von aths haben mich dazu bewegt, den alten Anti-Aliasing-Artikel wieder rauszukramen. Ich muss jetzt sicher gehen, dass ich das alles richtig verstehe.
Was ich Begriffen habe ist, dass beim Multisampling nur die Polygonkanten, bzw. die Pixel die auf denen liegen, geglättet werden. Wo die zu glättenden Pixel sind, wird beim entsprechend an die "Subpixel-Auflösung" angepassten Triangle Setup festgestellt.
Wo ich mir schon nicht mehr so sicher bin: Dort, wo nun geglättet werden soll, wird dann ähnlich verfahren, wie es 3Dfx beim RGSSAA mit Multisamplebuffer vorgemacht hat: Die Subpixel-Bilder werden in die jeweiligen Puffer geschoben und dann vermixt, richtig? *hoff*
So betrachtet ist Multisampling nur ein polygonkantenabhängiges Supersampling, auch richtig?
Wenn ich mir jetzt die Alpha-Kantenglättung angucke, dann funktioniert das doch prinzipiell genauso, nur dass die Kantenglättung jetzt nicht mehr nur auf die Polygonkanten anspringt, sondern auch auf die "Transparenz-Kanten". Das man die "Transparenz-Kanten" (hat mal wer 'n anderen Ausdruck für "Transparenz-Kanten"? Das ist ja eher 'ne Umschreibung für was, wofür ich den korrekten Ausdrück nicht kenne...) nicht im Triangle Setup bestimmen kann, ist mir klar, das wird nV dann irgendwie anders auf die Reihe bekommen haben, aber prinzipiell ist die Transparenz-Kantenglättung doch auch nur ein Multisampling, was eben sowohl auf Polygonkanten als auch auf die "Transparenz-Kanten" anspringt.
Alles richtig verstanden?
Wo ich mir schon nicht mehr so sicher bin: Dort, wo nun geglättet werden soll, wird dann ähnlich verfahren, wie es 3Dfx beim RGSSAA mit Multisamplebuffer vorgemacht hat: Die Subpixel-Bilder werden in die jeweiligen Puffer geschoben und dann vermixt, richtig? *hoff*
Auch wenn es tatsächlich nur ein Puffer ist, man kann es sich als mehrere logische Puffer denken, ja.
So betrachtet ist Multisampling nur ein polygonkantenabhängiges Supersampling, auch richtig?
Jein, normales Supersampling würde ja bedeuten dass die Shaderberechnungen pro Sample ausgeführt werden. Bei Multisampling werden sie pro Dreieck im Pixel einmal ausgeführt.
Bei 4xAA werden mit Supersamplingalso immer 4 Farbwerte berechnet, bei Multisampling im Polygoninneren einer und an den Kanten meistens 2, nur selten 3 oder 4.
Wenn ich mir jetzt die Alpha-Kantenglättung angucke, dann funktioniert das doch prinzipiell genauso, nur dass die Kantenglättung jetzt nicht mehr nur auf die Polygonkanten anspringt, sondern auch auf die "Transparenz-Kanten". Das man die "Transparenz-Kanten" (hat mal wer 'n anderen Ausdruck für "Transparenz-Kanten"? Das ist ja eher 'ne Umschreibung für was, wofür ich den korrekten Ausdrück nicht kenne...) nicht im Triangle Setup bestimmen kann, ist mir klar, das wird nV dann irgendwie anders auf die Reihe bekommen haben, aber prinzipiell ist die Transparenz-Kantenglättung doch auch nur ein Multisampling, was eben sowohl auf Polygonkanten als auch auf die "Transparenz-Kanten" anspringt.
Alles richtig verstanden?
TAA-SS ist reines Supersampling. TAA-MS ist Multisampling, es wird nur ein Farbwert berechnet und für alle bedeckten Samples verwendet. Nur dass die Bedeckung der Samples zusätzlich durch den berechneten Alpha-Wert modifiziert wird.
Exxtreme
2005-06-27, 13:54:08
TAA-SS ist reines Supersampling. TAA-MS ist Multisampling, es wird nur ein Farbwert berechnet und für alle bedeckten Samples verwendet. Nur dass die Bedeckung der Samples zusätzlich durch den berechneten Alpha-Wert modifiziert wird.
Sprich, recht grobe Alphatest-Texturen würden auch nur recht grobe Zwischenstufen ergeben, oder?
avalanche
2005-06-27, 15:18:38
Jein, normales Supersampling würde ja bedeuten dass die Shaderberechnungen pro Sample ausgeführt werden. Bei Multisampling werden sie pro Dreieck im Pixel einmal ausgeführt.
Bei 4xAA werden mit Supersamplingalso immer 4 Farbwerte berechnet, bei Multisampling im Polygoninneren einer und an den Kanten meistens 2, nur selten 3 oder 4.Also: Multisampling entspricht Supersampling (mit Multisamplebuffer), bei dem nur die Subpixel neuberechnet werden, die noch kein "Nachbar-Subpixel" haben, dass weder im selben Pixel noch im selben Dreieck liegt.
TAA-SS ist reines Supersampling. TAA-MS ist Multisampling, es wird nur ein Farbwert berechnet und für alle bedeckten Samples verwendet. Nur dass die Bedeckung der Samples zusätzlich durch den berechneten Alpha-Wert modifiziert wird.Also ist TAA-MS ungefähr das, was ich oben beschrieben hab und TAA-SS berechnet da, wo es soll (Transparenz-Kanten :D), *alle* Subpixel komplett (keine billigen Kopien) und achtet überhaupt nicht auf irgendwelche Polygonkanten. Denke, ich hab's gerafft. Danke.
Demirug
2005-06-27, 15:21:03
Sprich, recht grobe Alphatest-Texturen würden auch nur recht grobe Zwischenstufen ergeben, oder?
Kann man so allgemein nicht sagen. Da spielt dann noch die Genauigkeit des Texturefilters eine Rolle.
Demirug
2005-06-27, 15:25:39
Also: Multisampling entspricht Supersampling (mit Multisamplebuffer), bei dem nur die Subpixel neuberechnet werden, die noch kein "Nachbar-Subpixel" haben, dass weder im selben Pixel noch im selben Dreieck liegt.
Bei Multisample wird pro Pixel nur einmal der Pixelshader durchlaufen und dann aufgrund des Alphawerts eine Maske errechnet welche bestimmt wie viele der Samples nun mit dem berechneten Wert beschrieben werden. Selbst wenn er merken würde das da eine Kante ist führt das nicht zur Neuberechnung.
Also ist TAA-MS ungefähr das, was ich oben beschrieben hab und TAA-SS berechnet da, wo es soll (Transparenz-Kanten :D), *alle* Subpixel komplett (keine billigen Kopien) und achtet überhaupt nicht auf irgendwelche Polygonkanten. Denke, ich hab's gerafft. Danke.
Auch das TAA-SS erkennt die Kanten nicht. Es rechnet einfach stur für alle Pixel eines Dreiecks für jedes Sample einen Farbwert aus wenn der Treiber davon ausgehen muss das es zu Kanten kommen könnte die nicht durch die Geometrie entstehen. Gibt ja noch zwei weitere Fälle ausser dem Alphatest.
avalanche
2005-06-27, 15:48:18
Bei Multisample wird pro Pixel nur einmal der Pixelshader durchlaufen und dann aufgrund des Alphawerts eine Maske errechnet welche bestimmt wie viele der Samples nun mit dem berechneten Wert beschrieben werden. Selbst wenn er merken würde das da eine Kante ist führt das nicht zur Neuberechnung.Es wird also nach der Berechnung des Pixels entschieden, für welche Samples der errechnete Wert übernommen wird, und für welche nicht. Gilt das für die geometriebedingten Kanten auch (deine Ausführung klang danach, als ob es nur um das TAA-MS ginge)? Wie kommen dann die Samples zu einem anderen Wert, für die entschieden wurde, dass sie nicht mit dem Wert beschrieben werden?Auch das TAA-SS erkennt die Kanten nicht. Es rechnet einfach stur für alle Pixel eines Dreiecks für jedes Sample einen Farbwert aus wenn der Treiber davon ausgehen muss das es zu Kanten kommen könnte die nicht durch die Geometrie entstehen. Gibt ja noch zwei weitere Fälle ausser dem Alphatest.Jo, hier gibts dann aber wenigstens für jedes Sample einen Wert.
Funktioniert die ganze Geschichte eigentlich auch mit texkill? Bzw. erkennt das der Treiber, weil mit TSS AA sollte es ja auf jeden Fall gehen.
Demirug
2005-06-27, 15:53:48
Es wird also nach der Berechnung des Pixels entschieden, für welche Samples der errechnete Wert übernommen wird, und für welche nicht. Gilt das für die geometriebedingten Kanten auch (deine Ausführung klang danach, als ob es nur um das TAA-MS ginge)? Wie kommen dann die Samples zu einem anderen Wert, für die entschieden wurde, dass sie nicht mit dem Wert beschrieben werden?
Die anderen Samples kommen dann von dem Objekt das "dahinter" liegt. Da ja nicht nur der Farbwert sondern auch der Z-Wert dieser Samples nicht verändert wird funktioniert das.
Demirug
2005-06-27, 15:54:31
Funktioniert die ganze Geschichte eigentlich auch mit texkill? Bzw. erkennt das der Treiber, weil mit TSS AA sollte es ja auf jeden Fall gehen.
Ja, aber nur TSSAA. Gilt übrigens auch wenn der Pixelshader den Z-Wert verändert.
avalanche
2005-06-27, 16:01:50
Die anderen Samples kommen dann von dem Objekt das "dahinter" liegt. Da ja nicht nur der Farbwert sondern auch der Z-Wert dieser Samples nicht verändert wird funktioniert das.Ach so! Dann werden die entsprechenden Samples während der Berechnung eines anderen Objektes, welches ein Dreieck besitzt, das sich mit einem Dreick des aktuellen Objektes ein Pixel teilt, mit einem Wert beschrieben. Dann versteh ich das. Bei mir im Kopf schwirrten gerade ziemlich viele "wertlose" Samples rum, damit konnt ich so nix anfangen.
Gibt ja noch zwei weitere Fälle ausser dem Alphatest.
und welche wären dies?
Wurde schon gesagt. Texkill und Z-Wert veränderung im Pixelshader.
Neomi
2005-06-27, 23:22:55
und welche wären dies?
Einmal die Kanten der Dreiecke und dann noch partieller ZFail, wie es z.B. bei Überlappung auftritt. Weil das nicht geglättet wurde beim Matrox Parhelia, sah das grob skizziert so aus:
http://img215.echo.cx/img215/2817/dreiecke7rl.gif (http://www.imageshack.us)
Edit: oops, hätte das zitierte Zitat nochmal ungekürzt lesen sollen vorher...
Neomi, es ging um die Fälle in denen beim G70 TAA-SS aktiviert wird.
Neomi
2005-06-27, 23:48:40
Neomi, es ging um die Fälle in denen beim G70 TAA-SS aktiviert wird.
Ja, sorry. Das habe ich dann auch kurz nach dem Posting bemerkt. Wenn man an verschiedenen Stellen quasi gleichzeitig liest, vermischt man schonmal was...
MadManniMan
2005-06-28, 01:28:19
Ah, sehr schön! Ein AA-Wissens Auffrischungs Dings!
Da lang ich doch glatt mal zu...
Aaaalso: ganz unabhängig davon, ob jetzt Multisampling oder TSAA - oder besser gesagt... für beides bitte ne Antwort:
Wann genau in der Pipe merkt der Chip "Holla, da muß ich ja auch nochma Geometrie machen!" - und woran erkennt er dies?
Zudem: kann man sich das beim TAA so vorstellen, daß auch nur die Bereiche von Alpha-gedingsten Texturen mit TSAA behandelt werden, die auch anfällig dafür scheinen?
Wäre ja reichlich dämlich, wenn man - angenommen - 3/4el des Bildes durch eine Masche eines fiktiven Zaunes verdeckt hätte, wobei inner Mitte noch leicht durchsichtige Texel vorhanden sind, die kritischen, kontrastreichen aber erst weit außen und dann aber alle Supersampling abbekämen.
Nebenbei: kann man eigentlich Texelweise zwischen Alphablending und Alphatest beim Content Erstellen differenzieren? Oder kann man vorher nur grob einer Textur diese oder jene Eigenschaft zuweisen.
Ohjee, soviele Fragen um diese Zeit.... MFG
Neomi
2005-06-28, 02:29:42
Wann genau in der Pipe merkt der Chip "Holla, da muß ich ja auch nochma Geometrie machen!" - und woran erkennt er dies?
Die GPU geht nicht nochmal zurück, sondern entscheidet quasi pro Drawcall vorab und abhängig von den Renderstates.
Zudem: kann man sich das beim TAA so vorstellen, daß auch nur die Bereiche von Alpha-gedingsten Texturen mit TSAA behandelt werden, die auch anfällig dafür scheinen?
Wäre ja reichlich dämlich, wenn man - angenommen - 3/4el des Bildes durch eine Masche eines fiktiven Zaunes verdeckt hätte, wobei inner Mitte noch leicht durchsichtige Texel vorhanden sind, die kritischen, kontrastreichen aber erst weit außen und dann aber alle Supersampling abbekämen.
Nö, immer nur ein kompletter Drawcall. Wenn manche Pixel dank Alphatest Supersampling nötig haben, bekommen es alle in diesem Drawcall. Und selbst wenn der Alphatest aktiviert ist, obwohl keine Transparenz in der Textur vorhanden ist, wird eben Rechenzeit verschwendet.
Nebenbei: kann man eigentlich Texelweise zwischen Alphablending und Alphatest beim Content Erstellen differenzieren? Oder kann man vorher nur grob einer Textur diese oder jene Eigenschaft zuweisen.
Auch hier gilt: alles, was mit einem einzigen Drawcall gezeichnet wird, wird auch mit identischen Renderstates gezeichnet. Will man manche Dreiecke auf diese und manche auf jene Art zeichnen, muß man sie mit mehreren Drawcalls zeichnen und dazwischen die Settings passend ändern. Texelweise geht das nicht, gezeichnet werden immer Dreiecke.
MadManniMan
2005-06-28, 02:37:05
Holla, danke Dir! Beantwortet leider alle meine Fragen schon - Ineffizienz ahoi ;(
Vorab dachte ich, daß z.B. das Gras in BF2(kenne es nur von Screenies) nun auch nur dort SS bei TSAA abbekommt, wo es halt ... naja, sinnig wäre. Nu wird aber gleich der ganze Klumpen deartig bearbeitet - gibts da keine alternativen Lösungsansätze? Und ich habs auch noch richtig in Erinnerung, daß Drawcalls massiv CPU kosten?
Neomi
2005-06-28, 02:51:07
Holla, danke Dir! Beantwortet leider alle meine Fragen schon - Ineffizienz ahoi ;(
Immerhin deutlich effizienter als Supersampling für alle Drawcalls, auch wenn kein Alphatest aktiv ist.
Vorab dachte ich, daß z.B. das Gras in BF2(kenne es nur von Screenies) nun auch nur dort SS bei TSAA abbekommt, wo es halt ... naja, sinnig wäre. Nu wird aber gleich der ganze Klumpen deartig bearbeitet - gibts da keine alternativen Lösungsansätze? Und ich habs auch noch richtig in Erinnerung, daß Drawcalls massiv CPU kosten?
Ja, Drawcalls kosten Leistung, deshalb sollte man immer so viel wie möglich (bzw. sinnvoll) in einen Drawcall packen. Wo Supersampling sinnvoll ist, läßt sich nicht schon vorher erahnen, sondern erst hinterher beurteilen. Wenn ein Sampel eines Pixels den Test besteht oder nicht, sagt das eben gar nichts über die anderen Sampels aus.
Ailuros
2005-06-28, 10:50:29
Ich frage mich eigentlich ob Transparenz-AA die Schwelle fuer weiteres adaptives Supersampling in der Zukunft sein koennte. Anyone?
MadManniMan
2005-06-28, 11:04:21
Wenn ein Sampel eines Pixels den Test besteht oder nicht, sagt das eben gar nichts über die anderen Sampels aus.
Das heißt, wenn in einem Drawcall det Renderstat "Alphatest" aktiv ist, wird auch alles supergesampled?
Neomi
2005-06-28, 11:41:29
Das heißt, wenn in einem Drawcall det Renderstat "Alphatest" aktiv ist, wird auch alles supergesampled?
Wie schon geschrieben, entweder oder. Alles oder nichts. Kurz: ja!
Das heißt, wenn in einem Drawcall det Renderstat "Alphatest" aktiv ist, wird auch alles supergesampled?Ja, alles andere würde technisch nicht machbar sein. Du stellst dir das zu einfach vor. So viele Alphatest-Polygone gibt es im Bild normal nicht. Sei doch froh dass nVIDIA nicht mehr alles supersamplen muss.
Die Drawcalls kommen übrigens von der Applikation, nicht vom Treiber. An deren Anzahl ändert sich durch TSSAA rein gar nichts.
MadManniMan
2005-06-28, 12:18:05
Aye, alles klar!
Dazu noch eine (ich weiß, dämliche :D ) Frage: es wäre doch aber machbar, z.B. Pflanzentexturen über mehrere Polys zu verteilen - auf daß das "Innere" des Blattes mit nem anderen Drawcall daherkommt, als daß, was am Rande Alphatest erfahren soll.
Ich weiß, daß das irgendwie blödsinnig ist, aber wie würde da vielleicht das Ergebnis aussehen? Performanceverlust durch Drawcall contra Performancegewinn durch eingespartes Supersampling? Pauschal kann man das schlecht sagen, klar, aber ergäben sich bei diesem Gedankenspiel überhaupt sinnige Szenarien?
MFG, der Manni, der jetz zu Uni muß
Dazu noch eine (ich weiß, dämliche ) Frage: es wäre doch aber machbar, z.B. Pflanzentexturen über mehrere Polys zu verteilen - auf daß das "Innere" des Blattes mit nem anderen Drawcall daherkommt, als daß, was am Rande Alphatest erfahren soll.Ja, das ist möglich. Ist aber für den Artist natürlich aufwändiger und es braucht wieder mehr Drawcalls. Für Karten die kein TSAA haben würde es also in schlechterer Performance enden.
Ich weiß, daß das irgendwie blödsinnig ist, aber wie würde da vielleicht das Ergebnis aussehen? Performanceverlust durch Drawcall contra Performancegewinn durch eingespartes Supersampling? Pauschal kann man das schlecht sagen, klar, aber ergäben sich bei diesem Gedankenspiel überhaupt sinnige Szenarien?Also wenn wirklich bei einer rießigen Fläche nur 5% negative Alphatests dabei sind könnte das durchaus sinnvoll sein.
MadManniMan
2005-06-28, 13:09:53
Ja, das ist möglich. Ist aber für den Artist natürlich aufwändiger und es braucht wieder mehr Drawcalls. Für Karten die kein TSAA haben würde es also in schlechterer Performance enden.
Dann ist das klar...
Also wenn wirklich bei einer rießigen Fläche nur 5% negative Alphatests dabei sind könnte das durchaus sinnvoll sein.
...vielleicht wäre es ja durchaus bei manchen Sachen bei FarCry z.B. sinnvoll - dort die Blätter mit nem zweiten Drawcall mit nem Alphatestrand versehen, Schalter für => G70-Karten einbauen und los gehts ;)
Neomi
2005-06-28, 13:38:57
...vielleicht wäre es ja durchaus bei manchen Sachen bei FarCry z.B. sinnvoll - dort die Blätter mit nem zweiten Drawcall mit nem Alphatestrand versehen, Schalter für => G70-Karten einbauen und los gehts ;)
Das bedeutet dann sehr viel zusätzliche Geometrie und einige zusätzliche Drawcalls, was doch recht sinnlos ist.
Es gibt Dinge, bei denen lohnt sich keine Differenzierung, ob etwas nun sinnvoll ist oder nicht. Vor allem dann, wenn Variante 1 die eigentlich unnötigen Berechnungen schon längst ausgeführt hat, während Variante 2 noch über den Sinn grübelt.
MadManniMan
2005-06-28, 14:07:55
Das bedeutet dann sehr viel zusätzliche Geometrie und einige zusätzliche Drawcalls, was doch recht sinnlos ist.
Es gibt Dinge, bei denen lohnt sich keine Differenzierung, ob etwas nun sinnvoll ist oder nicht. Vor allem dann, wenn Variante 1 die eigentlich unnötigen Berechnungen schon längst ausgeführt hat, während Variante 2 noch über den Sinn grübelt.
:up: Danke, wollte nur nochmal bestätigt wissen, daß diese Idee wirklich scheiße ist - weil ich sonst nicht einsähe, warum sie nicht angewandt würde :D
avalanche
2005-06-28, 14:53:06
Oi, ich brauch wohl mal ein bisschen Begriffserklärung. Nachdem ich desöfteren mit "ich erklär mir die Begriffe selber" nicht unbedingt superweit gekommen bin:
Wie muss ich mir Renderstates vorstellen? Eine Art Flags, die gesetzt werden und von denen abhängig dann bestimmte Aktionen ausgeführt werden? Wodurch werden die gesetzt?
Was ist ein "Drawcall"?
Zu Ersterem: Ich weiß nicht, wie ausführlich da eine Erklärung sein muss. Wahrscheinlich ist das recht offtopic, also, wenn einer 'n Nerv dazu hat, mir das zu erklären, dann wär vielleicht 'ne PM ganz gut.
Demirug
2005-06-28, 15:06:55
Ein Renderstate ist ein Wert im Treiber/GPU der festlegt wie die Daten des nächsten Drawcalls zu rendern sind. Ein solcher Renderstate ist zum Beispiel der Alphatest den man an oder ausschalten kann.
Nachdem man alle States so gesetzt hat wie man sie braucht kommt der Drawcall. Dieser teilt dann dem Treiber/GPU mit wie viele "Primitives" (Punkte, Linien oder Dreiecke) er aus den festgelegten Buffern holen und entsprechend den festgelegten Renderstates rendern soll.
Beim Rendern wiederholt sich daher immer wieder das setzten der Renderstates mit anschliessendem Drawcall.
Neomi
2005-06-28, 15:35:39
Wie muss ich mir Renderstates vorstellen? Eine Art Flags, die gesetzt werden und von denen abhängig dann bestimmte Aktionen ausgeführt werden? Wodurch werden die gesetzt?
Renderstates sind Einstellungen, die der GPU sagen, auf welche Weise sie nachfolgende Zeichenanweisungen auszuführen hat. Mal ein kleines Beispiel...
Angenommen, es existiert eine Variable "IDirect3DDevice9 * pDevice;" (ein Pointer auf ein Device). Das Device wurde initialisiert und steht zur freien Verwendung bereit.
pDevice->SetRenderState (D3DRS_ALPHABLENDENABLE, TRUE);
Dieser Befehl sagt der DirectX-Runtime (die sagt es dem Treiber (der sagt es der GPU)), daß für nachfolgende Zeichenanweisungen doch bitte Alphablending aktiv zu sein hat.
Neben Renderstates gibt es noch Texturen, Shader und noch ein paar andere Dinge, die man setzen kann. Texturen etc. unterscheiden sich von den Renderstates dadurch, daß sie erst von der Applikation als Objekte angelegt werden müssen, während Renderstates vom Device zur Verfügung gestellt werden.
Was ist ein "Drawcall"?
Ein Drawcall ist ein Befehl, der unter Berücksichtigung der vorher eingestellten Dinge dann tatsächlich Geometrie zeichnet.
pDevice->DrawIndexedPrimitive (D3DPT_TRIANGLELIST, 0, 0, 4, 0, 2);
Dieser hier zeichnet zwei Dreiecke, deren Eckpunkte aus dem aktiven Vertexbuffer kommen, aber erstmal durch den aktiven Indexbuffer indiziert werden (damit man Eckpunkte mehrfach verwenden kann). Die Eckpunkte werden vom vorher gesetzten Vertexshader transformiert, vom aktiven Pixelshader werden die interpolierten Ergebnisse des Vertexshaders weiter verarbeitet (z.B. texturiert und beleuchtet), dessen Ergebnis wird an die ROPs weitergereicht. Die ROPs können dann den erhaltenen Wert mit dem alten Wert an der jeweiligen Pixelposition vermischen (Alphablending an) oder den alten Wert einfach überschreiben (Alphablending aus).
Das ganze ist zwar stark vereinfacht dargestellt, aber eine wirklich ausführliche Erklärung wäre wohl zu lang. Die Kurzzusammenfassung...
- Renderstates sagen, wie etwas gezeichnet werden soll.
- Drawcalls zeichnen Geometrie.
Edit: hoppala, deutlich zu langsam.
Dazu noch eine (ich weiß, dämliche :D ) Frage: es wäre doch aber machbar, z.B. Pflanzentexturen über mehrere Polys zu verteilen - auf daß das "Innere" des Blattes mit nem anderen Drawcall daherkommt, als daß, was am Rande Alphatest erfahren soll.
dann könntest du ja gleich die blätter ausmodellieren, wäre wahrscheinlich auch nicht viel mehr aufwand.
Für die Performance würde das aber sehrwohl einen Unterschied machen. :rolleyes:
Nicky
2005-07-13, 17:32:33
Hallo **threadwiederausgrab**
ergibt das http://www.humus.ca/index.php?page=Cool (OGL und DXOverride) den selben Effekt wie TAA?
Es sollte denselben Effekt wie Transparent Multisampling ergeben, ja. Leider funktioniert TMAA beim G70 nicht immer reibungslos.
Nicky
2005-07-13, 17:51:04
Es sollte denselben Effekt wie Transparent Multisampling ergeben, ja. Leider funktioniert TMAA beim G70 nicht immer reibungslos.
will heissen A2C ist problemloser und bringt dasselbe Resultat (evtl eher CPU lastig). Falls Ati kein TAA Equivalent in Hardware im R520 hat, koennten sie sich ergo mit A2C ueber Treiber behelfen um nicht mit heruntergelassenen Hosen dazustehen.(Humus ist eh ein Freund der Familie)
Jain. nVIDIA bietet ja auch TSSAA, das kann auch Humus nicht emulieren.
Nicky
2005-07-13, 18:21:44
Jain. nVIDIA bietet ja auch TSSAA, das kann auch Humus nicht emulieren.
**confused**
T(M)AA glaettet laut Screenshots Alphatestkanten nicht so toll, TSSAA, aber doch. Durch A2C sollten immo die Kanten eines "Alphatestobjektes" imo so gut wie bei TSAA geglaettet werden nicht aber die sich nach der Umwandlung entstehenden "Texturen". Rite?
Nein. Das "Humus-Verfahren" glättet allerhöchstens so gut wie TMSAA.
will heissen A2C ist problemloser und bringt dasselbe Resultat (evtl eher CPU lastig).
Nein, Transparent Multisampling ist A2C. Es funktioniert nur scheinbar noch nicht richtig in allen Spielen und ist mit einer kleinen Modifikation versehen, die mir nicht besonders gefällt.
Falls Ati kein TAA Equivalent in Hardware im R520 hat, koennten sie sich ergo mit A2C ueber Treiber behelfen um nicht mit heruntergelassenen Hosen dazustehen.(Humus ist eh ein Freund der Familie)
Da Humus jetzt bereits ein Override-Tool für D3D bereitgestellt hat und A2C in DirectX gar nicht direkt verfügbar ist, hat man es offensichtlich schon in den Treiber eingebaut. Ich rechne damit, dass Transparent Multisampling bald im ATI-Treiber verfügbar ist. TSAA sollte bei ATI auch möglich sein, beides ab R300. Falls ATI dies tut, wäre es auch denkbar dass NVidia reagiert und TMAA auch für ältere Modelle ermöglicht (TSAA wird schwieriger).
In seine A2C-Demo (http://www.humus.ca/index.php?page=3D&ID=61) hat er übrigens noch einen interessanten Modus eingebaut, der dafür sorgt dass beim Vergrößern die Alpha-Kanten nicht unscharf werden. Dies lässt sich allerdings so kaum durch den Treiber erzwingen.
**confused**
T(M)AA glaettet laut Screenshots Alphatestkanten nicht so toll, TSSAA, aber doch. Durch A2C sollten immo die Kanten eines "Alphatestobjektes" imo so gut wie bei TSAA geglaettet werden nicht aber die sich nach der Umwandlung entstehenden "Texturen". Rite?
Nein, die Kanten werden etwas schlechter geglättet (auch wegen Dithering, siehe Demo), allerdings funktioniert A2C mit kleineren Mipmaps besser. TSAA glättet dazu aber auch Kanten, die durch Texkill und im Shader modifizierte Tiefenwerte entstehen. Das kann TMAA/A2C nicht.
Demirug
2005-07-13, 22:04:06
Da Humus jetzt bereits ein Override-Tool für D3D bereitgestellt hat und A2C in DirectX gar nicht direkt verfügbar ist, hat man es offensichtlich schon in den Treiber eingebaut.
Ja. Es funktioniert wieder über den PointSize RenderState. Die Steuer Codes sind: "A2M0" und "A2M1"
Ja. Es funktioniert wieder über den PointSize RenderState. Die Steuer Codes sind: "A2M0" und "A2M1"Arrrrrrrr. Sorry, das musst ich loswerden :biggrin:
Demirug
2005-07-13, 22:12:43
Arrrrrrrr. Sorry, das musst ich loswerden :biggrin:
Ja, mir geht dieser Missbrauch von Renderstates langsam auch auf den Sack. Aber nVidia macht da ja jetzt auch mit.
Mr. Lolman
2005-07-13, 22:28:11
Was für ein EER haben Alphatest-Texturen eigentlich bei 4x4OGSSAA kombiniert mit 4xTSSAA?
Was für ein EER haben Alphatest-Texturen eigentlich bei 4x4OGSSAA kombiniert mit 4xTSSAA?Das hängt vom 4x-Muster des 4x TAA SS ab.
mapel110
2005-07-14, 02:21:47
Ja, mir geht dieser Missbrauch von Renderstates langsam auch auf den Sack. Aber nVidia macht da ja jetzt auch mit.
Was ist so schlimm daran? (unter Opengl heißen die "graphics states"?!)
Was für ein EER haben Alphatest-Texturen eigentlich bei 4x4OGSSAA kombiniert mit 4xTSSAA?
Bei reinem 4x4 SSAA funktioniert TSAA gar nicht, weil TSAA aktiviertes Multisampling benötigt.
Ja. Es funktioniert wieder über den PointSize RenderState. Die Steuer Codes sind: "A2M0" und "A2M1"
Na da hätten sie sich ja wenigstens an dieselbe Methode wie NVidia halten können... ist A2M1 zum Einschalten und A2M0 zum Abschalten?
Was ist so schlimm daran? (unter Opengl heißen die "graphics states"?!)
In OpenGL macht man eine Extension mit zusätzlichen States, dokumentiert diese und hat so eine eindeutige, einheitliche Methode.
In DirectX muss man States, die eigentlich für etwas ganz anderes stehen, aber in den vorgesehenen Situationen "frei" sind, mißbrauchen, weil man keine neuen hinzufügen kann.
Demirug
2005-07-14, 06:22:34
Na da hätten sie sich ja wenigstens an dieselbe Methode wie NVidia halten können... ist A2M1 zum Einschalten und A2M0 zum Abschalten?
Soweit ich das verstanden haben muss man bei nVidia das ganze nur einmal aufrufen um das Transaprency AA zu aktivieren damit es genauso arbeitet wie die Panel Methode. Könnte mich da aber auch täuschen.
Beim ATI wird damit auf jeden Fall das A2C aktiviert und deaktiviert, Man muss es also immer zusammen mit dem Alphatest setzten bzw Rücksetzten.
zeckensack
2005-07-14, 06:46:47
Ja. Es funktioniert wieder über den PointSize RenderState. Die Steuer Codes sind: "A2M0" und "A2M1"Wie wahrscheinlich ist es, dass Microsoft den WHQL-Test dahingehend erweitertert, dass dazu wieder ein Knopf im Treiber erforderlich wird? :naughty:
X-D
Demirug
2005-07-14, 07:24:15
Wie wahrscheinlich ist es, dass Microsoft den WHQL-Test dahingehend erweitertert, dass dazu wieder ein Knopf im Treiber erforderlich wird? :naughty:
X-D
Unwahrscheinlich. Beim Instancing war es ja nicht die Aktivierung über einen Renderstate sondern die Erkennung über ein FourCC Format welches dann aber nicht unterstützt wurde. Eigentlich hätte ATI nur dafür sorgen müssen das sich eine Texture mit dieses Format korrekt verhält und der Schalter im Treiber wäre nicht notwendig gewesen. Allerdings hätte es ATI auch wesentlich einfacher haben können. Sie hätten lediglich rechtzeitig bescheid sagen müssen das sie auch bei iheren nicht SM3 Lösungen Instancing unterstützen wollen. Hätten sie das getan hätte es ein Caps bit gegeben.
Nicky
2005-07-14, 07:59:49
Da Humus jetzt bereits ein Override-Tool für D3D bereitgestellt hat und A2C in DirectX gar nicht direkt verfügbar ist, hat man es offensichtlich schon in den Treiber eingebaut. Ich rechne damit, dass Transparent Multisampling bald im ATI-Treiber verfügbar ist. TSAA sollte bei ATI auch möglich sein, beides ab R300. Falls ATI dies tut, wäre es auch denkbar dass NVidia reagiert und TMAA auch für ältere Modelle ermöglicht (TSAA wird schwieriger).
.
Nice, wuerde hier (TSAA) auch die 1.024x7684 4xMSAA Beschraenkung fuer R3/4XX gelten?
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.