Archiv verlassen und diese Seite im Standarddesign anzeigen : NV40 mit 3DFX Algorithmus für AA
Godmode
2004-03-09, 17:39:50
Wenn man der neuen Inq meldung glauben schenken kann, wird in den NV40 3DFX AA Know-How einfließen.:naughty:
Von was könnte man da jetz augehen? 3DFX verwendete doch SSAA, oder? Wäre es möglich einen SSAA-Algorithmus zu implementieren der nicht soviel Performance verpulvert? oder müssen wir hier überhaupt von SSAA absehen?
Also diskutiert mal fleißig mit!!
http://www.theinquirer.net/?article=14600
nagus
2004-03-09, 18:01:57
Original geschrieben von bans3i
Wenn man der neuen Inq meldung glauben schenken kann, wird in den NV40 3DFX AA Know-How einfließen.:naughty:
Von was könnte man da jetz augehen? 3DFX verwendete doch SSAA, oder? Wäre es möglich einen SSAA-Algorithmus zu implementieren der nicht soviel Performance verpulvert? oder müssen wir hier überhaupt von SSAA absehen?
Also diskutiert mal fleißig mit!!
http://www.theinquirer.net/?article=14600
*ROFLLOL*
soweit ich mich erinnern kann - nicht erinnern, ich weiss es ganz genau - wurde selbiges dem NV30 nachgeagt... und was is es dann schlussendlich geworden? wir wissen es alle.
reunion
2004-03-09, 18:05:32
Original geschrieben von bans3i
Wenn man der neuen Inq meldung glauben schenken kann, wird in den NV40 3DFX AA Know-How einfließen.:naughty:
Von was könnte man da jetz augehen? 3DFX verwendete doch SSAA, oder? Wäre es möglich einen SSAA-Algorithmus zu implementieren der nicht soviel Performance verpulvert? oder müssen wir hier überhaupt von SSAA absehen?
Also diskutiert mal fleißig mit!!
http://www.theinquirer.net/?article=14600
Vielleicht so eine art M-Buffer wie er beim Rampage geplant war?
Zumindest kann man wohl mit sparsed AA rechnen...
ShadowXX
2004-03-09, 18:08:35
Original geschrieben von nagus
*ROFLLOL*
soweit ich mich erinnern kann - nicht erinnern, ich weiss es ganz genau - wurde selbiges dem NV30 nachgeagt... und was is es dann schlussendlich geworden? wir wissen es alle.
Das istja auch ein echte :cop: FUAD :cop: Meldung...
Also mit extremer vorsicht zu geniessen...
Zum Topic: ich glaube nicht, das nV das SSAA der 3dfxe implementiert...zu langsam...
J.S.Shadow
reunion
2004-03-09, 18:12:26
Original geschrieben von ShadowXX
Zum Topic: ich glaube nicht, das nV das SSAA der 3dfxe implementiert...zu langsam...
J.S.Shadow
Nur weil man 3dfx Technik verwendet heißt dass ja noch lange nicht dass man SSAA benützt...
ShadowXX
2004-03-09, 18:15:09
Original geschrieben von reunion
Nur weil man 3dfx Technik verwendet heißt dass ja noch lange nicht dass man SSAA integriert...
Klar...aber so was besonderes ist eine Sparsed Sample Maske auch nicht mehr.....
Es wuerde mich allerdings freuen, wenn sie die AA Designer von 3dfx wieder aus Ihrem Keller rausgelassen haben und diese sich jetzt um das SSMSAA des nv40 kuemmern...
J.S.Shadow
Ach... Wenn sie die 3Dfx Technik mit MSAA benützen, dann haben sie genau das ATi AA minus gamma correction
Toll.
Quasar
2004-03-09, 18:36:58
Original geschrieben von ShadowXX
Zum Topic: ich glaube nicht, das nV das SSAA der 3dfxe implementiert...zu langsam...
Ich hoffe sehr stark, daß sie es doch tun - als Option!
Stellt euch mal vor, wie geil ältere Games in hoher Auflösung mit 4xRGSS aussehen. Die Rohpower sollte dann mit ~4GPix/s auch locker ausreichen.
Ailuros
2004-03-09, 18:50:22
Kein Kommentar zum ueblichen Inq-Quatsch.
Wenn es aber wirklich so waere, waere es fast ideal. Spectre hatte nicht nur ausschliesslich M-buffer Unterstuetzung (for the record).
Ailuros
2004-03-09, 18:51:30
Original geschrieben von Quasar
Ich hoffe sehr stark, daß sie es doch tun - als Option!
Stellt euch mal vor, wie geil ältere Games in hoher Auflösung mit 4xRGSS aussehen. Die Rohpower sollte dann mit ~4GPix/s auch locker ausreichen.
Maximal 500MTexels/sec trilinear. :D
reunion
2004-03-09, 18:58:56
Original geschrieben von Ailuros
Spectre hatte nicht nur ausschliesslich M-buffer Unterstuetzung (for the record).
Was denn sonst noch??
ShadowXX
2004-03-09, 19:09:56
Original geschrieben von Quasar
Ich hoffe sehr stark, daß sie es doch tun - als Option!
Stellt euch mal vor, wie geil ältere Games in hoher Auflösung mit 4xRGSS aussehen. Die Rohpower sollte dann mit ~4GPix/s auch locker ausreichen.
Als Option waere es sicher ein seeeehr nettes Schmankerl fuer aeltere Games...da gebe ich dir recht...
J.S.Shadow
Quasar
2004-03-09, 19:23:02
Original geschrieben von Ailuros
Maximal 500MTexels/sec trilinear. :D
Hm, ja, schaun wir mal, wieviel von den 8 Pipes (oder 16, wenn man Jen-Hsung's crack-pfeifchen mitrechnet ;) ) dann am Ende auch color-writes zustande bringen und wieviele TMUs dann insgesamt verbaut respektive gleichzeitig nutzbar sein werden.
Selbst wenn es bei 8 echten Pipes mit jeweils 2 TMUs und 400MHz (ausmultipliziert in etwa das unterste Ende meiner Erwartungen - von mir aus können's auch 4x2 bei 800MHz sein ;) ) bliebe, wären wir am Ende noch bei 800MTex trilinear mit 4xRGSSA. X-D
Ich versuch jetzt mal zwischen den Zeilen zu lesen: Welchen Grund könnte Nvidia denn haben, Meldungen in Umlauf zu bringen sie würden 3dfx Knowhow beim Nv40 zum Einsatz bringen?
Ich behaupte (ohne irgendeinen Beweis dafür zu haben):
UM DIE NV40 KARTEN ALS VOODOO 6 VERMARKTEN ZU KÖNNEN!!
haifisch1896
2004-03-09, 22:02:42
Finde, das ist Quatsch.
Würde nv den Namen GeforceFx durch Voodoo6 ersetzen, hieße es nach aussen hin wie: GeforceFX ist Müll, nv ist Müll, es lebe 3DFX.
Außerdem ist Geforce ein geläufiger Markenname für gute Produkte, welcher durch keinen Namen der Welt zu ersetzen ist. Schließlich gibt es in der PC-Welt nicht nur Freaks wie uns, sondern auch DAU´s und Normaluser. Und die meisten davon werden mit dem Namen Voodoo nichts anfangen können. wobei MediaMarkt und Co. eben diese User doch immer mit Geforce konfrontieren.
Ailuros
2004-03-09, 22:09:09
Original geschrieben von Quasar
Hm, ja, schaun wir mal, wieviel von den 8 Pipes (oder 16, wenn man Jen-Hsung's crack-pfeifchen mitrechnet ;) ) dann am Ende auch color-writes zustande bringen und wieviele TMUs dann insgesamt verbaut respektive gleichzeitig nutzbar sein werden.
Selbst wenn es bei 8 echten Pipes mit jeweils 2 TMUs und 400MHz (ausmultipliziert in etwa das unterste Ende meiner Erwartungen - von mir aus können's auch 4x2 bei 800MHz sein ;) ) bliebe, wären wir am Ende noch bei 800MTex trilinear mit 4xRGSSA. X-D
Was genau hab ich bei Deiner Rechnung jetzt verpasst?
Wieso trilinear 800MTexels/s, unter der Annahme dass 2xbi= trilinear fuer die TMUs?
Ailuros
2004-03-09, 22:09:48
Original geschrieben von reunion
Was denn sonst noch??
T- und M-buffer.
Quasar
2004-03-09, 22:25:00
Original geschrieben von Ailuros
Was genau hab ich bei Deiner Rechnung jetzt verpasst?
Wieso trilinear 800MTexels/s, unter der Annahme dass 2xbi= trilinear fuer die TMUs?
Acht echte Pipes, die Z-, Stencil- und sogar Color-Writes durchführen können mit jeweils zwei bilinearen TMUs.
Macht bei einem Minimum von 400MHz nach Adam Riese:
3200 GPix/s
6400 GTex/s (bi)
3200 GTex/s (tri)
Mit 4xRGSS (ergo Füllrate durch 4) komme ich dann auf 800.
betasilie
2004-03-09, 22:37:48
Original geschrieben von Quasar
Ich hoffe sehr stark, daß sie es doch tun - als Option!
Stellt euch mal vor, wie geil ältere Games in hoher Auflösung mit 4xRGSS aussehen. Die Rohpower sollte dann mit ~4GPix/s auch locker ausreichen.
Ack! SS ist zwar nicht wirklich notwendig, aber wenn man bei älteren Games mit Alphatexturen sowas hätte, wäre das toll. *böse richtung ati guck*
Kauf dir nen Mac dann hast du SS :D
betasilie
2004-03-09, 22:48:22
Original geschrieben von Gast
Kauf dir nen Mac dann hast du SS :D
Kaar, der R3xx kann SS, aber der Algo soll nicht gerade das gelbe vom Ei sein. Deshalb machen sie es wahrscheinlich auch nicht frei für Windows. ;)
LOCHFRASS
2004-03-09, 22:50:05
Wer SSAA will, soll sich doch ne Volari kaufen X-D
In einem anderen Thread meint jemand das ATI SSAA beim Mac nur deshalb in den Treiber eingebaut hat weil MSAA nicht so funzte wie es sollte *shrug*
Ailuros
2004-03-09, 23:03:45
Original geschrieben von Quasar
Acht echte Pipes, die Z-, Stencil- und sogar Color-Writes durchführen können mit jeweils zwei bilinearen TMUs.
Macht bei einem Minimum von 400MHz nach Adam Riese:
3200 GPix/s
6400 GTex/s (bi)
3200 GTex/s (tri)
Mit 4xRGSS (ergo Füllrate durch 4) komme ich dann auf 800.
Arggghhh ja (ich wundere mich gerade was zum Henker ich da ausgerechnet habe....).
Ailuros
2004-03-09, 23:04:07
Original geschrieben von LOCHFRASS
Wer SSAA will, soll sich doch ne Volari kaufen X-D
*faints*
robbitop
2004-03-10, 10:52:55
einen Multisampling Buffer hatte schon die Geforce3.
Interessant wäre eine FB Compression für SSAA, sie wäre wohl viel komplexer umzusetzen, würde aber ähnliche Bandbreitenersparnis wie die heutige FBCompression bringen, nur gegen die Füllratenverschwendung kann ein IMR nicht viel tun.
Ich denke nicht, dass SSAA in nächster Zeit wieder zum Einsatz kommt, es gilt schliesslich als langsam und veraltet. Ohne MSAA wäre 4xAA flüssig zZ gar nicht realisierbar.
Zumal ein tiefer Eingriff ins Trisetup nötig ist, um die Samplemasken gegen Sparse auszutauschen. Ich hoffe, man realisiert wenigstens 4xSparsed oder erweitert den 4xS Modus auf 2xRGMS und 2xRGSS was theoretisch ohne große Eingriffe machbar wäre. Dann hätte man die BQ von 8xS zu den Kosten von 4xS.
Ich persönlich mag die Hybriden sehr gern, da sie nicht allzusehr von der Leistung kosten wie reines SS.
(Habe mal wieder Mafia 1280x1024 8xAF und 4xS probiert...einfach der Wahnsinn wie scharf und geglättet alles im vergleich zu 2xRG bei den selben Settings ist, aber es läuft nur gerade eben flüssig)
bei ATi gibts derzeit nur OGSSAA, weil man beim Rasterizer abspecken musste.
Quasar
2004-03-10, 11:09:53
Original geschrieben von robbitop
Interessant wäre eine FB Compression für SSAA, sie wäre wohl viel komplexer umzusetzen, würde aber ähnliche Bandbreitenersparnis wie die heutige FBCompression bringen, nur gegen die Füllratenverschwendung kann ein IMR nicht viel tun.
Meinst du wirklich Framebuffer-Compression oder Color-Compression?
Exxtreme
2004-03-10, 11:17:02
Original geschrieben von robbitop
Interessant wäre eine FB Compression für SSAA, sie wäre wohl viel komplexer umzusetzen, würde aber ähnliche Bandbreitenersparnis wie die heutige FBCompression bringen, nur gegen die Füllratenverschwendung kann ein IMR nicht viel tun.
Man kann tatsächlich eine Framebufferkompression einbauen, die auch bei SSAA wirken würde. Der Vorteil wäre, daß eine derartige Technik auch wirken würde wenn kein AA eingeschaltet ist. Die heutige Color Compression funktioniert nur mit aktivierten AA. Mit SSAA funktioniert CC nicht da jedes AA-Sample anders ist. Man könnte sogar beide Techniken kombinieren wenn man nur MSAA nutzt.
Gegen den Füllratenverlust wirkt nur Füllrate erhöhen.
Original geschrieben von Exxtreme
Man kann tatsächlich eine Framebufferkompression einbauen, die auch bei SSAA wirken würde.
Erzähl mal. Oder hast du dazu einen Link?
gehst du von einer Art "Codelength Encoding" pro Quad aus, also 1x32bit + 3x8bit als Differenzwerte (oder 1x24bit + 3x12bit oder...) wenn sowas wirklich funktioniert, oder ist es noch komplizierter?
Exxtreme
2004-03-10, 11:49:26
Original geschrieben von Gast
Erzähl mal. Oder hast du dazu einen Link?
gehst du von einer Art "Codelength Encoding" pro Quad aus, also 1x32bit + 3x8bit als Differenzwerte (oder 1x24bit + 3x12bit oder...) wenn sowas wirklich funktioniert, oder ist es noch komplizierter?
Es gibt genug verlustlose Kompressionsalgorhythmen, die man in Hardware gießen könnte.
Es werden schon oft bekannte Verfahren direkt per Hardware ausgeführt. S3TC z.B. ist ein AFAIK Blockkomprimierer.
Ich weiss zwar, wie viele Kompressionsalgorhythmen prinzipiell funktionieren, im Detail kenne ich mich leider nicht wirklich aus. Von daher kann ich deine Frage bezüglich "Codelength Encoding" nicht wirklich beantworten. :(
robbitop
2004-03-10, 11:56:36
hm ich kann mir vorstellen dass eine echte Colorcompression zwar etwas bringt, aber mit MSAA ist diese natürlich extrem wirksam. Denn an NICHT-Polygonkanten (also das meiste vom Bild) haben alle Subpixel die gleiche Farbe, somit wird die BAndbreite doch gut entlastet
Exxtreme
2004-03-10, 12:02:26
Original geschrieben von robbitop
hm ich kann mir vorstellen dass eine echte Colorcompression zwar etwas bringt, aber mit MSAA ist diese natürlich extrem wirksam. Denn an NICHT-Polygonkanten (also das meiste vom Bild) haben alle Subpixel die gleiche Farbe, somit wird die BAndbreite doch gut entlastet
CC bringt ohne MSAA wirklich nichts da man hier davon ausgehen muss, daß jedes AA-Sample anders ist. Und in dem Fall ist das so weil AA-Sample = Pixel.
Original geschrieben von bans3i
Wenn man der neuen Inq meldung glauben schenken kann, wird in den NV40 3DFX AA Know-How einfließen.:naughty: Diese Meldung, so weit kann ich mich wohl aus dem Fenster lehnen, ist eine Interpretation von TI.
Original geschrieben von Exxtreme
CC bringt ohne MSAA wirklich nichts Das hängt vom Algorithmus ab. Z-Compression z. B. bringt ja auch was, ohne dass MSAA zugeschaltet ist. Eine hochwertiger Color-Compression *könnte* auch ohne MSAA (und ohne SSAA) was bringen.
Original geschrieben von nagus
*ROFLLOL*
soweit ich mich erinnern kann - nicht erinnern, ich weiss es ganz genau - wurde selbiges dem NV30 nachgeagt... und was is es dann schlussendlich geworden? wir wissen es alle. Das heißt, dass Nvidia niemals das Antialiasing verbessern wird??
Original geschrieben von Coda
Ach... Wenn sie die 3Dfx Technik mit MSAA benützen, dann haben sie genau das ATi AA minus gamma correction
Toll. Genau, toll. Das gammacorrected downfiltering ist ja mathematisch gesehen nicht unbedingt richtig :)
Exxtreme
2004-03-10, 12:22:30
Original geschrieben von bans3i
Wenn man der neuen Inq meldung glauben schenken kann, wird in den NV40 3DFX AA Know-How einfließen.:naughty:
Das einzige 3dfx-KnowHow, welches ich jetzt bei Nvidia gesehen habe, ist der Molex-Stromanschluß. Und AFAIK hätte Rampage bereits MSAA können sollen. Daß hochwertige SSAA-Implementierungen kurz- oder mittelfristig Einzug finden werden, bezweifle ich.
Exxtreme
2004-03-10, 12:23:21
Original geschrieben von aths
Das hängt vom Algorithmus ab. Z-Compression z. B. bringt ja auch was, ohne dass MSAA zugeschaltet ist. Eine hochwertiger Color-Compression *könnte* auch ohne MSAA (und ohne SSAA) was bringen.
Ich gehe von jetzigen Implementierungen aus. Daß es in Zukunft bessere geben wird, schliesse ich nicht aus.
Original geschrieben von Exxtreme
Das einzige 3dfx-KnowHow, welches ich jetzt bei Nvidia gesehen habe, ist der Molex-Stromanschluß. Und AFAIK hätte Rampage bereits MSAA können sollen.Richtig. Beim Rampage hättest du 4x sparsed Multisampling gehabt.
marco42
2004-03-10, 12:28:06
Original geschrieben von Exxtreme
CC bringt ohne MSAA wirklich nichts da man hier davon ausgehen muss, daß jedes AA-Sample anders ist. Und in dem Fall ist das so weil AA-Sample = Pixel.
AA-Sample == Fragment? Vielleicht sollte man diese Terminologie auch mal in DirectX einfuehren.
Exxtreme
2004-03-10, 12:31:49
Original geschrieben von marco42
AA-Sample == Fragment? Vielleicht sollte man diese Terminologie auch mal in DirectX einfuehren.
Fragment?
Naja, wenn man AA deaktiviert, hat man pro Pixel ein (AA-)Sample.
Original geschrieben von marco42
AA-Sample == Fragment? Vielleicht sollte man diese Terminologie auch mal in DirectX einfuehren. Afaik heißt es in DirectX "Subpixel".
marco42
2004-03-10, 12:43:47
Original geschrieben von aths
Afaik heißt es in DirectX "Subpixel".
Pixel bedeutet eigentlich Picture(Pix) Element. Und dass es ist es erst im Frame Buffer. Eigentlich waere Fragment also besser.
marco42
2004-03-10, 12:50:50
Original geschrieben von Exxtreme
Fragment?
Naja, wenn man AA deaktiviert, hat man pro Pixel ein (AA-)Sample.
Und genau das ist ein Fragment. Ich dachte du haettest schon mal etwas mit OpenGL gemacht? Klang fuer mich so.
Original geschrieben von aths
Richtig. Beim Rampage hättest du 4x sparsed Multisampling gehabt.
Bist du dir da ganz sicher?
Schließlich sank die Füllrate bei 4xAA auf ein Viertel ab.
Ailuros
2004-03-10, 13:02:46
Original geschrieben von Gast
Bist du dir da ganz sicher?
Schließlich sank die Füllrate bei 4xAA auf ein Viertel ab.
hehehe mit wie vielen Texturen pro pass? :D
***edit:
Der Genauigkeit zuliebe Sparsely sampled Multisampling auf Rampage war unter den folgenden Situationen (in relativem Sinn) "Fuellraten-frei":
quad texturing= 4xRGMS/noAF
dual texturing= 2xRGMS/4xAF
Ailuros
2004-03-10, 13:23:33
Zum Thema:
NVIDIA hat schon seit NV25 Ideen aus dem 3dfx Portofolio gezogen und diese implementiert (Beispiele: "filter on scanout", ROP "trick" usw.)
2x sparse MSAA gab es schon (wie bekannt) auf dem NV20 biz zur heutigen NV3x Produkt-Linie.
Spectre haette tatsaechlich 2x und 4x sparse MSAA gehabt, aber auch 2x/4x Supersampling support. Der T-buffer originierte eigentlich vom M-buffer von Spectre, wo Gary Taroli (daher auch das "T") sparse sampled SSAA in den VSA-100 brachte; ergo waren die beiden "quasi-A-buffer" sehr nahe, nur eben der M-buffer komplizierter in HW.
Ich bezweifle genauso dass NV sparsed MSAA und SSAA im NV40 unterstuetzen wird; sparse MSAA schon. Wuerde man dem Inq Quatsch glauben schenken und es auch wortwoertlich nehmen, waere dann wohl eine eher komplizierte Weiterentwicklung des M-buffers in NV40 notwendig gewesen. Ich bezweifle aber dass man durch soviel Aufwand ging...
Ich hoffe, man realisiert wenigstens 4xSparsed oder erweitert den 4xS Modus auf 2xRGMS und 2xRGSS was theoretisch ohne große Eingriffe machbar wäre. Dann hätte man die BQ von 8xS zu den Kosten von 4xS.
Ich lass es mal so stehen. Ich bin mir sicher dass aths diesen Paragraph uebersehen hat ;)
robbitop
2004-03-10, 14:12:11
@Exxtreme
AFAIR hatte Demirug mal was über die Machbarkeit einer Colorcompression für SS gesagt.
Von mir aus glaube ich ebenfalls dass CC nur bei MS sinn macht.
@AiL
na dann schaun wir doch mal was passiert :D
Ailuros
2004-03-10, 14:41:24
@AiL
na dann schaun wir doch mal was passiert
Es geht hier nicht darum was passiert, sondern:
a) Ob der Aufwand im Vergleich zum Resultat der Rede Wert ist.
b) Ob die Qualitaet bei 2x RGMS + 2x RGSS = 8xS sein kann.
Definitiv nein fuer (b). Nur einfach weil der 4xOGSS Anteil von 8xS, horizontal und vertikal Texturen filtert (2 by 2).
Wenn Dir jetzt aber der Textur-filterungs Teil von SSAA egal ist, dann sehe ich auch wieder keinen Grund warum man nicht gleich 4x sparse MSAA + AF benutzen sollte.
Original geschrieben von Gast
Bist du dir da ganz sicher?
Schließlich sank die Füllrate bei 4xAA auf ein Viertel ab. Nur bei bilinearem Singletexturing. Bei trilinearem 2x-Texturing wäre die Füllrate ggü. 1x AA kaum noch gesunken.
Original geschrieben von Ailuros
Zum Thema:
NVIDIA hat schon seit NV25 Ideen aus dem 3dfx Portofolio gezogen und diese implementiert (Beispiele: "filter on scanout", ROP "trick" usw.)Welcher ROP-Trick?
Original geschrieben von Ailuros
Ich lass es mal so stehen. Ich bin mir sicher dass aths diesen Paragraph uebersehen hat ;) 2x RGMS und 2x RGSS, diese Maske würde ich gerne mal sehen. Die würde nämlich keinen Sinn machen.
robbitop
2004-03-10, 15:01:55
nein es geht mir sehr wohl um die Texturen.
der SS Anteil bei 4xS glättet nur in eine Richtung 1x2
der SSAnteil bei 8xS glättet in beide Richtungen 1x2 + 2x1
bei meinem utopischen 2xRGSS anteil hätte ich 2x2 für alpha Texturen.
Also vom Glättungsgrad der alphaTexkanten derselbe Effekt. Die Texturschärfe allerdings, da hast du recht ist bei 4xOG größer...aber 4xS und 8xAF sind die Texturen wirklich schon scharf genug ;)
geht mir also nur noch um noch bessere Kantenglättung bei alphatex
Original geschrieben von robbitop
nein es geht mir sehr wohl um die Texturen.
der SS Anteil bei 4xS glättet nur in eine Richtung 1x2
der SSAnteil bei 8xS glättet in beide Richtungen 1x2 + 2x1
bei meinem utopischen 2xRGSS anteil hätte ich 2x2 für alpha Texturen.EER-mäßig, ja. Aber man kann RGSSAA nicht einfach mit RGMSAA kombinieren. Anstatt sich zu überlegen, Alphatest-Kanten zu glätten, sollten die Content-Ersteller lieber auf solchen Unsinn verzichten.
robbitop
2004-03-10, 15:25:07
aber es bringt performance.
Wenn man unglaublich viel Schilder aufstellt und bäume und all diese auf Polygonen basierend wären, würden heutige Systeme sicher einbrechen.
Die Zeit ist wohl noch nicht reif
Exxtreme
2004-03-10, 15:30:43
Original geschrieben von aths
Anstatt sich zu überlegen, Alphatest-Kanten zu glätten, sollten die Content-Ersteller lieber auf solchen Unsinn verzichten.
Werden sie aber so schnell nicht machen. Die "Ersatztechnologien" dafür bringen weitere Nachteile mit sich. Die neueren Titel mit diesen Technologien dürften nur mit absoluter Highend-HW spielbar sein. Demirug hat mal vorgerechnet was z.B. Alphablending an Bandbreite wegschluckt.
Original geschrieben von robbitop
aber es bringt performance.Das sicher. Es ist aber "falsch".
Original geschrieben von robbitop
Die Zeit ist wohl noch nicht reif Die CPUs werden immer schneller, die Bandbreite ist inzwischen da (AGPx4) und die Vertex-Power ist auch da (ab Radeon 9600 und erst recht ab FX 5700.)
Original geschrieben von Exxtreme
Werden sie aber so schnell nicht machen. Die "Ersatztechnologien" dafür bringen weitere Nachteile mit sich. Die neueren Titel mit diesen Technologien dürften nur mit absoluter Highend-HW spielbar sein. Demirug hat mal vorgerechnet was z.B. Alphablending an Bandbreite wegschluckt. An Alphablending dachte ich hier gar nicht. Imo sollte man Modelle mit Geometrie modellieren. Alphablending verballert Bandbreite, aber das Bild sieht deutlich besser aus als mit Alphatesting. Alphablending saugt aber, wenn man den Objekten sehr nahe kommt.
Ich glaube nicht, dass man "absolute Highend-HW" braucht. Lediglich kann man vergessen, dass sowas auf GF2 MX noch brauchbar läuft.
Was für HW bräuchte man, um die Artefakte mit 4x RGSSAA zu mindern (von wegkriegen kann ja keine Rede sein)? Dann lieber was, was nicht auf RGSSAA setzt und vor allem "richtig" ist.
Das gammacorrected downfiltering ist ja mathematisch gesehen nicht unbedingt richtig
Erläuterung? Den einfachen Mittelwert der Samples rechnen ist auf jeden Fall nicht korrekt.
Original geschrieben von Coda
Erläuterung? Den einfachen Mittelwert der Samples rechnen ist auf jeden Fall nicht korrekt. Das ist dann nicht korrekt, wenn das Ausgabe-Gerät eine nichtlineare Wiedergabe hat.
ATI rechnen korrekt für Gamma 2,2. Nicht jedes Gerät braucht zur Linearisierung genau diese Gammakorrektur. ATI berücksichtigt auch nicht den Gammawert, den man im CP oder im Spiel einstellt.
Richtig. Aber es ist immer noch besser als linear zu rechnen, zumindest auf der absoluten Mehrzahl der Monitore
Original geschrieben von Coda
Richtig. Aber es ist immer noch besser als linear zu rechnen, zumindest auf der absoluten Mehrzahl der Monitore Es ist besser, aber nicht "korrekt". Da die Verbreitung von TFTs zunimmt, sollte ATI bald mal die Möglichkeit einbauen, die Gamma-Gegenkorrektur zu deaktivieren.
TFTs haben doch auch Gamma, oder irre ich mich da?
Exxtreme
2004-03-10, 19:32:13
Original geschrieben von aths
An Alphablending dachte ich hier gar nicht. Imo sollte man Modelle mit Geometrie modellieren. Alphablending verballert Bandbreite, aber das Bild sieht deutlich besser aus als mit Alphatesting. Alphablending saugt aber, wenn man den Objekten sehr nahe kommt.
Ich glaube nicht, dass man "absolute Highend-HW" braucht. Lediglich kann man vergessen, dass sowas auf GF2 MX noch brauchbar läuft.
Ähhhem, Demi hat mal was von 60 GB/s ausgerechnet bei einer R9800XT. Diese Bandbreite bräuchte man in Extremfällen. Und vergiss auch nicht die höhere CPU-Belastung beim Alphablending.
Und wenn man mit Polygonen ausmodellieren will, dann belastet das die CPU auch. Die GraKa kann nämlich die Vertices nicht selbst erzeugen. Da muss noch die CPU ran.
Original geschrieben von aths
Was für HW bräuchte man, um die Artefakte mit 4x RGSSAA zu mindern (von wegkriegen kann ja keine Rede sein)? Dann lieber was, was nicht auf RGSSAA setzt und vor allem "richtig" ist.
Also ich sehe nichts "Falsches" an Alphatesting bzw. ich sehe Alphablending nicht als "richtiger" an.
Original geschrieben von Coda
TFTs haben doch auch Gamma, oder irre ich mich da? TFTs haben eine einigermaßen lineare Wiedergabe.
Original geschrieben von Exxtreme
Ähhhem, Demi hat mal was von 60 GB/s ausgerechnet bei einer R9800XT. Diese Bandbreite bräuchte man in Extremfällen. ... die in der Praxis so nicht auftreten.
Original geschrieben von Exxtreme
Und vergiss auch nicht die höhere CPU-Belastung beim Alphablending.Besser als 4x GPU-Belastung durch Supersampling.
Original geschrieben von Exxtreme
Und wenn man mit Polygonen ausmodellieren will, dann belastet das die CPU auch. Die GraKa kann nämlich die Vertices nicht selbst erzeugen. Da muss noch die CPU ran.Weiß ich. Die CPU habe ich in diesem Zusammenhang auch erwähnt. Mit Vertex Buffern kann man die CPU aber entlasten. Die lokal gespeicherte Geometrie muss dann nur noch einmal erzeugt werden.
Original geschrieben von Exxtreme
Also ich sehe nichts "Falsches" an Alphatesting bzw. ich sehe Alphablending nicht als "richtiger" an. Alphatesting ist falsch, weil die Texturfilterung damit nicht mehr richtig funktioniert. Alphablending ist nicht viel richtiger, im Ergebnis aber besser. Richtig ist Modellierung mit Geometrie.
Demirug
2004-03-10, 19:42:51
aths, ein Drahtzaun als Geometrie killt dir jede Grafikkarte.
Z-Texturen und Alphatest/Pixelkill sind nach wie vor die beste Lösung für solche Darstellungen. Um das AA-Problem in den Griff zu bekommen müsste man selektives SS oder noch besser Subpixelshader erlauben.
Exxtreme
2004-03-10, 19:50:59
Original geschrieben von aths
... die in der Praxis so nicht auftreten.
Alphablending killt aber leider in der Praxis die Performance. Zock mal UT2003 einmal mit und einmal ohne Alphablending. Klar sind die 60 GB/s nicht wirklich in der Praxis anzutreffen.
Original geschrieben von aths
Besser als 4x GPU-Belastung durch Supersampling.
Ansichtssache. :)
Original geschrieben von aths
Weiß ich. Die CPU habe ich in diesem Zusammenhang auch erwähnt. Mit Vertex Buffern kann man die CPU aber entlasten. Die lokal gespeicherte Geometrie muss dann nur noch einmal erzeugt werden.
Bei einigen Millionen Polygonen frisst das Bandbreite und Speicherplatz weg.
Original geschrieben von aths
Alphatesting ist falsch, weil die Texturfilterung damit nicht mehr richtig funktioniert. Alphablending ist nicht viel richtiger, im Ergebnis aber besser. Richtig ist Modellierung mit Geometrie.
Ein Spiel wie Gothic 2 komplett ausmodelieren wird dir AFAIK jede heute verfügbare GraKa killen. Die Polygone werden so klein, daß die Pipelines nicht mehr vollständig genutzt werden können. Und es könnte auch passieren, daß die Z-Buffer-Genauigkeit nicht mehr richtig reicht und es zu Z-Fehlern kommt.
P.S. Und nur weil die Texturfilterung nicht damit zurechtkommt, ist das falsch? Wieso nicht die Texturfilterung verbessern? :gruebel:
Quasar
2004-03-10, 20:04:19
Original geschrieben von aths
Anstatt sich zu überlegen, Alphatest-Kanten zu glätten, sollten die Content-Ersteller lieber auf solchen Unsinn verzichten.
Schön und gut, aber was machst du mit bereits erhältlichem Content? Ignorieren? Ertragen?
Oder schlicht und einfach im Treiber zur Not auch OGSS freischalten - denn im Lande der Blinden ist der Einäugige König, auch wenn's die Blinden natürlich nicht wahrhaben wollen. ;)
TFTs haben eine einigermaßen lineare Wiedergabe.
Dann müsste das Bild auf einem TFT völlig anders aussehen als auf einem CRT.
Kann nicht sein.
Quasar
2004-03-10, 20:33:05
Original geschrieben von aths
Besser als 4x GPU-Belastung durch Supersampling.
Wirklich?
Was mache ich, wenn mit meinem aktuellen Sys (s.Sig.) ein Game mit 4xSS nicht richtig läuft: Ich kann darauf verzichten und ich kann die Auflösung senken.
Was mache ich, wenn aber ein Game, welches dein Forderung nach heftigster Geometrie erfüllt, nicht mehr ordentlich läuft?
CPU, Board und RAM wegwerfen und neue Hardware kaufen?
Sorry, aber die Option auf Supersampling, bzw. den Verzicht darauf, ist mir ehrlich gesagt lieber.
Ailuros
2004-03-10, 22:07:38
Original geschrieben von robbitop
nein es geht mir sehr wohl um die Texturen.
der SS Anteil bei 4xS glättet nur in eine Richtung 1x2
der SSAnteil bei 8xS glättet in beide Richtungen 1x2 + 2x1
bei meinem utopischen 2xRGSS anteil hätte ich 2x2 für alpha Texturen.
Also vom Glättungsgrad der alphaTexkanten derselbe Effekt. Die Texturschärfe allerdings, da hast du recht ist bei 4xOG größer...aber 4xS und 8xAF sind die Texturen wirklich schon scharf genug ;)
geht mir also nur noch um noch bessere Kantenglättung bei alphatex
Nein. Bei 4xS werden (und dabei ist es egal ob der Algorithmus einen sparse oder ordered grid hat) Texturen nur immer in jeweils eine Richtung gefiltert.
2x RGMS und 2x RGSS, diese Maske würde ich gerne mal sehen. Die würde nämlich keinen Sinn machen.
Wollte ich auch lesen ;)
Welcher ROP-Trick?
Dein eigener Kommentar:
Nur bei bilinearem Singletexturing. Bei trilinearem 2x-Texturing wäre die Füllrate ggü. 1x AA kaum noch gesunken.
Warum wohl? (ich denke Du weisst was ich meine).
Ailuros
2004-03-10, 22:13:08
Original geschrieben von Exxtreme
Alphablending killt aber leider in der Praxis die Performance. Zock mal UT2003 einmal mit und einmal ohne Alphablending. Klar sind die 60 GB/s nicht wirklich in der Praxis anzutreffen.
Ansichtssache. :)
Bei einigen Millionen Polygonen frisst das Bandbreite und Speicherplatz weg.
Ein Spiel wie Gothic 2 komplett ausmodelieren wird dir AFAIK jede heute verfügbare GraKa killen. Die Polygone werden so klein, daß die Pipelines nicht mehr vollständig genutzt werden können. Und es könnte auch passieren, daß die Z-Buffer-Genauigkeit nicht mehr richtig reicht und es zu Z-Fehlern kommt.
P.S. Und nur weil die Texturfilterung nicht damit zurechtkommt, ist das falsch? Wieso nicht die Texturfilterung verbessern? :gruebel:
Mal ne ganz dumme Frage Exxtreme; Du bist nicht auch zufaellig ein Fan von TBDR oder? Wenn nicht dann ueberleg nochmal das obrige genauer (ja soll nur ein Witz sein) :D
Original geschrieben von Ailuros
Warum wohl? (ich denke Du weisst was ich meine). ??? NV25 hat, wie NV20 auch, 4 ROPs pro Pipe.
Exxtreme
2004-03-10, 22:23:57
Original geschrieben von Ailuros
Mal ne ganz dumme Frage Exxtreme; Du bist nicht auch zufaellig ein Fan von TBDR oder? Wenn nicht dann ueberleg nochmal das obrige genauer (ja soll nur ein Witz sein) :D
Nein, ich bin nicht unbedingt ein Fan der TBDR-Technologie ... warum? Ich bin eher ein Fan von glatten Kanten und diese Ansprüche erfüllt MSAA leider in vielen Fällen nicht. Ich wusste zwar, was MSAA kann und nicht kann als ich mir die R9700Pro holte. Aber daß es soviele Spiele gibt, bei denen sich die Nachteile des MSAA offenbaren, damit habe ich nicht im Entferntesten gerechnet.
Original geschrieben von Exxtreme
Alphablending killt aber leider in der Praxis die Performance. Zock mal UT2003 einmal mit und einmal ohne Alphablending.Wo kann man das einstellen?
Original geschrieben von Exxtreme
Ansichtssache. :)Ich wundere mich über deine Argumenation. Auf der einen Seite führst du die Graka-Last durch Bandbreiten-Verbrauch von Alphablending als Negativ-Argument ins Feld, auf der anderen Seite schwärmst du dauernd von Supersampling.
Original geschrieben von Exxtreme
Bei einigen Millionen Polygonen frisst das Bandbreite und Speicherplatz weg."Geometrisches LOD".
Original geschrieben von Exxtreme
Ein Spiel wie Gothic 2 komplett ausmodelieren wird dir AFAIK jede heute verfügbare GraKa killen. Die Polygone werden so klein, daß die Pipelines nicht mehr vollständig genutzt werden können. Und es könnte auch passieren, daß die Z-Buffer-Genauigkeit nicht mehr richtig reicht und es zu Z-Fehlern kommt.Hm? Was hat die Z-Genauigkeit mit der Polygonzahl zu tun?
Mit geometrischem LOD kann man die Polygone schon groß genug halten. Für vieles kann man auch Alphablending nehmen, z. B. für Baumkronen.
Original geschrieben von Exxtreme
P.S. Und nur weil die Texturfilterung nicht damit zurechtkommt, ist das falsch? Wieso nicht die Texturfilterung verbessern? :gruebel: Sagt dir "Nyquist-Kriterium" was?
Original geschrieben von Coda
Dann müsste das Bild auf einem TFT völlig anders aussehen als auf einem CRT.
Kann nicht sein. Nicht "völlig" anders, aber anders. Welche Gammakorrektur ist für CRTs optimal? Etwa 1,7 - 2,5. Ich wüsste keinen TFT-User, der mit so hohen Gammawerten spielt.
Original geschrieben von Quasar
Sorry, aber die Option auf Supersampling, bzw. den Verzicht darauf, ist mir ehrlich gesagt lieber. Als Option ist OGSSAA auf GF-Karten ja auch möglich. Wenn es auch nicht viel Sinn hat, mit OGSSAA zu arbeiten, bei extremer CPU-Limitierung kann man es nehmen. Im Thread gehts aber um NV40-HW. Keiner rechnet ernsthaft damit, dass er 4x JGSSAA hat. Ich glaube nicht, dass es in absehbarer Zeit solche HW geben wird. Das beste ist, wenn zukünftige Spiele auf Alphatesting verzichten.
Original geschrieben von Demirug
aths, ein Drahtzaun als Geometrie killt dir jede Grafikkarte.
Z-Texturen und Alphatest/Pixelkill sind nach wie vor die beste Lösung für solche Darstellungen. Um das AA-Problem in den Griff zu bekommen müsste man selektives SS oder noch besser Subpixelshader erlauben. Subpixelkill wäre eine Möglichkeit, ja.
Ailuros
2004-03-10, 22:31:45
Original geschrieben von aths
??? NV25 hat, wie NV20 auch, 4 ROPs pro Pipe.
Ja und? Bei Rampage wurde Pixel Fuellrate aufgeopfert, damit die Texel Fuellraten intakt bleibt.
Ailuros
2004-03-10, 22:34:27
Original geschrieben von Exxtreme
Nein, ich bin nicht unbedingt ein Fan der TBDR-Technologie ... warum? Ich bin eher ein Fan von glatten Kanten und diese Ansprüche erfüllt MSAA leider in vielen Fällen nicht. Ich wusste zwar, was MSAA kann und nicht kann als ich mir die R9700Pro holte. Aber daß es soviele Spiele gibt, bei denen sich die Nachteile des MSAA offenbaren, damit habe ich nicht im Entferntesten gerechnet.
Weil es die einzige Architektur ist, die - bis auf die Fuellrate - keine Bandbreiten Probleme mit SSAA hat, einen wesentlich kleineren memory footprint erlaubt, back2front/alpha-Quark kein Problem darstellen usw usw. War eigentlich ein sarkastischer Kommentar <shrug>.
Mir ist selbst ein Tiler mit MSAA lieber :weg:
Exxtreme
2004-03-10, 22:38:36
Original geschrieben von aths
Wo kann man das einstellen?
Mist. Den genauen Namen für diese Option kenne ich leider nicht. Ich müsste Windows booten um UT2003 zu starten ... ;(
Original geschrieben von aths
Ich wundere mich über deine Argumenation. Auf der einen Seite führst du die Graka-Last durch Bandbreiten-Verbrauch von Alphablending als Negativ-Argument ins Feld, auf der anderen Seite schwärmst du dauernd von Supersampling.
Natürlich. Die von dir beschriebenen "Ausweichsmöglichkeiten" killen die GraKa oder die CPU schon bevor man ans AA überhaupt denken kann.
Original geschrieben von aths
"Geometrisches LOD".
Kann das die GraKa alleine oder muss wieder die CPU ran? Ansonsten wäre es in der Tat eine Möglichkeit.
Original geschrieben von aths
Hm? Was hat die Z-Genauigkeit mit der Polygonzahl zu tun?
Es könnte Z-Fehler geben? Diese gibt es schon in einigen Spielen. Und AFAIK wird das Problem mit steigender Polygonanzahl immer schlimmer.
Original geschrieben von aths
Sagt dir "Nyquist-Kriterium" was?
Sagen tut es mir was aber leider verstehe ich es nicht richtig. :(
robbitop
2004-03-10, 22:54:17
hat das etwas mit einem Kosten/Nutzen Verhältnis zu tun?
Exxtreme
2004-03-10, 22:55:50
Original geschrieben von robbitop
hat das etwas mit einem Kosten/Nutzen Verhältnis zu tun?
AFAIK irgendwas mit "Stabilität".
Original geschrieben von aths
Nicht "völlig" anders, aber anders. Welche Gammakorrektur ist für CRTs optimal? Etwa 1,7 - 2,5. Ich wüsste keinen TFT-User, der mit so hohen Gammawerten spielt.
Windows PCs haben nen Gamma Wert von 2.5
Die TFTs müssen sich daran anpassen, sonst stimmt das Bild nicht.
Es kann sein, dass die TFT Zellen linear reagieren, aber die Elektronik regelt das definitiv nicht so
Probier einfach mal aus einen linearen Farbverlauf mit einem Program darstellen zu lassen und du wirst sehen was ich meine (auch sehr gut zu sehen bei alten Windows Version an den Fensterleisten...)
zeckensack
2004-03-10, 23:10:08
Original geschrieben von Exxtreme
AFAIK irgendwas mit "Stabilität". Nein. Onkel Nyquist sagt, dass man in der digitalen Signalverarbeitung nur Frequenzen mit einer Periode von maximal der halben Abtastrate überhaupt repräsentieren kann.
Überschreitet man diese Frequenz, kommt es zu Aliasing.
Das ist der Grund, warum alle Audio-CD-Player einen recht steilen Tiefpass bei <=22,05kHz ansetzen müssen (obwohl das Medium mit 44,1 Samples pro Sekunde auflöst). Auch bei der Produktion, also bei der Konvertierung von analog nach digital ist ein solcher Tiefpassfilter erforderlich. Man muss diese hohen Frequenzen um jeden Preis aus dem Material heraushalten.
Onkel Nyquist ist auch der Grund dafür, warum texturierte 3D-Grafik mit stark negativem LOD-Bias shice aussieht :D
Was aths nun IMO meinte, war dass die aktuellen Texturfilter nicht verbesserungswürdig sind, weil sie eben das Maximum an Schärfe aus jedem gegebenen Material herausholen können (das Nyquist-Kriterium wird so gerade eben nicht verletzt).
Exxtreme
2004-03-10, 23:15:34
Original geschrieben von zeckensack
Nein. Onkel Nyquist sagt, dass man in der digitalen Signalverarbeitung nur Frequenzen mit einer Periode von maximal der halben Abtastrate überhaupt repräsentieren kann.
Überschreitet man diese Frequenz, kommt es zu Aliasing.
Das ist der Grund, warum alle Audio-CD-Player einen recht steilen Tiefpass bei <=22,05kHz ansetzen müssen (obwohl das Medium mit 44,1 Samples pro Sekunde auflöst). Auch bei der Produktion, also bei der Konvertierung von analog nach digital ist ein solcher Tiefpassfilter erforderlich. Man muss diese hohen Frequenzen um jeden Preis aus dem Material heraushalten.
Onkel Nyquist ist auch der Grund dafür, warum texturierte 3D-Grafik mit stark negativem LOD-Bias shice aussieht :D
Was aths nun IMO meinte, war dass die aktuellen Texturfilter nicht verbesserungswürdig sind, weil sie eben das Maximum an Schärfe aus jedem gegebenen Material herausholen können (das Nyquist-Kriterium wird so gerade eben nicht verletzt).
ARRGHH!!11 BRUJO!!1 Stimmt. Das habe ich total vergessen. :|
Original geschrieben von Coda
Windows PCs haben nen Gamma Wert von 2.52,2.
Original geschrieben von Coda
Es kann sein, dass die TFT Zellen linear reagieren, aber die Elektronik regelt das definitiv nicht so
Xmas nutzt auf seinem TFT gerne eine Gammakorrektur < 1,0 :)
Original geschrieben von Exxtreme
Natürlich. Die von dir beschriebenen "Ausweichsmöglichkeiten" killen die GraKa oder die CPU schon bevor man ans AA überhaupt denken kann.Nö. Max Payne z. B. arbeitet teilweise mit Alphablending, und ist nicht gerade ein Hardwarefresser.
Original geschrieben von Exxtreme
Kann das die GraKa alleine oder muss wieder die CPU ran? Ansonsten wäre es in der Tat eine Möglichkeit.Natürlich muss die CPU da ran. Aber bei klugem Algo spart man mehr, als man zunächst zusätzlich reinsteckt.
Original geschrieben von Exxtreme
Es könnte Z-Fehler geben? Diese gibt es schon in einigen Spielen. Und AFAIK wird das Problem mit steigender Polygonanzahl immer schlimmer.Da sehe ich keinen Zusammenhang mit der Polygonzahl.
Original geschrieben von Exxtreme
Sagen tut es mir was aber leider verstehe ich es nicht richtig. :( Wenn das Nyquist-Kriterium verletzt wird, hat man Aliasing. Alphatesting führt zur Verletzung dieses Kriteriums, ganz besonders dann, wenn man AF aktiviert. Da kann der Texturfilter nix dran machen. Das liefe letztlich auf Alphablending hinaus, und das geht nur vernünftig mit Back2Front-Sorting.
Durch den Alphatest verworfene Pixel werden ja eben *nicht* gefiltert. Da kann man die Texturfilterung noch so verbessern. Der Fehler ist systemimmanent. Alphatesting ist halt "falsch".
marco42
2004-03-10, 23:55:54
Original geschrieben von aths
Alphatesting ist falsch, weil die Texturfilterung damit nicht mehr richtig funktioniert. Alphablending ist nicht viel richtiger, im Ergebnis aber besser. Richtig ist Modellierung mit Geometrie.
Hast du schon einmal einen Baum in Geometry gegossen? Oder denk mal an einen Loewenzahn, Grass ist da recht einfach. Das erzeugt Unmengen an Punkten und mit LOD ist das auch nicht so einfach, zumindestens es nicht poppen soll.
Ein Bekannter (http://www.computerpflanzen.de/) von mir hat mal eine Wiese (http://www.xfrogdownloads.com/greenwebNew/gallery/images/Landscapes/landscape1.jpg) mmodelliert. Glaub mir, sowas bekommst du nicht ohne Tricks in Real-Time hin.
marco42
2004-03-11, 00:00:49
Original geschrieben von aths
Durch den Alphatest verworfene Pixel werden ja eben *nicht* gefiltert. Da kann man die Texturfilterung noch so verbessern. Der Fehler ist systemimmanent. Alphatesting ist halt "falsch".
Naja, es ist ein Step Filter, also auch ein Filter, aber halt der mit maximalen Aliasing. Aber auch die Linearen Filter sind nicht optimal.
Original geschrieben von marco42
Hast du schon einmal einen Baum in Geometry gegossen? Oder denk mal an einen Loewenzahn, Grass ist da recht einfach. Das erzeugt Unmengen an Punkten und mit LOD ist das auch nicht so einfach, zumindestens es nicht poppen soll. Ganz einfach ist das nicht, ja. Letztlich wird es ohnehin kommen. Bei Gras kann man auch teilweise mit Alphablending arbeiten. Solche völlig ausmodellierten Landschaften werden wir in näherer Zukunft noch nicht sehen, das ist klar. Was ich auf keinen Fall sehen will, ist Alphatest-Geflimmer in Baumkronen und Gras.
Original geschrieben von marco42
Naja, es ist ein Step Filter, also auch ein Filter, aber halt der mit maximalen Aliasing. Aber auch die Linearen Filter sind nicht optimal. Hier habe ich Probleme, dir zu folgen.
marco42
2004-03-11, 01:41:32
Original geschrieben von aths
Ganz einfach ist das nicht, ja. Letztlich wird es ohnehin kommen. Bei Gras kann man auch teilweise mit Alphablending arbeiten. Solche völlig ausmodellierten Landschaften werden wir in näherer Zukunft noch nicht sehen, das ist klar. Was ich auf keinen Fall sehen will, ist Alphatest-Geflimmer in Baumkronen und Gras.
Hier habe ich Probleme, dir zu folgen.
Es gibt verschiedene Art von Filter. Ein Step Filter ist einfach 0 bei kleiner als X und 1 bei groesser als X. Kennst du Principles of Image Sythesis. Da ist das schone erklaert. Oder noch besser Texturing and Modelling. Das ist ueber proceduale Texturen. Da ist Filtering sehr schoen erklaert.
MadManniMan
2004-03-11, 03:21:02
Original geschrieben von aths
Nö. Max Payne z. B. arbeitet teilweise mit Alphablending, und ist nicht gerade ein Hardwarefresser.
Und muckt - genau wie Teil 1 - hin und wieder beim Sortier0rn rum ;)
BTW säh das bestmögliche 2*RGMS/2*RGSS-Muster folgendermaßen aus:
Aquaschaf
2004-03-11, 08:37:30
Nicht vergessen, dass Alphatesting/Alphablending nicht nur gegenüber vollständiger Ausmodelierung Leistung spart, sondern auch jede Menge Arbeit.
Ailuros
2004-03-11, 08:53:02
Original geschrieben von MadManniMan
Und muckt - genau wie Teil 1 - hin und wieder beim Sortier0rn rum ;)
BTW säh das bestmögliche 2*RGMS/2*RGSS-Muster folgendermaßen aus:
Na das Gekritzel (errr sorry...) ist ein bisschen schwer zu entziffern, aber wenn es das ist was ich verdaechtige, dann ist es eher eine schlechte Idee.
Exxtreme
2004-03-11, 09:46:29
Original geschrieben von aths
Durch den Alphatest verworfene Pixel werden ja eben *nicht* gefiltert. Da kann man die Texturfilterung noch so verbessern. Der Fehler ist systemimmanent. Alphatesting ist halt "falsch".
Tja, wie wäre es dann, wenn man SSAA nur für die betroffenen Pixel aktiviert? Die GraKa weiss es ja wo das Alphatesting stattfindet. Gut, es wäre keine Aufgabe mehr der Texturfilter, würde aber auf's gleiche hinauslaufen.
P.S. Lass dich nicht wegen meiner Vorliebe zum SSAA verrückt machen. Ich sehe die Sache aus Gamer-Sicht. Und ich schätze die Wahrscheinlichkeit als sehr viel höher ein, daß SSAA Einzug finden wird, als daß die Spielehersteller den alten Content ändern.
marco42
2004-03-11, 12:05:45
Original geschrieben von Aquaschaf
Nicht vergessen, dass Alphatesting/Alphablending nicht nur gegenüber vollständiger Ausmodelierung Leistung spart, sondern auch jede Menge Arbeit.
Das wuerde ich nicht so einfach sagen.
Ailuros
2004-03-11, 13:00:22
P.S. Lass dich nicht wegen meiner Vorliebe zum SSAA verrückt machen. Ich sehe die Sache aus Gamer-Sicht. Und ich schätze die Wahrscheinlichkeit als sehr viel höher ein, daß SSAA Einzug finden wird, als daß die Spielehersteller den alten Content ändern.
Wo siehst Du mehr stoerendes alpha aliasing in frueheren oder neueren Spielen? (eben von der Gamer Perspektive).
Einfaches Beispiel waere 4x4Evo vs Rallisport Challenge.
Uebrigens ich bezweifle dass Deine Tendenz zu SSAA auf irgend eine Weise jemand irritieren koennte. Die Loesung liegt meistens irgendwo in der Mitte; wenn man jetzt stellenweise SSAA u.a. einsetzt (wie schon des oefteren erwaehnt wurde) kann man einfach die Vorteile von MS- und SSAA kombinieren und zu optimalem output kommen. So wie es aussieht muss man das wohl dann eher den ISVs ueberlassen.
Resourcen (Fuellrate, Bandbreite etc etc.) skalieren staendig nach oben je komplexer Grafik-chips werden; da macht es technisch gesehen mehr Sinn die problematischen Faelle (die sowieso nur kleine Prozentuale einer Szene betreffen) getrennt zu behandeln, anstatt ein Uebermass von Fuellrate und Leistung unnoetig fuer ausschliessliches SSAA zu verbrennen.
Zu guter letzt: Multisampling oder auch zukuenftige moegliche edge-AA Algorithmen erlauben eine um einiges groessere Skalierung der Anzahl von samples ohne die Bandbreite besonders zu ueberfordern. Und ich meine jetzt nicht unbedingt dieses oder naechstes Jahr und auch nicht nur 8x oder 16x samples.
Quasar
2004-03-11, 13:10:42
Original geschrieben von aths
Als Option ist OGSSAA auf GF-Karten ja auch möglich. Wenn es auch nicht viel Sinn hat, mit OGSSAA zu arbeiten, bei extremer CPU-Limitierung kann man es nehmen.
Oder bei durch TFT/Game-Engine beschränkter Auflösung, ja.
Original geschrieben von aths
Im Thread gehts aber um NV40-HW.
Das ist mir bewußt.
Aber da ich auch beim nV40 mit steigender Rohleistung rechne, wird SSAA wieder für ein paar Spiele mehr zur Option.
Original geschrieben von aths
Keiner rechnet ernsthaft damit, dass er 4x JGSSAA hat.
Nein, nicht ernsthaft. Aber 'nett' wäre es schon, wenn das TriSetup für Besseres als OGAA ausgelegt wäre, sollten doch entsprechende Supersampling-Optionen nicht so furchtbar schwierig sein.
Original geschrieben von aths
Das beste ist, wenn zukünftige Spiele auf Alphatesting verzichten.
Das Beste wär's, wenn *Utopien rausgekürzt*.
Man kriegt dummerweise nur selten das, was man für das Beste hält.
Original geschrieben von MadManniMan
Und muckt - genau wie Teil 1 - hin und wieder beim Sortier0rn rum ;)
BTW säh das bestmögliche 2*RGMS/2*RGSS-Muster folgendermaßen aus: Das ist ingesamt ein Shicemuster.
Original geschrieben von Exxtreme
Tja, wie wäre es dann, wenn man SSAA nur für die betroffenen Pixel aktiviert? Das geht nicht so einfach. Oder anders gesagt geht das nur, wenn gleichzeitig schon MSAA aktiv ist, damit die Multisample-Buffer genutzt werden können.
Original geschrieben von Exxtreme
Die GraKa weiss es ja wo das Alphatesting stattfindet. Ja und nein. Für die ganze Textur SSAA zu aktivieren = Füllratenverlust³. Was willst du aber ansonst machen? Erst mal Alphatesten, und dann mit einer Filterbox gucken wo überall gekillt wurde, um die Umgebung nachträglich zu Supersampeln?
Original geschrieben von Exxtreme
Gut, es wäre keine Aufgabe mehr der Texturfilter, würde aber auf's gleiche hinauslaufen.Ich würde gerne konkrete Vorschläge hören :)
Original geschrieben von Exxtreme
Und ich schätze die Wahrscheinlichkeit als sehr viel höher ein, daß SSAA Einzug finden wird, als daß die Spielehersteller den alten Content ändern. Damit die Karte gegenüber der Konkurrenz langsamer wird?
Über kurz oder lang wird es eine Möglichkeit zum Supersampling im Pixelshader geben. Ob das für Alphatexturen sinnvoll nutzbar sein wird, kann ich nicht abschätzen.
Ailuros
2004-03-11, 13:22:35
Original geschrieben von aths
Das ist ingesamt ein Shicemuster.
Meine Version war leicht hoeflicher :D
Original geschrieben von aths
Xmas nutzt auf seinem TFT gerne eine Gammakorrektur < 1,0 :)
Auf dem Desktop. Das ist aber etwas anderes, da praktisch alle Bilder und Farben darauf ausgelegt werden, auf einem CRT mit den Standardeinstellungen (Sprich Gamma=1.0 im CP) ordentlich aussehen. Dennoch ist ein TFT nichtlinear, nur brauche ich bei meinem TFT kein Gamma=2.2 um Linearität zu erreichen.
Das Problem mit dem "gammakorrigierten AA" hatten wir ja schon in einem anderen Thread. Korrekterweise sollte die GPU alles im linearen Farbraum rechnen, und nur noch die finale Ausgabe an den Monitor angepasst werden.
Original geschrieben von Quasar
Das ist mir bewußt.
Aber da ich auch beim nV40 mit steigender Rohleistung rechne, wird SSAA wieder für ein paar Spiele mehr zur Option.Das schon. Allerdings nur OGSSAA.
Original geschrieben von Quasar
Nein, nicht ernsthaft. Aber 'nett' wäre es schon, wenn das TriSetup für Besseres als OGAA ausgelegt wäre, sollten doch entsprechende Supersampling-Optionen nicht so furchtbar schwierig sein.Die sollten sehr einfach sein.
Original geschrieben von Quasar
Das Beste wär's, wenn *Utopien rausgekürzt*.
Man kriegt dummerweise nur selten das, was man für das Beste hält. Es macht jedenfalls keinen Sinn, am falschen Ende zu flicken.
MadManniMan
2004-03-11, 14:15:34
Original geschrieben von Ailuros
Meine Version war leicht hoeflicher :D
Hab ich behauptet, ihr hättet Unrecht? :naughty:
marco42
2004-03-11, 14:33:57
Original geschrieben von aths
Über kurz oder lang wird es eine Möglichkeit zum Supersampling im Pixelshader geben. Ob das für Alphatexturen sinnvoll nutzbar sein wird, kann ich nicht abschätzen.
Alpha Testing findet auf Fragmenten statt. Es hat direkt also nichts mit dem Textureing und Shading zu tun. Es schaut sich den Alpha Wert an, und schmeisst das Fragment dann weg oder laesst es durch. Wenn du mehrere Fragmente pro Pixel hast, dann gehen halt ein paar durch und ein paar nicht. Du musst die jetzt aber auch im Framebuffer haben, da du sie ja noch mit spaeteren Fragmenten fuer den gleichen Pixel mixen musst. Der Vorteil ist einfach, das du eine konstante Anzahl von Fragmenten pro Pixel hast. Du also eine sehr einfache Speicherverwaltung hast.
Das Problem liesse sich auch loesen, dass fuer alle Alphawerte != 0 oder 1 eine Liste im Framebuffer angelegt wird. Und diese dann vor dem Framebufferswap geblendet werden. Du wuerdest praktische alsoein verzoegertes Alpha Blending einfuehren. Wenn du es nur an Kanten machen wuerdest waere es wahrscheinlich sogar sparsamer als Supersampling, wuerde aber aufwendiger von der Verwaltung her sein. Es duerfte Qualitaetsmessig den Supersampling ueberlegen sein. Fuer diese Tolle Technik gibt es auch einen Namen, den ich mal wieder vergessen habe. :-)
raffa
2004-03-11, 14:36:48
ich lese hier immer wieder von nem Gamma von 2.2, auf das Ati sein gammakorregiertes AA abgestimmt hat (oder so ähnlich)
was fürn Gammawert ist denn damit gemeint, ein Gamma von 2.2 im CP??
standart is bei mir hier (voodoo 5 an CRT) 1.3, das passt bei den meisten games ganz gut, bei cs dreh ich etwas höher, so auf 1.5-1.6. 2.2 scheint mir doch ein wenig hoch, wird dann schon arg blass das ganze.
---
btw, ich würde mich auch über ein optionales 4xRGSS AA bei den neuen karten freuen.
Wäre es denn theoretisch möglich, den User selbst bestimmen zu lassen, welchen Gamma-Wert er haben will ? Oder sind diese Eigenschaften so stark an das jeweilige AA-Verfahren gebunden, dass dies generell nicht möglich / bzw. sogar unsinnig ist ?
Quasar
2004-03-11, 17:29:28
Original geschrieben von aths
Es macht jedenfalls keinen Sinn, am falschen Ende zu flicken.
Doch, nämlich in dem Fall, wenn man an das "richtige Ende" nicht herankommt. ;)
Original geschrieben von raffa
ich lese hier immer wieder von nem Gamma von 2.2, auf das Ati sein gammakorregiertes AA abgestimmt hat (oder so ähnlich)
was fürn Gammawert ist denn damit gemeint, ein Gamma von 2.2 im CP??
standart is bei mir hier (voodoo 5 an CRT) 1.3, das passt bei den meisten games ganz gut, bei cs dreh ich etwas höher, so auf 1.5-1.6. 2.2 scheint mir doch ein wenig hoch, wird dann schon arg blass das ganze.
---
btw, ich würde mich auch über ein optionales 4xRGSS AA bei den neuen karten freuen.
Das ist noch ein Zusätzlicher Gamma Wert. Ich weiß nur nicht ob das Multipliziert oder Addiert wird, aber ich vermute ersteres.
Aquaschaf
2004-03-11, 19:36:50
Original geschrieben von marco42
Das wuerde ich nicht so einfach sagen.
Nimmt man eine Pflanze als Beispiel. Es ist doch wesentlich weniger Arbeit für die Blätter ein flaches, viereckiges Polygon zu nehmen und darauf eine Textur mit Alphatesting/Alphablending zu mappen als ein Blatt auszumodelieren.
marco42
2004-03-11, 21:04:30
Original geschrieben von Aquaschaf
Nimmt man eine Pflanze als Beispiel. Es ist doch wesentlich weniger Arbeit für die Blätter ein flaches, viereckiges Polygon zu nehmen und darauf eine Textur mit Alphatesting/Alphablending zu mappen als ein Blatt auszumodelieren.
Fuer sowas benutzt du ja auch nicht gerade Maya oder 3D Studio. Da gibt es Spezial-Tools. Das Modellieren der Blaetter ist wirklich nicht der groesste Aufwand. Die zu beschaffen, einzusannen etc. kostet sehr viel Zeit. Da sollen ja zB nicht schon Glanzlichter auf dem Blatt sein. Es geht ja auch noch um das Shading. Blatter lassen zB Licht durchscheinen etc..
Original geschrieben von Quasar
Doch, nämlich in dem Fall, wenn man an das "richtige Ende" nicht herankommt. ;) ... wieso, ist denn eine Karte mit RGSSAA angekündigt?
Quasar
2004-03-12, 00:06:07
Besser sogar: Es gibt schon welche!
S3 Delta-Chrome, VSA-100 AFAIK ;)
Im Ernst:
Für's Flicken reicht erstmal auch OGSS. Schließlich kann selbst ich einen Knopf annähen, wenn ich die Hosenbauer schon nicht zu Reißverschlüssen bewegen kann. So gut wie einem richtigen Schneider wird mir das jedoch nur im Ausnahmefall gelingen.
(Analogon ahoi)
Original geschrieben von Quasar
Besser sogar: Es gibt schon welche!
S3 Delta-Chrome, VSA-100 AFAIK ;)
Im Ernst:
Für's Flicken reicht erstmal auch OGSS. Schließlich kann selbst ich einen Knopf annähen, wenn ich die Hosenbauer schon nicht zu Reißverschlüssen bewegen kann. So gut wie einem richtigen Schneider wird mir das jedoch nur im Ausnahmefall gelingen.
(Analogon ahoi) Das ist nun am ganz falschen Ende angesetzt: Extrem viel Leistung zu verballern für ein vergleichsweise kleines Qualitätsplus. In ganz seltenen Ausnahmefällen einsetzbar, aber kein wirklich brauchbares Mittel gegen Aliasing durch Alphatesting.
Quasar
2004-03-12, 00:36:28
Wie gesagt, deine Meinung....
Was machste in dem gar nicht soo seltenen Fall, daß jemand ein 15"-TFT-Display hat, die zumeist auf 1024 begrenzt sind?
Was machst du, wenn es sich um ein älteres Spiel handelt, wo die Auflösung begrenzt ist, so daß du darüber keinen Blumentopf gewinnen kannst?
Naja, ich halte jetzt mal mein Maul zu dem Thema, nicht daß mir jemand noch wegen der offenbar notwendigen Wiederholung der Argumente noch Spamming vorwirft.... (Noch ist das Punktesystem ja nicht abgeschafft).
edit:
Um im Analogon zu bleiben: Bevor du also selbst versuchst, einen Knopf anzunähen, läufst du lieber mit halboffener Hose durch die Gegend? :|
Ailuros
2004-03-12, 03:48:07
Original geschrieben von raffa
ich lese hier immer wieder von nem Gamma von 2.2, auf das Ati sein gammakorregiertes AA abgestimmt hat (oder so ähnlich)
was fürn Gammawert ist denn damit gemeint, ein Gamma von 2.2 im CP??
standart is bei mir hier (voodoo 5 an CRT) 1.3, das passt bei den meisten games ganz gut, bei cs dreh ich etwas höher, so auf 1.5-1.6. 2.2 scheint mir doch ein wenig hoch, wird dann schon arg blass das ganze.
---
btw, ich würde mich auch über ein optionales 4xRGSS AA bei den neuen karten freuen.
Gute Lektuere:
http://www.normankoren.com/makingfineprints1A.html#gammachart
Exxtreme
2004-03-12, 09:33:15
Original geschrieben von aths
Das ist nun am ganz falschen Ende angesetzt: Extrem viel Leistung zu verballern für ein vergleichsweise kleines Qualitätsplus. In ganz seltenen Ausnahmefällen einsetzbar, aber kein wirklich brauchbares Mittel gegen Aliasing durch Alphatesting.
Aths,
wenn der Prophet nicht zum Berg kommen will, dann muss halt manchmal der Berg zum Propheten kommen. Keiner bestreitet, daß du recht hast. Und es mag sein, daß du Alphatesting als "falsch" ansiehst. Nur Leuten, die viele "Alphatesting-verseuchte" Spiele haben, hilft das nicht weiter. Die "Ersatztechnologien" sind leider auch nicht ohne Macken. Was bringt mir ein Spiel, bei dem zwar alles schön mit Polygonen ausmodelliert wurde, dieses aber mit 3 fps läuft? Deine Vorschläge verballern nämlich auch viel Leistung für ein wenig mehr Qualitätsplus. Schau dir mal an wie lahm Morrowind läuft. Dieses nutzt AFAIK viel Alphablending. Und SSAA hat noch ganz andere Vorteile. Es ist quasi die Antialiasing-Maßnahme in Vollendung.
Original geschrieben von Exxtreme
Aths,
wenn der Prophet nicht zum Berg kommen will, dann muss halt manchmal der Berg zum Propheten kommen. Keiner bestreitet, daß du recht hast. G00d =) (Na, im Posting tust du es ja doch.)
Original geschrieben von Exxtreme
Und es mag sein, daß du Alphatesting als "falsch" ansiehst. Wieso "ansiehst"? Alphatesting widerspricht den Prinzipien einer funktionierenden Texturfilterung. Das halte ich für ein Faktum, weniger für eine Sichtweise.
Original geschrieben von Exxtreme
Nur Leuten, die viele "Alphatesting-verseuchte" Spiele haben, hilft das nicht weiter. Die "Ersatztechnologien" sind leider auch nicht ohne Macken. Was bringt mir ein Spiel, bei dem zwar alles schön mit Polygonen ausmodelliert wurde, dieses aber mit 3 fps läuft? Deine Vorschläge verballern nämlich auch viel Leistung für ein wenig mehr Qualitätsplus. Warum forderst du die ganze Zeit OG-Supersampling? Der Trade-off ist hier am schlechtesten.
Original geschrieben von Exxtreme
Schau dir mal an wie lahm Morrowind läuft. Dieses nutzt AFAIK viel Alphablending. Das ist jedoch nicht der Grund, warum MW so lahmt. MWs lahmt vor allem, weil die CPU mit einer Unmenge Drawcalls belastet wird. Die paar Bäume mit Alphablending-Kronen rendert dir mühelos jede GeForce3.
Original geschrieben von Exxtreme
Und SSAA hat noch ganz andere Vorteile. Es ist quasi die Antialiasing-Maßnahme in Vollendung. Es ist größtenteils Verschwendung von Rechenzeit.
Exxtreme
2004-03-12, 09:50:18
Original geschrieben von aths
Warum forderst du die ganze Zeit OG-Supersampling? Der Trade-off ist hier am schlechtesten.
Ich fordere RGSSAA und das gammakorrigiert. Nicht mehr und nicht weniger. :)
P.S. Und MSAA auch noch als Option. =)
Original geschrieben von Exxtreme
Ich fordere RGSSAA und das gammakorrigiert. Nicht mehr und nicht weniger. :) Du hast ein Voting für OGSSAA im R300 unterstützt.
Echte Gammakorrektheit ist btw kaum zu machen. Was ATI macht, ist gamma, aber nicht korrekt :)
Original geschrieben von Exxtreme
P.S. Und MSAA auch noch als Option. =) MSAA gehört die Zukunft.
Quasar
2004-03-12, 10:04:26
aths,
eine abschliessende Frage:
Wenn es im Discounter deines Vertrauens deine Lieblingsspeise nicht gibt und du auch nichts mehr davon zu Hause hast, was tust du dann?
a)
Hungern und warten, bis die nächste Lieferung kommt, auch wenn der Artikel möglicherweise aus dem Sortiment gestrichen wurde oder
b)
Doch etwas anderes zu essen kaufen, was dir eventuell nicht so gut schmeckt und vielleicht nichtmal billiger ist?
Exxtreme
2004-03-12, 10:13:43
Original geschrieben von aths
Du hast ein Voting für OGSSAA im R300 unterstützt.
Lieber OGSSAA als gar kein SSAA. :)
Original geschrieben von aths
MSAA gehört die Zukunft.
Wenn die Contenthersteller mitmachen würden, hätte ich nichts dagegen. Leider machen die Contenthersteller nicht mit. Ihnen ist die Spielbarkeit auf älterer Hardware wichtiger eine "Korrektheit" der Implementation. Und solange das so ist, werde ich mich für SSAA stark machen. :)
Original geschrieben von Exxtreme
Lieber OGSSAA als gar kein SSAA. :)OGSSAA hat ein sehr, sehr schlechtes Kosten-Nutzen-Verhältnis. Ich finde es höchst inkonsistent, dass dir das hier egal zu sein scheint, du aber ständig darauf hinweist, dass meine Vorschläge zu höherer Systemlast führen. Wäre dir Supersamling wirklich so wichtig, warum hast du keine FX 5900?
Original geschrieben von Exxtreme
Wenn die Contenthersteller mitmachen würden, hätte ich nichts dagegen. Leider machen die Contenthersteller nicht mit. Ihnen ist die Spielbarkeit auf älterer Hardware wichtiger eine "Korrektheit" der Implementation. Und solange das so ist, werde ich mich für SSAA stark machen. :) Vergeudete Kraft :)
Exxtreme
2004-03-12, 10:21:46
Original geschrieben von aths
OGSSAA hat ein sehr, sehr schlechtes Kosten-Nutzen-Verhältnis. Ich finde es höchst inkonsistent, dass dir das hier egal zu sein scheint, du aber ständig darauf hinweist, dass meine Vorschläge zu höherer Systemlast führen.
Der Unterschied ist, daß es weniger Aufwand bedeutet SSAA in eine Hardware/Treiber zu gießen als alle Spiele anzupassen, die Alphatesting verwenden. Dein Vorschlag ist eleganter und korrekter, meiner ist praxistauglicher.
Ailuros
2004-03-12, 10:23:27
http://www.beyond3d.com/forum/viewtopic.php?p=129946&highlight=multisampling#129946
<snip>
This may not be much of an advantage in actual practice though, since a TBR would be limited by pixel shader performance, even though it is not restricted by external memory bandwidth. Super-sampling each sample when running a sophisticated pixel shader is simply impractical. The computational resources could be put to much better use and multi-sampled AA is good enough.
http://www.beyond3d.com/forum/viewtopic.php?p=60662&highlight=multisampling#60662
<snip>
Of course it goes without saying the more samples the better. For IMRs coverage mask (A buffer) techniques easily allow 8x, 16x, or even 32x AA without much extra memory bandwidth since it simply requires a larger bit mask. Tilers can also easily increase the samples without incurring extra bandwidth.
http://www.beyond3d.com/forum/viewtopic.php?p=58200&highlight=multisampling#58200
(BITTE DAS DATUM DES POSTS BEACHTEN)
Multi-sampling with anisotropic filtering is a performance optimization that will continue to grow in importance as pixel shaders come into more general use. Chips are just getting to the point where they can perform some very interesting pixel shader effects at acceptable frame rates for one set of calculations per pixel. It is simply impractical at this point to run pixel shaders for each of 8 or 16 samples per pixel for supersampled AA at every pixel, especially for the small improvement.
In the future, it is likely that developers will apply supersampling to selective areas under control of the shader. This is especially true of shaders that actually generate the local image such as procedural textures and selective ray tracing.
micki
2004-03-12, 10:31:13
Original geschrieben von aths
Wieso "ansiehst"? Alphatesting widerspricht den Prinzipien einer funktionierenden Texturfilterung. Das halte ich für ein Faktum, weniger für eine Sichtweise.
wird alphatesting nicht nach der texturfilterung durchgeführt? und welchem prinzip widerspricht alphatesting und wer hat dieses prinzip definiert?
"Das halte ich für ein Faktum" ist wie "ich glaube ich bin mir sicher" und somit ein paradoxum.
MfG
micki
Original geschrieben von Exxtreme
Der Unterschied ist, daß es weniger Aufwand bedeutet SSAA in eine Hardware/Treiber zu gießen als alle Spiele anzupassen, die Alphatesting verwenden. Dein Vorschlag ist eleganter und korrekter, meiner ist praxistauglicher. Deiner ist dann praxistauglich, wenn du alte Spiele auf aktuellen Highend-Geschossen spielst. Erst führst du an, wie bandbreitenlastig Alphablending sei, jetzt machst du einen "praxistauglichen" Vorschlag, der Highend-HW erfordert.
Kauf oder borge dir eine FX 5900 und probiere aus, wie die Karte bei 2x MSAA performt (sehr gut), und wie bei 2x2 Supersampling (sehr mäßig.)
Original geschrieben von micki
wird alphatesting nicht nach der texturfilterung durchgeführt? und welchem prinzip widerspricht alphatesting und wer hat dieses prinzip definiert?Alphatesting beeinflusst Texturen. Alphatesting kann die Nyquist-Grenze verletzen, was dann zu Aliasing führt.
Original geschrieben von micki
"Das halte ich für ein Faktum" ist wie "ich glaube ich bin mir sicher" und somit ein paradoxum.Meine in sich widersprüchliche Formulierung sollte andeuten, dass ich mich nicht in Besitz der endgültigen Weisheit wähne.
Ailuros
2004-03-12, 10:41:25
Original geschrieben von aths
Deiner ist dann praxistauglich, wenn du alte Spiele auf aktuellen Highend-Geschossen spielst. Erst führst du an, wie bandbreitenlastig Alphablending sei, jetzt machst du einen "praxistauglichen" Vorschlag, der Highend-HW erfordert.
Wenn man SSAA mit AF kombinieren moechte, reicht da selbst noch eine NV2x voll aus.
Fuellraten-Forderung bei diesen Spielen ist sowieso klein.
Original geschrieben von Ailuros
Wenn man SSAA mit AF kombinieren moechte, reicht da selbst noch eine NV2x voll aus.
Fuellraten-Forderung bei diesen Spielen ist sowieso klein. Bei welchen Spielen konkret? Q3 in 800x600? :)
Demirug
2004-03-12, 10:51:25
aths, der Alphatest ist eine Rasteroperation und entscheidet ob ein Subpixel relevant ist oder eben nicht. Da wird an den Texturen überhaupt nichts beeinflusst. Eine Alphatestkante ist in dieser Beziehung identisch mit einer Geometrischen Kanten. Das Problem ist nicht der Alphatest an sich. Dieser funktioniert genau wie er soll. Das Problem ist das bei MSAA für alle Subpixel eines Pixels der gleiche Wert zur Prüfung benutzt wird.
Für kleine Löcher in der Geometrie ist und bleibt der Alphatest (oder auch Texkill) das beste Mittel. Baut man für das ganze eine feine Geometrie blockiert man sich die Pipeline. Nur mal so als Denkanstoss. NV3X ist auf durchschnittlich 32 Pixel pro Dreieck ausgelegt.
micki
2004-03-12, 10:56:53
Original geschrieben von aths
Alphatesting beeinflusst Texturen. Alphatesting kann die Nyquist-Grenze verletzen, was dann zu Aliasing führt.
aber alphatest hat garkeinen einfluss auf texturfilterung, erst wenn ein pixel (bzw dessen alpha) fertig zusammengerechnet ist (also 100%ig nach der filterung) wird alphagetestet. mag sein dass da irgendwelche optimierungen vorhanden sind von denen du weißt (und ich nicht), aber wenn es so liefe wie alphatest definiert ist, dürfte es erst am ende abgearbeitet werden.
übersehe ich eine peinliche kleinigkeit ? *SichNicht100%igSicherSei*
Original geschrieben von aths
Meine in sich widersprüchliche Formulierung sollte andeuten, dass ich mich nicht in Besitz der endgültigen Weisheit wähne.
aber mit Worten der Entschiedenheit Dominanz suggerieren ;D
MfG
micki
Original geschrieben von Demirug
aths, der Alphatest ist eine Rasteroperation und entscheidet ob ein Subpixel relevant ist oder eben nicht. Da wird an den Texturen überhaupt nichts beeinflusst.Die Alpha-Information wird bei Alphatexturen ja aus der Textur gelesen. Auf dem Bildschirm ist das "Loch" dann in der Textur.
Original geschrieben von Demirug
Eine Alphatestkante ist in dieser Beziehung identisch mit einer Geometrischen Kanten. Das Problem ist nicht der Alphatest an sich. Dieser funktioniert genau wie er soll. Das Problem ist das bei MSAA für alle Subpixel eines Pixels der gleiche Wert zur Prüfung benutzt wird. Japp, ein Wert pro Pixel.
Original geschrieben von Demirug
Für kleine Löcher in der Geometrie ist und bleibt der Alphatest (oder auch Texkill) das beste Mittel. Damit kriegt man aber immer Löcher, die keine glatten Kanten haben. Man könnte bei einem Alpha-Wert killen, und in einem Übergangsbereich blenden.
Original geschrieben von Demirug
Baut man für das ganze eine feine Geometrie blockiert man sich die Pipeline. Nur mal so als Denkanstoss. NV3X ist auf durchschnittlich 32 Pixel pro Dreieck ausgelegt. 2 Pixel breite Grashalme in Massen geometrisch zu modellieren ist natürlich nicht drin.
Ailuros
2004-03-12, 10:57:45
Original geschrieben von aths
Bei welchen Spielen konkret? Q3 in 800x600? :)
Als ob Q3a wirklich SSAA benoetigen wuerde....alphas waren mehr als nur selten in dem Spiel.
Original geschrieben von micki
aber alphatest hat garkeinen einfluss auf texturfilterung, erst wenn ein pixel (bzw dessen alpha) fertig zusammengerechnet ist (also 100%ig nach der filterung) wird alphagetestet. Japp.
Original geschrieben von micki
übersehe ich eine peinliche kleinigkeit ? *SichNicht100%igSicherSei*Ist schon richtig, auf Alpha wird getestet, bevor das Pixel in den Framebuffer geht. Dann geht das gesamte Pixel entweder rein, oder nicht. Rechnet man das Pixel in den Texture Space zurück, "stimmt" das aber nicht immer. Man filtert ja mindestens 4 Texel für einen Pixelfarbwert zusammen. Beim Kill durch den Alphatest steht das Pixel für sich.
Original geschrieben von micki
aber mit Worten der Entschiedenheit Dominanz suggerieren ;DGenau.
Original geschrieben von Ailuros
Als ob Q3a wirklich SSAA benoetigen wuerde....alphas waren mehr als nur selten in dem Spiel. Na, welche Spiele denn? Namen, Ailuros, Namen :)
micki
2004-03-12, 11:00:31
Original geschrieben von Demirug
aths, der Alphatest ist eine Rasteroperation und entscheidet ob ein Subpixel relevant ist oder eben nicht. Da wird an den Texturen überhaupt nichts beeinflusst. Eine Alphatestkante ist in dieser Beziehung identisch mit einer Geometrischen Kanten. Das Problem ist nicht der Alphatest an sich. Dieser funktioniert genau wie er soll. Das Problem ist das bei MSAA für alle Subpixel eines Pixels der gleiche Wert zur Prüfung benutzt wird.
Für kleine Löcher in der Geometrie ist und bleibt der Alphatest (oder auch Texkill) das beste Mittel. Baut man für das ganze eine feine Geometrie blockiert man sich die Pipeline. Nur mal so als Denkanstoss. NV3X ist auf durchschnittlich 32 Pixel pro Dreieck ausgelegt.
da warst du schneller :)
was noch zu bedenken wäre, wäre dass durch die geometrie eventuell viel mehr flimmern auftauchen würde als durch alphatesting, das beobachtet man heute zwar eher andersrum, aber nur weil die grakas sozusagen ein EdgeAA durchführen, mit FSAA müßte alphatest weniger flimmern erzeugen als das gleiche ausgemodellt.
MfG
micki
Original geschrieben von micki
da warst du schneller :)
was noch zu bedenken wäre, wäre dass durch die geometrie eventuell viel mehr flimmern auftauchen würde als durch alphatesting, das beobachtet man heute zwar eher andersrum, aber nur weil die grakas sozusagen ein EdgeAA durchführen, mit FSAA müßte alphatest weniger flimmern erzeugen als das gleiche ausgemodellt. Das sollte Jacke wie Hose sein. Die Kanten werden mit MSAA ja behandelt.
Demirug
2004-03-12, 11:10:01
Original geschrieben von aths
Die Alpha-Information wird bei Alphatexturen ja aus der Textur gelesen. Auf dem Bildschirm ist das "Loch" dann in der Textur.
Die Alpha-Information muss nicht zwingend aus einer Textur komme. Aber das Loch will man ja.
Japp, ein Wert pro Pixel.
Sagen wir ein Wert pro Pixelshader durchlauf, OK?
Damit kriegt man aber immer Löcher, die keine glatten Kanten haben. Man könnte bei einem Alpha-Wert killen, und in einem Übergangsbereich blenden.
Die Löcher wollen wir ja. Die Kante aber nicht. Ergo muss das Raster am Loch-Rand feiner aufgelösst werden.
Blenden ist aus bekannte Gründen unbrauchbar zudem ist das identisch mit BLUR.
Meine Lösung:
Zuerst einen Alphawert für den Pixel errechnen. Ist dieser
< einen ersten Gernzwert = alle Subpixel werden nicht geschrieben
> einen zweiten Gernzwert = alle Subpixel geschrieben
Zwischen dem ersten und zweiten Grenzwert = Alphawert für jeden Subpixel ermitteln und erneut prüfen.
2 Pixel breite Grashalme in Massen geometrisch zu modellieren ist natürlich nicht drin.
Mit meiner Methode ging das auch mit glatten Kanten.
Ailuros
2004-03-12, 11:10:07
Original geschrieben von aths
Na, welche Spiele denn? Namen, Ailuros, Namen :)
Arggghh die Mehrzahl von allen anderen; Q3a ist gerade eine der wenigen Ausnahmen die eben Fuellraten-limitiert ist. Wie waer's mit praktisch einer weiten Mehrzahl von flight/space/racing sims aus der pre-V5 oder V5 Aera? Ja ich bin jetzt zu faul ne Liste zu machen.
Falls Du die Spiele in >1024 mit SSAA/AF spielen willst, reicht da wohl selbst eine NV35 nicht mehr aus, wenn's um das geht.
micki
2004-03-12, 11:10:17
Original geschrieben von aths
Ist schon richtig, auf Alpha wird getestet, bevor das Pixel in den Framebuffer geht. Dann geht das gesamte Pixel entweder rein, oder nicht. Rechnet man das Pixel in den Texture Space zurück, "stimmt" das aber nicht immer. Man filtert ja mindestens 4 Texel für einen Pixelfarbwert zusammen. Beim Kill durch den Alphatest steht das Pixel für sich.
ich weiß jetzt nicht ganz was du damit sagen möchtest. dass das pixel das man zeichnet den farbwert und alpa aus der _interpolierten_ textur hat, das ist doch absicht, sonst würde man das filterin ja 'ausschalten'. und wenn man das zurücktransformiert, dann ist die position auf der textur immer noch genau die selbe wie beim zeichnen (bis auf rundungsfehler). es wird doch nirgens eine transformation durchgeführt die nicht rückgängig zu machen ist (soweit ich weiß)
MfG
micki
Quasar
2004-03-12, 11:10:24
Nächste Frage an dich, aths, nachdem die letzte ja unbeantwortet blieb.
Szenario: Wald.
Voll ausmodelliert mit Geometrie (Mal angenommen, das würde CPU-mäßig hinhauen), also so, wie du es forderst.
Was meinst du, bleibt noch von der Effizienz von MSAA übrig, wenn das Verhältnis Flächenpixel / Kantenpixel sich von 95:1 immer weiter in Richtung 1:1 verschiebt, sagen wir für den Anfang mal, auf ca. 60:1?
Ailuros
2004-03-12, 11:13:54
Original geschrieben von Quasar
Nächste Frage an dich, aths, nachdem die letzte ja unbeantwortet blieb.
Szenario: Wald.
Voll ausmodelliert mit Geometrie (Mal angenommen, das würde CPU-mäßig hinhauen), also so, wie du es forderst.
Was meinst du, bleibt noch von der Effizienz von MSAA übrig, wenn das Verhältnis Flächenpixel / Kantenpixel sich von 95:1 immer weiter in Richtung 1:1 verschiebt, sagen wir für den Anfang mal, auf ca. 60:1?
Nur so nebenbei eine aehnliche Frage hab ich auch schon gestellt, aber solche Faelle sind viel zu viel in die Zukunft gegriffen (*edit: dass sich im Durchschnitt dass edge polygon/polygon interior Verhaeltnis drastisch aendert). Netter Gedankenstoss trotz allem ;)
Original geschrieben von Demirug
Die Alpha-Information muss nicht zwingend aus einer Textur komme.Ja. Aber es kommt dort rein, wo sich sonst (ohne Kill) Texel befinden würden. "In" die Textur.
Original geschrieben von Demirug
Sagen wir ein Wert pro Pixelshader durchlauf, OK?KK.
Original geschrieben von Demirug
Die Löcher wollen wir ja. Die Kante aber nicht. Ergo muss das Raster am Loch-Rand feiner aufgelösst werden.Wie willst du das tun? 5% oder 10% Extra-Framebuffer für Alphakanten-Subpixel irgendwo allokieren?
Original geschrieben von Demirug
Blenden ist aus bekannte Gründen unbrauchbar zudem ist das identisch mit BLUR.*Denk, denk* Stimmt, für glatte, aber scharfe Kanten ist Blendig keine gute Idee.
Original geschrieben von Demirug
Meine Lösung:
Zuerst einen Alphawert für den Pixel errechnen. Ist dieser
< einen ersten Gernzwert = alle Subpixel werden nicht geschrieben
> einen zweiten Gernzwert = alle Subpixel geschrieben
Zwischen dem ersten und zweiten Grenzwert = Alphawert für jeden Subpixel ermitteln und erneut prüfen.Dazu müsste das gesamte Bild in höherer Auflösung vorliegen, bzw. man müsste ohnehin mit MSAA rendern, und dann partiell SSAA machen. Wie willst du die Grenzwerte in der Pipe feststellen? Dazu müsstest du doch pro Pass, wo ein Alphatest eingeschaltet ist, letzlich jedes Subpixel testen. Klingt für mich fast so "performant" wie Supersampling (weil die ROPs limitieren dürften.)
Original geschrieben von Ailuros
Arggghh die Mehrzahl von allen anderen; Q3a ist gerade eine der wenigen Ausnahmen die eben Fuellraten-limitiert ist. Wie waer's mit praktisch einer weiten Mehrzahl von flight/space/racing sims aus der pre-V5 oder V5 Aera? Ja ich bin jetzt zu faul ne Liste zu machen.Solche Spiele dürften nicht mehr so stark gespielt werden, denke ich. Max Payne z. B. ist auch nicht mehr taufrisch, kaum jemand wird das in 1024x768 mit 4x AF und 8xS-AA spielen. (Obwohl das mit viel gutem Willen möglich wäre, btw.) Lieber die Auflösung hochballern, und 8x AF rein.
Original geschrieben von Ailuros
Falls Du die Spiele in >1024 mit SSAA/AF spielen willst, reicht da wohl selbst eine NV35 nicht mehr aus, wenn's um das geht. Es geht um 1024x768 mit mindestens 4x AF und 4x OGSSAA. Gute Texturen, mäßig glatte Kanten, sehr mäßige Performance.
Exxtreme
2004-03-12, 11:21:12
Original geschrieben von Quasar
Nächste Frage an dich, aths, nachdem die letzte ja unbeantwortet blieb.
Szenario: Wald.
Voll ausmodelliert mit Geometrie (Mal angenommen, das würde CPU-mäßig hinhauen), also so, wie du es forderst.
Was meinst du, bleibt noch von der Effizienz von MSAA übrig, wenn das Verhältnis Flächenpixel / Kantenpixel sich von 95:1 immer weiter in Richtung 1:1 verschiebt, sagen wir für den Anfang mal, auf ca. 60:1?
Hier könnte man sich mit einem Geometrie-LOD behelfen. Aber die Problematik ist tatsächlich da. Je mehr Polygone da sind desto ineffizienter wird MSAA. Die Z-Einheiten bekommen mehr zu tun und mehr Pixel werden geglättet was auf die Füllrate haut.
micki
2004-03-12, 11:26:59
Original geschrieben von Demirug
Meine Lösung:
Zuerst einen Alphawert für den Pixel errechnen. Ist dieser
< einen ersten Gernzwert = alle Subpixel werden nicht geschrieben
> einen zweiten Gernzwert = alle Subpixel geschrieben
Zwischen dem ersten und zweiten Grenzwert = Alphawert für jeden Subpixel ermitteln und erneut prüfen.
Mit meiner Methode ging das auch mit glatten Kanten.
ich glaube das ist die eigentliche idee von MSAA, aber ein paar schlaue leute dachten sich, wenn man innerhalb eines polys eh keine kante haben kann (die leute die unser alphatestproblem uebersahen), dann kann man mit der selben textur alle subpixel berechnen (hat das die geforce3 unnötigerweise so gemacht, oder?). weiter haben sich die gedacht, mit der selben textur kommen die selben ergebnisse raus und haben die subpixelberechnungen auch weggelassen.
deine lösung wäre eigentlich die einzig richtige für MSAA finde ich.
MfG
micki
Original geschrieben von Exxtreme
Hier könnte man sich mit einem Geometrie-LOD behelfen. Aber die Problematik ist tatsächlich da. Je mehr Polygone da sind desto ineffizienter wird MSAA.Solange es vollständig bedeckte Pixel gibt (und noch etwas darüber hinaus) ist es aber effizienter als SSAA :)
Original geschrieben von Exxtreme
Die Z-Einheiten bekommen mehr zu tun und mehr Pixel werden geglättet was auf die Füllrate haut. Wieso bekommen die Z-Einheiten mehr zu tun?
Exxtreme
2004-03-12, 11:29:06
Original geschrieben von aths
Wieso bekommen die Z-Einheiten mehr zu tun?
Je mehr Polygone, desto mehr Kanten müssen erkannt werden. Aber ob's tatsächlich Auswirkungen auf die Leistung hat, weiss ich nicht.
Original geschrieben von micki
ich glaube das ist die eigentliche idee von MSAA, aber ein paar schlaue leute dachten sich, wenn man innerhalb eines polys eh keine kante haben kann (die leute die unser alphatestproblem uebersahen), dann kann man mit der selben textur alle subpixel berechnen (hat das die geforce3 unnötigerweise so gemacht, oder?). weiter haben sich die gedacht, mit der selben textur kommen die selben ergebnisse raus und haben die subpixelberechnungen auch weggelassen.
deine lösung wäre eigentlich die einzig richtige für MSAA finde ich.Das ist doch gerade der Unterschied zwischen MSAA und SSAA: Ein Texel pro Pixel bei MSAA, ein Pixel pro Texel bei SSAA. Z wird aber Subpixelweise getestet. Alpha subpixelweise zu testen macht nicht viel Sinn, da Alpha meist aus der Textur kommt. Und pro Pixel wird nur ein Texturwert (und damit ein Alpha-Wert) gefiltert.
Original geschrieben von Exxtreme
Je mehr Polygone, desto mehr Kanten müssen erkannt werden. Rrr. Kanten "erkannt"... den 3dcenter-MSAA-Artikel hast du gelesen?
Demirug
2004-03-12, 11:31:11
Original geschrieben von aths
Ja. Aber es kommt dort rein, wo sich sonst (ohne Kill) Texel befinden würden. "In" die Textur.
Ohne Kill würde sich dort ein Pixelwert befinden. Du denkst hier noch viel zu sehr in die Richtung das ein Pixelprozessor nur Texturen auf die Geometrische Fläche "klept".
Wie willst du das tun? 5% oder 10% Extra-Framebuffer für Alphakanten-Subpixel irgendwo allokieren?
Sobald AA aktiviert ist hat man doch sowieso schon einen grösseren Framebuffer. bei 4xAA pro Pixel 4 Subpixel.
Dazu müsste das gesamte Bild in höherer Auflösung vorliegen, bzw. man müsste ohnehin mit MSAA rendern, und dann partiell SSAA machen. Wie willst du die Grenzwerte in der Pipe feststellen? Dazu müsstest du doch pro Pass, wo ein Alphatest eingeschaltet ist, letzlich jedes Subpixel testen. Klingt für mich fast so "performant" wie Supersampling (weil die ROPs limitieren dürften.)
Mit aktiviertem AA arbeitet der Chip doch mit einer höheren Auflösung bestimmt durch das AA-Muster und die "echte" Auflösung.
Subpixelshader sind die Lösung. Gleichzeitig braucht man im Pixelshader ein Ausgangsregister das bestimmt ob der Subpixelshader für ein Pixel benutzt wird oder nicht.
Im Pixelshader also den Grenzbereich prüfen und wenn man dazwischen liegt den Subpixelshader aktivieren. Ist die Sache schon auf der Pixelebene klar (alle Subpixel ausgeben oder killen) kann man den Subpixelshader umgehen. Im schlimmsten Fall ist es nicht schneller als SS. Dann muss aber nahezu jeder Pixel auf einer Kante liegen. Die vergleichbare Geometrie würde IMHO den Rasterisiere so stark blockieren das man sowieso nicht schneller als mit SS werden dürfte. Zudem dürfte bei einer solchen Geometrie die Quads ständig Leerpixel enthalten.
Ailuros
2004-03-12, 11:31:45
Original geschrieben von aths
Solche Spiele dürften nicht mehr so stark gespielt werden, denke ich. Max Payne z. B. ist auch nicht mehr taufrisch, kaum jemand wird das in 1024x768 mit 4x AF und 8xS-AA spielen. (Obwohl das mit viel gutem Willen möglich wäre, btw.) Lieber die Auflösung hochballern, und 8x AF rein.
Es geht um 1024x768 mit mindestens 4x AF und 4x OGSSAA. Gute Texturen, mäßig glatte Kanten, sehr mäßige Performance.
Wenn man keine aelteren Spiele spielt dann wird die Notwendigkeit fuer SSAA aber auch um einiges kleiner.
Mach mich jetzt nicht verrueckt mit dem Genauigkeitsfusel, nur aeltere Spiele sind radikal mit alphas ueberladen. Wenn nicht sehe ich keinen besonderen Grund fuer SSAA.
Die Aufloesung hochballern hilft Dir nicht besonders bei alphas und erst gar nicht wenn das Spiel keine besonders hohen Aufloesungen unterstuetzt.
Mal anders rum: wieviel neue racing sims als Beispiel benoetigen heutzutage eigentlich unbedingt SSAA?
Exxtreme
2004-03-12, 11:34:19
Original geschrieben von aths
Rrr. Kanten "erkannt"... den 3dcenter-MSAA-Artikel hast du gelesen?
Ja, habe ich. Und ARGHH ... ja, ich habe Mist geschrieben. Wieder zu arg an TBDR gedacht. Bitte meine letzte Aussage über Kantenerkennung aus'm Protokoll streichen. :D
micki
2004-03-12, 11:36:17
Original geschrieben von aths
Das ist doch gerade der Unterschied zwischen MSAA und SSAA: Ein Texel pro Pixel bei MSAA, ein Pixel pro Texel bei SSAA. Z wird aber Subpixelweise getestet. Alpha subpixelweise zu testen macht nicht viel Sinn, da Alpha meist aus der Textur kommt. Und pro Pixel wird nur ein Texturwert (und damit ein Alpha-Wert) gefiltert.
dann find ich MSAA so bedüftig wie das 16xAA von matrox.
MfG
micki
Demirug
2004-03-12, 11:40:46
Original geschrieben von micki
dann find ich MSAA so bedüftig wie das 16xAA von matrox.
MfG
micki
FAA von Matrox ist noch schlimmer. Dort gehen neben den Alphakanten auch keine Z und Stencil Kanten. FAA erkennt nur Geometrie Kante und selbst die nicht immer.
Ja, aths "erkennt" habe ich mit absicht geschrieben den beim FAA muss es offentsichtlich ein Verfahren im Chip geben das entscheidet ob es nun eine relevante Kante oder ebene nicht ist.
Original geschrieben von Demirug
Im Pixelshader also den Grenzbereich prüfenWie willst du das anstellen, ohne für jedes Subpixel vorher Alpha zu testen, und auch für jedes Subpixel die Alpha-Textur neu zu filtern?
Original geschrieben von Exxtreme
Ja, habe ich. Und ARGHH ... ja, ich habe Mist geschrieben. Wieder zu arg an TBDR gedacht. Bitte meine letzte Aussage über Kantenerkennung aus'm Protokoll streichen. :D Ich wüsste jetzt nicht, was beim TDBR-MSAA da grundlegend anders sein soll.
Original geschrieben von micki
dann find ich MSAA so bedüftig wie das 16xAA von matrox.
MfG
micki MSAA ist MSAA. FAA hat ganz andere Schwächen. MSAA funktioniert genau, wie es soll: Auf Polygonkanten. Ich würde gerne erklärt bekommen, wie MSAA den Alphatest subpixelweise ausführen soll, ohne pro Subpixel die Alphatextur zu filtern. Filtert man Texturen pro Subpixel, hat man Supersampling.
Demirug
2004-03-12, 11:53:33
Original geschrieben von aths
Wie willst du das anstellen, ohne für jedes Subpixel vorher Alpha zu testen, und auch für jedes Subpixel die Alpha-Textur neu zu filtern?
Wenn man den Alphawert für den Pixel filtern lässt so deckt dieser ja alle Subpixel ab. Ist dieser Wert 0 so kann man mit einem sehr hohen Mass an Wahrscheinlichkeit davon ausgehen das auch der Alpha-Wert für alle Subpixel 0 sein wird da die Sampleposition nur minimal verschoben ist. Das gleiche gilt für den maximal Wert. Wenn der Alphawert 1 ist dann kann man auch davon ausgehen das er für alle Suppixel ebenfalls 1 ist. Durch Grenzewerte grösser 0 und kleiner 1 kann man die Empfindlichkeit verändern bei der die Subpixelshader ran müssen.
Natürlich ist das nicht zu 100% perfekt aber IMHO der beste Kompromiss zwischen alle Möglichkeiten.
Exxtreme
2004-03-12, 11:55:39
Original geschrieben von aths
Ich wüsste jetzt nicht, was beim TDBR-MSAA da grundlegend anders sein soll.
Nein. Mir ging gerade der Raycasting-Quatsch durch den Kopf.
micki
2004-03-12, 11:57:46
Original geschrieben von Demirug
FAA von Matrox ist noch schlimmer. Dort gehen neben den Alphakanten auch keine Z und Stencil Kanten. FAA erkennt nur Geometrie Kante und selbst die nicht immer.
ja, jede kante(definiert durch die indices) an der mindestens zwei triangles sich diese teilen und keines von denen backfacing ist, ist keine kante die AA bedarf(soweit ich beobachten konnte), somit sollte man von einer untexturierten box (damit keine splits durch UV auftauchen) eine kante sehen wenn man sie um 45° rotiert.
das ist sehr fehlerhaft.
aber ein antialiasing dass aliasing nur an polygonkanten berechnet ist 'bedürftig'.
man bekommt ja manchmal schon aliasing wenn man beim envmapping die radien beim multiplizieren mit dem envmap vector ein wenig höcher stellt. das würde MSAA auch aliased lassen.
ein gutes AA müßte (meiner meinung nach) nunmal alle subpixel berechnen, wenn auch nur einer mit colorcompression geschrieben würde.
MfG
micki
micki
2004-03-12, 12:01:18
*ping* @ aths
Original geschrieben von micki
ich weiß jetzt nicht ganz was du damit sagen möchtest. dass das pixel das man zeichnet den farbwert und alpa aus der _interpolierten_ textur hat, das ist doch absicht, sonst würde man das filterin ja 'ausschalten'. und wenn man das zurücktransformiert, dann ist die position auf der textur immer noch genau die selbe wie beim zeichnen (bis auf rundungsfehler). es wird doch nirgens eine transformation durchgeführt die nicht rückgängig zu machen ist (soweit ich weiß)
MfG
micki
Original geschrieben von Demirug
Wenn man den Alphawert für den Pixel filtern lässt so deckt dieser ja alle Subpixel ab. Ist dieser Wert 0 so kann man mit einem sehr hohen Mass an Wahrscheinlichkeit davon ausgehen das auch der Alpha-Wert für alle Subpixel 0 sein wird da die Sampleposition nur minimal verschoben ist. Das gleiche gilt für den maximal Wert. Wenn der Alphawert 1 ist dann kann man auch davon ausgehen das er für alle Suppixel ebenfalls 1 ist. Durch Grenzewerte grösser 0 und kleiner 1 kann man die Empfindlichkeit verändern bei der die Subpixelshader ran müssen.
Natürlich ist das nicht zu 100% perfekt aber IMHO der beste Kompromiss zwischen alle Möglichkeiten. Dieses partielle Supersampling erfordert wohl noch einige Loopback-Mechanismen.
Original geschrieben von micki
aber ein antialiasing dass aliasing nur an polygonkanten berechnet ist 'bedürftig'.Aber richtig, da bei Texturen im Filter Aliasing vermieden wird. Bei Shadern muss der Shader sich selbst darum kümmern. Bei prozeduralen Shadern sind die Frequenzen im Bild am Ende nicht immer abzusehen, das wird natürlich schwierig.
Original geschrieben von micki
ein gutes AA müßte (meiner meinung nach) nunmal alle subpixel berechnen, wenn auch nur einer mit colorcompression geschrieben würde.Supersampling verbessert in den meisten Szenen die allermeisten Pixel fast gar nicht. Es werden also massenhaft (praktisch) unsichtbare Berechnungen durchgeführt.
Original geschrieben von micki
*ping* @ aths Mal es dir auf :) Trilineare Filterung deckt (meistens sogar mehr als) das Pixel im Texture Space ab. Killst du ein ganzes Pixel, ist Rand willkürlich durch das Pixelraster festgelegt. Richtig hässlich wird es, wenn AF zum Einsatz kommt, und die Alphawerte aus einer höher aufgelösten MIP gefiltert werden. Die Filterung ansich ist richtig, der Pixelkill aber nicht – Onkel Nyquist würde da in Tränen ausbrechen.
micki
2004-03-12, 12:23:51
Original geschrieben von aths
Aber richtig, da bei Texturen im Filter Aliasing vermieden wird. Bei Shadern muss der Shader sich selbst darum kümmern. Bei prozeduralen Shadern sind die Frequenzen im Bild am Ende nicht immer abzusehen, das wird natürlich schwierig.
wie schon gesagt, wenn man aus einer envmap ließt und der radius zu ungünstig ist, dann kann man trots filtering noch aliasing erkennen. texturfiltering kann nie eine ausreichend hoche qualität erreichen dass kein aliasing auftritt, denn texturen sind nur die 'source' und können gänzlich egal für das resultat sein welches man im pixelshader ausrechnet.
btw. das envmapping problem hab ich auch wenn ich das mit einer radeon 1 (ohne pixelshader) laufen habe (ohne AA).
MfG
micki
micki
2004-03-12, 12:29:21
Original geschrieben von aths
Mal es dir auf :) Trilineare Filterung deckt (meistens sogar mehr als) das Pixel im Texture Space ab. Killst du ein ganzes Pixel, ist Rand willkürlich durch das Pixelraster festgelegt. Richtig hässlich wird es, wenn AF zum Einsatz kommt, und die Alphawerte aus einer höher aufgelösten MIP gefiltert werden. Die Filterung ansich ist richtig, der Pixelkill aber nicht – Onkel Nyquist würde da in Tränen ausbrechen.
"(meistens sogar mehr als)" in dem fall wäre es nicht richtig, wenn jedoch exact der bereich aus der textur für den alphatest genutzt wird, den der pixel abdeckt, dann ist es richtig *zustimm*
aber...
das aliasing tritt erst danach auf, nicht beim filtering. damit es nicht auftritt müßte man in den subpixeln den bereich filtern den ein subpixel abdeckt, dann den alphatest durchführen und die übriggebliebenen pixel aufaddieren und durch die pixelanzahl teilen damit man das richtige (gewünschte) ergebniss erhältt. diesen antialiasten pixel könnte man nicht zurücktransformieren wenn nicht alle pixel gesetzt wurden (das kann man auber auch nicht an den kanten, selbst mit MSAA, aber jeden einzelnen sichtbaren subpixel könnte man zurückprojezieren.
MfG
micki
Original geschrieben von micki
wie schon gesagt, wenn man aus einer envmap ließt und der radius zu ungünstig ist, dann kann man trots filtering noch aliasing erkennen. texturfiltering kann nie eine ausreichend hoche qualität erreichen dass kein aliasing auftritt, denn texturen sind nur die 'source' und können gänzlich egal für das resultat sein welches man im pixelshader ausrechnet. Um von Envmaps das richtige LOD zu bestimmen, gibt es doch das du/dv-Verhältnis im Quad :kratz:
Original geschrieben von micki
das aliasing tritt erst danach auf, nicht beim filtering. damit es nicht auftritt müßte man in den subpixeln den bereich filtern den ein subpixel abdeckt, Das macht Supersampling mit (fast) der gleichen Genauigkeit wie für ein normales Pixel. Sofern also das Enviromentmapping nicht richtig funzt, ist Supersampling keine echte Abhilfe. Oder anders, wie bei Kanten wird das Aliasing verringert, ohne es gänzlich beseitigen zu können.
Original geschrieben von Exxtreme
Nein. Mir ging gerade der Raycasting-Quatsch durch den Kopf. Auch hier wüsste ich jetzt nicht, was das mit Z-Last zu tun hätte …
marco42
2004-03-12, 14:14:19
Original geschrieben von micki
wird alphatesting nicht nach der texturfilterung durchgeführt? und welchem prinzip widerspricht alphatesting und wer hat dieses prinzip definiert?
Ja, das hat aber nichts mit dem Texture Filtering zu tun. Du kannst beim Alpha Testing definieren, wie der Vergleichsoperator(also <, ==, > >=, <= , immer, garnicht und so weiter) aussieht und wie der Wert ist, mit dem Verglichen wird, also 0.0, 0.5, 1.0 etc.. Du hast damit automatisch eine ja oder nein ausage, also eine scharfe kannte. Du blendest nicht zum Hintergrund. Das kann durchaus sinnvoll sein, Alpha Blending mit Alpha Testing zu kombinieren. zB alle Fragmente mit Alphawert 0.0 wegzuschmeissen und nicht zu blenden.
Ich hoffe, dass war jetzt verstaendlich.
marco42
2004-03-12, 14:22:46
Original geschrieben von Demirug
Blenden ist aus bekannte Gründen unbrauchbar zudem ist das identisch mit BLUR.
Wieos ist das ein Blur? Alpha Blending ist eine ganz normale mix function. Du sagst doch nur, das Fragment geht mit diesem Anteil in den Pixel ein. Kannst du mir das erklaeren?
Demirug
2004-03-12, 15:14:39
Original geschrieben von marco42
Wieos ist das ein Blur? Alpha Blending ist eine ganz normale mix function. Du sagst doch nur, das Fragment geht mit diesem Anteil in den Pixel ein. Kannst du mir das erklaeren?
Blur ist nicht unbedingt die ideale Umschreibung für das was passiert. Zum einen haben wir ja den Texturfilter (wenn Alpha aus einer Textur errechnet wird) der schon als Weichzeichner wirkt. Das zweite Problem entsteht wenn der Pixel der bereits ein Kanten Pixel ist. In diesem Fall werden alle Samples unabhängig von iherer Lage gleichmässig verändert. Dadurch können Farbanteile von Dreiecken übrig bleiben die dort nichts verloren haben. Blendet man dann noch mehrer solche Alpha-schichten übereinader stimmt am Ende gar nichts mehr. Die Alphatestkanten wird Rastertechnisch einfach nicht richtig erfasst und die modernen AA-Verfahren bauen eben drauf auf das Kanten auf Rasterebene erfasst werden.
marco42
2004-03-12, 15:37:36
Original geschrieben von Demirug
Blur ist nicht unbedingt die ideale Umschreibung für das was passiert. Zum einen haben wir ja den Texturfilter (wenn Alpha aus einer Textur errechnet wird) der schon als Weichzeichner wirkt. Das zweite Problem entsteht wenn der Pixel der bereits ein Kanten Pixel ist. In diesem Fall werden alle Samples unabhängig von iherer Lage gleichmässig verändert. Dadurch können Farbanteile von Dreiecken übrig bleiben die dort nichts verloren haben. Blendet man dann noch mehrer solche Alpha-schichten übereinader stimmt am Ende gar nichts mehr. Die Alphatestkanten wird Rastertechnisch einfach nicht richtig erfasst und die modernen AA-Verfahren bauen eben drauf auf das Kanten auf Rasterebene erfasst werden.
Wir brauchten also einen Deckungsfaktor fuer jedes Fragment. Hmm, das kann man ja ueber Multisampling loesen. Also, bei Baeumen sieht das aber wirklich besser aus, als fast alles.
Schade dass es nicht sowas gibt wie Pixel Listen gibt. Aber das wuerde leider die Lokalitaet des Framebuffers ueber den Haufen schmeissen.
Der Texture Filter bei Linearem Filtering ist ja ein Boxfilter, der zeichnet halt immer etwas weich, Gauss in Hardware waere halt etwas teuer. :-)
Demirug
2004-03-12, 15:48:25
Original geschrieben von marco42
Wir brauchten also einen Deckungsfaktor fuer jedes Fragment. Hmm, das kann man ja ueber Multisampling loesen. Also, bei Baeumen sieht das aber wirklich besser aus, als fast alles.
Es sind Kanten also entweder 100% oder eben nichts. Keine Lust zum sortieren. Multisampling könnte das lösen wenn man pro Subpixel einen Alphawert zum vergleichen hätte. Nur hat man den leider nicht.
Schade dass es nicht sowas gibt wie Pixel Listen gibt. Aber das wuerde leider die Lokalitaet des Framebuffers ueber den Haufen schmeissen.
Eine Pointliste mit transformierten Punkte ist eine Pixelliste. Oder meinen wir jetzt unterschiedliche Dinge?
Der Texture Filter bei Linearem Filtering ist ja ein Boxfilter, der zeichnet halt immer etwas weich, Gauss in Hardware waere halt etwas teuer. :-)
Du meinst sicherlich einen Tent-Filter. Box wäre ja Pointsampling.
marco42
2004-03-12, 16:18:50
Original geschrieben von Demirug
Es sind Kanten also entweder 100% oder eben nichts. Keine Lust zum sortieren. Multisampling könnte das lösen wenn man pro Subpixel einen Alphawert zum vergleichen hätte. Nur hat man den leider nicht.
Du sortierst ja auch nicht, du verzoegerst bloss einige Fragment Operationen. Du hast also mehr Informationen im Pixelbuffer. Du machst also praktisch das Alpha Blending erst beim Swap. Das ganze waere wohl zu aufwendig, aber eine sehr saubere Loesung. Du sortierst halt praktisch im Framebuffer anhand der Tiefenwerte. Es waere also kein Object basiertes sortieren, sondern ein Pixelbasiertes. Ich hoffe, du verstehtst jetzt was ich meine.
Original geschrieben von Demirug
Eine Pointliste mit transformierten Punkte ist eine Pixelliste. Oder meinen wir jetzt unterschiedliche Dinge?
Ich meinte eine Pixel Liste. Also es wird nicht ein Pixel in den Framebuffer geschrieben, sondern eine Liste von Pixeln. Die werden dann vor einem Swap zusammengeblendet mit Hilfe eines Blendfaktors.
Original geschrieben von Demirug
Du meinst sicherlich einen Tent-Filter. Box wäre ja Pointsampling.
Naja, also visuell gesehen meine ich einen Filter, der zwischen zwei Werten linear interpoliert und davor einen konstanten Wert hat und danach einen konstanten Wert.
Man braeuchte hier ein drawing board. :-)
Demirug
2004-03-12, 16:43:07
Original geschrieben von marco42
Du sortierst ja auch nicht, du verzoegerst bloss einige Fragment Operationen. Du hast also mehr Informationen im Pixelbuffer. Du machst also praktisch das Alpha Blending erst beim Swap. Das ganze waere wohl zu aufwendig, aber eine sehr saubere Loesung. Du sortierst halt praktisch im Framebuffer anhand der Tiefenwerte. Es waere also kein Object basiertes sortieren, sondern ein Pixelbasiertes. Ich hoffe, du verstehtst jetzt was ich meine.
Ich meinte eine Pixel Liste. Also es wird nicht ein Pixel in den Framebuffer geschrieben, sondern eine Liste von Pixeln. Die werden dann vor einem Swap zusammengeblendet mit Hilfe eines Blendfaktors.
Jetzt ist mir glaube ich klar auf was du hinaus möchtest. Pixar hat mal sowas entwickelt und A-Buffer genannt. Wurde aber AFAIK niemals in einem Chip unterstützt.
Naja, also visuell gesehen meine ich einen Filter, der zwischen zwei Werten linear interpoliert und davor einen konstanten Wert hat und danach einen konstanten Wert.
Man braeuchte hier ein drawing board. :-)
Ja das ist ein Tent Filter.
http://www.wheatchex.com/projects/filters/
http://www.hinjang.com/gfx/gfx01.html
marco42
2004-03-12, 17:07:32
Original geschrieben von Demirug
Jetzt ist mir glaube ich klar auf was du hinaus möchtest. Pixar hat mal sowas entwickelt und A-Buffer genannt. Wurde aber AFAIK niemals in einem Chip unterstützt.
Genau, dass war glaube ich der Name. Bei den ganzen IrgendEinBuchstabe-Buffer verliere ich immer den Ueberblick. :-)
Na, vielleicht kommt es doch noch. Vor ein paar Jahren gab es ja auch nur Vertex Shading und mittlerweile benutzen viele Fragment Shading.
Original geschrieben von Demirug
Ja das ist ein Tent Filter.
Stimmt, hab das verwechselt. Box-Filter waere ja GL_NEAREST.
PS das GLSlang (http://www.3dlabs.com/seminar/oglshadereu/index.htm) waere vielleicht interessant fuer die News
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.