Archiv verlassen und diese Seite im Standarddesign anzeigen : "Perfektes Anti-Aliasing"
Wie mir inzwischen klar geworden ist, ist ein Boxfilter nicht gerade der optimale Rekonstruktionsfilter für Anti-Aliasing.
Reines CFAA ohne Edge-Detect bietet jetzt ja die Möglichkeit einen Gaussian- oder Tent-Kernel zu verwenden, allerdings wird dadurch das ganze Bild verwaschen.
Ich bin mir inzwischen recht sicher, warum das so ist. Bei Multisampling wird für jeden Pixel nur eine Farbe für alle Pixel verwendet wenn man innerhalb eines Dreiecks bleibt, das ist okay für den Boxfilter weil man ja eh nur innerhalb eines Pixels gewichtet und die Samples alle gleich stark.
Bei Gaussian passt die Sache aber nicht mehr. Eigentlich sollten dort schon die Samples in einem Pixel unterschiedliche Gewichtung haben, außerdem werden auch Samples "außerhalb" des Pixels gewichtet.
Ich bin der Meinung dass das alles deshalb nur mit Supersampling wirklich Sinn machen würde und da auch hervorrangend aussehen sollte - allerdings braucht man wahrscheinlich auch mehr Samples.
Edge-Detect geht in die Richtung, weil die Geometrie ja praktisch immer Supersampling abbekommt, allerdings ist dort wieder das Problem das umliegende Pixel wieder nur Multisampling abbekommen haben und dadurch eigentlich falsche Daten enthalten.
Es wäre also vielleicht interessant einen Rasterizer zu bauen, der mit Multisampling erst anfängt, wenn man 1 oder 2 Pixel weit von der Polygonkante entfernt ist und das mit Edge-Detect verbindet. Problem wären dann aber wahrscheinlich die unterschiedlichen LOD-Level der Texturdaten.
Was meint ihr?
StefanV
2007-07-11, 22:08:44
Naja, die Frage ist doch, wie teuer ein Chip wäre, der von Grund auf für effizientes Supersampling gebaut wurde bzw der das gleich 'in Hardware' berechnet, ohne das die Füllrate drastisch einbricht...
Ansonsten ists auch nicht soo einfahc, die bestehenden Implementationen noch wirklich zu verbessern, außer eben mit solchen 'Spielereien' wie es AMD gerad versucht.
robbitop
2007-07-11, 22:10:10
Bei Edge Detection bekommen doch nur Geometrie Kanten den Tent Kernel. Alles andere wird doch weiterhin Box-Filter behandelt. Somit duerfte die Kantenglaettung doch gut sein, was sie laut meinen Level 1 optischen Sensoren (Augen) auch ist.
Naja, die Frage ist doch, wie teuer ein Chip wäre, der von Grund auf für effizientes Supersampling gebaut wurde bzw der das gleich 'in Hardware' berechnet, ohne das die Füllrate drastisch einbricht...
Supersampling braucht nunmal die n-fache Fuellrate (und nicht nur das sondern die n-fache Rohleistung von allem, da die Pixel ja entweder mehrfach durch die Pipeline muessen oder halt intern mit einer hoeheren Aufloesung gerechnet wird)
Daran kann ein Chipdesign wenig aendern.
Bei Edge Detection bekommen doch nur Geometrie Kanten den Tent Kernel. Alles andere wird doch weiterhin Box-Filter behandelt. Somit duerfte die Kantenglaettung doch gut sein, was sie laut meinen Level 1 optischen Sensoren (Augen) auch ist.
Gaussian. Ja, aber die umliegenden Pixel sind bereits wieder Multisampling, also "falsch" werden aber trotzdem auch gesampled. Das ist doch der Knackpunkt.
Deshalb ja auch mein Vorschlag, die Randpixel der Polygone mit Supersampling durchlaufen zu lassen. Das wäre gar nicht so unmöglich zu implementieren.
Aquaschaf
2007-07-11, 22:18:09
Naja, die Frage ist doch, wie teuer ein Chip wäre, der von Grund auf für effizientes Supersampling gebaut wurde bzw der das gleich 'in Hardware' berechnet, ohne das die Füllrate drastisch einbricht....
"Für effizientes Supersampling gebaut" gibt es nicht.
StefanV
2007-07-11, 22:19:14
Daran kann ein Chipdesign wenig aendern.
Man könnt die TMUs so auslegen, das sie gleich 'intern' Supersampling machen, wäre eigentlich kein Problem, die Frage ist nur wieviell das kostet (Transistormäßig) und obs überhaupt wirklich SInn macht...
robbitop
2007-07-11, 22:21:42
Gaussian. Ja, aber die umliegenden Pixel sind bereits wieder Multisampling, also "falsch" werden aber trotzdem auch gesampled. Das ist doch der Knackpunkt.
Deshalb ja auch mein Vorschlag, die Randpixel der Polygone mit Supersampling durchlaufen zu lassen. Das wäre gar nicht so unmöglich zu implementieren.
Allerdings sieht edge CFAA schon wirklich nett aus IMO?
Durftest du es mittlerweile schon irgendwo mal testen? :)
robbitop
2007-07-11, 22:22:45
Man könnt die TMUs so auslegen, das sie gleich 'intern' Supersampling machen, wäre eigentlich kein Problem, die Frage ist nur wieviell das kostet (Transistormäßig) und obs überhaupt wirklich SInn macht...
Nicht nur die TMUs sind beim Supersampling inkludiert sondern alles.
Alles muss in n-facher Menge berechnet werden. Das kann man nicht anders auslegen. Man muss die Grundleistung halt erhoehen.
Hier geht es mir gerade eigentlich eher mehr um Theorie als um Praxis.
Ich glaube schon, dass CFAA "nicht schlecht" aussieht, allerdings ist es theoretisch an manchen Stellen immer noch falsch auch wenn der Ansatz wirklich der richtige ist - auch wenn ich immer noch glaube, dass das ganze eher aus Not gebohren wurde als das es ursprünglich geplant war.
Nicht nur die TMUs sind beim Supersampling inkludiert sondern alles.
Alles vor und inkl. dem Rasterizer nicht wenn man es richtig macht und nicht per Multipass. Eigentlich ist Multisampling ja gar nicht so weit von Supersampling entfernt: Man müsste nur die Pixelfarbe pro Subpixel berechnen und das LOD entsprechend automatisch anpassen (das könnte allerdings ein Problem sein, vor allem bei dynamischem branching etc.)
Es wäre also vielleicht interessant einen Rasterizer zu bauen, der mit Multisampling erst anfängt, wenn man 1 oder 2 Pixel weit von der Polygonkante entfernt ist und das mit Edge-Detect verbindet.Der Satz ergibt irgendwie nur Sinn, wenn du Supersampling statt Multisampling meinst bzw. dort, wo keine Kanten vorhanden sind, ist MSAA so überflüssig wie ein Kropf - außer natürlich als erster Durchgang, um zu erkennen, wo SSAA genutzt werden soll. Aber:
Edge Detect hat das Problem, Kanten zu "markieren", entweder bei MSAA durch Unschärfe oder bei selektivem SSAA durch höhere Schärfe dort (das meintest du doch mit den unterschiedlichen LODs, oder?). Daher ist es IMO besser, den Filter und Supersampling auf die ganze Szenerie anzuwenden und nicht nur selektiv (mit Ausnahme des HUDs). Wie wirds beim Offlinerendering denn gemacht? Wird dort bei hohen Kontrasten Filter und Samplemenge nur stellenweise angepasst oder fürs ganze Bild?
Ein kleiner Praxistest noch für jene, die den Boxfilter als richtig erachten:
Die Antennenphalanx der Raumstation im Hauptmenü von Freelancer. Selbst mit 32xS "wabern" die Kanten dort noch enorm. Dürfte mit CFAA in der breitzeltigen oder Kanten erkennenden Variante wahrscheinlich besser aussehen trotz erheblich weniger und auch noch schlechterer (SSAA vs MSAA) Samples, da das Aliasing dort nur von der Geometrie kommt.
BAGZZlash
2007-07-12, 08:44:03
Es wäre also vielleicht interessant einen Rasterizer zu bauen, der mit Multisampling erst anfängt, wenn man 1 oder 2 Pixel weit von der Polygonkante entfernt ist und das mit Edge-Detect verbindet.
Der Satz ergibt irgendwie nur Sinn, wenn du Supersampling statt Multisampling meinst.
Das hab' ich auch gedacht.
Ein kleiner Praxistest noch für jene, die den Boxfilter als richtig erachten:
Die Antennenphalanx der Raumstation im Hauptmenü von Freelancer.
Ja, das ist in der Tat ein gutes Beispiel dafür, wo mit CFAA deutlich bessere Qualität erreichbar wäre/ist.
Was ich nicht verstehe ist, warum laut Threadsteller selbst bei gaussian supersampling (also mit geringerer Gewichtung der Samples außerhalb des Pixels) nicht trotzdem Texturdaten unscharf werden. Kannst Du nochmal erklären, auf welche Weise das verhindert werden soll?
- auch wenn ich immer noch glaube, dass das ganze eher aus Not gebohren wurde als das es ursprünglich geplant war.
Warum sollte es? Die Leute bei ATI sind auch nicht blöd und wissen natürlich von diesem Problem. Anstatt die Sampleanzahl ständig zu erhöhen, was kaum noch verbesserungen bringt, ist es viel schlauer alternative Wege einzuschlagen.
robbitop
2007-07-12, 11:45:26
Nunja waere der R600 fuer CFAA designed worden, waere vieles als FF inplementiert und damit deutlich fixer.
Und die ganzen Blurring Modi würde ich auch nicht als schlauen alternativen Weg bezeichnen.
robbitop
2007-07-12, 11:55:00
Und die ganzen Blurring Modi würde ich auch nicht als schlauen alternativen Weg bezeichnen.
Sofern die Tentfilter nur an Polyedges appliziert werden schon. (wie bei edge detection)
BAGZZlash
2007-07-12, 12:13:05
Nunja waere der R600 fuer CFAA designed worden, waere vieles als FF inplementiert und damit deutlich fixer.
Ist es mittlerweile eigentlich Fakt, daß R600 AA (teilweise) auf Shadern ausführt? Mein letzter Stand ist, daß es dieses Gerücht gab.
Ist es mittlerweile eigentlich Fakt, daß R600 AA (teilweise) auf Shadern ausführt? Mein letzter Stand ist, daß es dieses Gerücht gab.
:eek: Wie soll das funktionieren?
Erklärung? :confused:
Und die ganzen Blurring Modi würde ich auch nicht als schlauen alternativen Weg bezeichnen.Yo, dass es im Offlinerendering auch so gemacht wird liegt nur daran, dass ILM, Pixar & Co einfach nicht soviel Ahnung haben wie du, oh Erleuchteter :uhammer:
Ist halt nur, wie von Coda bereits ausgeführt, mit MSAA weit weniger sinnvoll als mit SSAA.
Ist es mittlerweile eigentlich Fakt, daß R600 AA (teilweise) auf Shadern ausführt? Mein letzter Stand ist, daß es dieses Gerücht gab.Ist höchstoffiziell bestätigt. Nur was genau alles in SW und was als FF genutzt wird ist nicht ganz sicher.
Nunja waere der R600 fuer CFAA designed worden, waere vieles als FF inplementiert und damit deutlich fixer.
Eispruch:
das wuerde noch mehr Transistoren mit sich ziehen als das Teil schon hat. Einerseits kann man sich natuerlich auch fragen ob da viele schlummernde Transistoren in teil-defekten ROPS schlummern, oder ob Ati den Weg einschlug weil
a) die Faehigkeit zum MSAA shader resolve in D3D10 eh Pflicht ist
b) man Transistoren sparen musste
robbitop
2007-07-12, 13:47:40
Soviele Transistoren haette das nicht gekostet und es waere drastisch schneller.
Yo, dass es im Offlinerendering auch so gemacht wird liegt nur daran, dass ILM, Pixar & Co einfach nicht soviel Ahnung haben wie du, oh Erleuchteter :uhammer:
Das funktioniert nur deswegen, weil man genau weiß, welcher bereich scharf und welcher verblurrt sein soll. In einem ganzen Bild einem Blur-Filter zu legen ist einfach falsch und das geschieht auch nicht in Filmen mit viel CGI - siehe z.B Spider-Man 3. Beim ersten Auftritt des schwarzen Kostüm wurde alles per PC erstellt. Und dort ist nur der Huntergrund verblurrt.
Das hat aber nur was mit dem Feintuning der Filter sowie der virtuellen Kamera (DOF etc.) zu tun. Garantiert wird in keiner CGI-Szene irgendeines beliebigen Films ein Boxfilter zu "bewundern" sein. Wäre ja noch schöner, etliche Samples höchst aufwändig zu berechnen, nur um anschließend durch einen beschissenen Downfilter Qualität zu verbrennen.
Ich check nicht, warum ein Mittelwertfilter schlecht sein soll...
Weil ein Pixel kein kleines Rechteck ist, sondern ein Punkt. Ein Sample hat in alle Richtungen Auswirkung zu haben, nicht nur in Richtung des nächstgelegenen Pixels.
Der Satz ergibt irgendwie nur Sinn, wenn du Supersampling statt Multisampling meinst bzw. dort, wo keine Kanten vorhanden sind, ist MSAA so überflüssig wie ein Kropf - außer natürlich als erster Durchgang, um zu erkennen, wo SSAA genutzt werden soll.
Du hast meinen Ursprungspost nicht verstanden (oder nicht gelesen). Es ist sinnvoll, weil man an den Kanten auch Samples nimmt die außerhalb der Eckpixel liegen wenn man keinen Boxfilter hat.
Sofern die Tentfilter nur an Polyedges appliziert werden schon. (wie bei edge detection)
Immer noch Gaussian.
Ich check nicht, warum ein Mittelwertfilter schlecht sein soll...
Signaltheorie. Ein Boxfilter ist gänzlich schlecht um das Ursprungssignal zu rekonstruieren.
Du hast meinen Ursprungspost nicht verstanden. Es ist sinnvoll, weil man an den Kanten auch Samples nimmt die außerhalb der Eckpixel liegen wenn man keinen Boxfilter hat.Bei den (gemäß Pixel=Rechteck-Modell) einem Pixel zugehörigen Kantenpixeln hat man eh ein gewisses Maß an Supersampling, außerhalb derer aber doch identische Werte für alle Multisamples. Daher ist MSAA außerhalb von (gemäß Pixel=Rechteck-Modell) Kantenpixeln doch irrelevant außer eben für die Kantenerkennung, oder?
Und den arroganten Ton kannst auch bleiben lassen, ich weiß genau von was ich rede.Sorry, so sollte es echt nicht rüberkommen. Hielt es halt für einen Flüchtigkeitsfehler und wollte daher nochmal nachfragen, da ich den Sinn des Satzes so irgendwie nicht nachvollziehen kann.
Bei den (gemäß Pixel=Rechteck-Modell) einem Pixel zugehörigen KantenpixelnArrgh, sollte "Bei den (gemäß Pixel=Rechteck-Modell) einem Kantenpixel zugehörigen Samples" sein.
(gemäß Pixel=Rechteck-Modell)
Das ist schonmal falsch.
ftp://ftp.alvyray.com/Acrobat/6_Pixel.pdf
einem Pixel zugehörigen Kantenpixeln hat man eh ein gewisses Maß an Supersampling, außerhalb derer aber doch identische Werte für alle Multisamples.
Das ist ja das Problem, weil man sich damit bei einem Nicht-Box-Rekonstruktionsfilter Fehler einhandelt.
Daher ist MSAA außerhalb von (gemäß Pixel=Rechteck-Modell) Kantenpixeln doch irrelevant außer eben für die Kantenerkennung, oder?
Bei normalem Box-Downsampling mit gleich gewichteten Samples: Ja. Hier nicht. Ein Gaussfilter ist nicht mal innerhalb eines Pixels mit Multisampling sinnvoll, weil die Gewichtung nicht gleich ist.
Soviele Transistoren haette das nicht gekostet und es waere drastisch schneller.
Das weißt du woher?
Immer noch Gaussian.
Ich habe bisher eigentlich noch nirgends erwähnt gesehen, welcher Filter beim Edge-Detect-Modus angewendet wird. Gibt es dazu eine Quelle?
Das ist schonmal falsch.
ftp://ftp.alvyray.com/Acrobat/6_Pixel.pdfKenne ich, wollte damit verdeutlichen, dass ich mir des Unterschieds zwischen der eigentlichen Natur eines Pixels und dem falschen Pixel=Rechteck-Modell bewusst bin.
Das ist ja das Problem, weil man sich damit bei einem Nicht-Box-Rekonstruktionsfilter Fehler einhandelt.Mir war schon klar, dass MSAA und bessere Downfilter nicht gut zusammenpassen. Warum das so ist, ist mir aber erst durch diesen Thread aufgefallen:
MSAA fußt auf dem Pixel=Rechteck-Modell und ist somit zwangsläufig ein Hindernis für wirklich gute Grafik - und nicht nur, weil es lediglich die Geometrie feiner abtastet, wie ich bisher dachte.
Hmm...
Vielleicht könnte man bereits bei der Zuweisung der Farbwerte zu den einzelnen Multisamples auch die Farbwerte benachbarter Pixel hinzuziehen. Damit sollte sich MSAA auch ohne die Annahme des Pixel=Rechteck-Modells und somit besser verträglich mit besseren Downfiltern realisieren lassen. Würde aber die Farbwertkompression zumindest wesentlich komplizierter machen wenn nicht gar verunmöglichen...
Bei normalem Box-Downsampling mit gleich gewichteten Samples: Ja. Hier nicht. Ein Gaussfilter ist nicht mal innerhalb eines Pixels mit Multisampling sinnvoll, weil die Gewichtung nicht gleich ist.Außerhalb von Kantenpixeln brauchts bei herkömmlichem MSAA mit was besserem als nem Boxfilter aber doch nicht die eigentlichen Multisamples, sondern lediglich die korrekte Gewichtung. Das ist der Punkt, auf den ich mit meiner Nachfrage hinaus wollte.
Ich habe bisher eigentlich noch nirgends erwähnt gesehen, welcher Filter beim Edge-Detect-Modus angewendet wird. Gibt es dazu eine Quelle?
Ich meine eine ATI-Folie gesehen zu haben auf der zu sehen war, dass Edge-Detect einen angenäherten Gaussian benützt (3 verschiedene kreisförmige Zonen, aber kein linearer Abfall).
Außerhalb von Kantenpixeln brauchts bei herkömmlichem MSAA mit was besserem als nem Boxfilter aber doch nicht die eigentlichen Multisamples, sondern lediglich die korrekte Gewichtung. Das ist der Punkt, auf den ich mit meiner Nachfrage hinaus wollte.
Nein, man braucht auch die korrekte Subpixelfarbe, sonst blurt man wieder wie es der Tent-Filter von ATI auf's ganze Bild macht. Zwar nicht stark, aber dennoch.
Nein, man braucht auch die korrekte Subpixelfarbe, sonst blurt man wieder wie es der Tent-Filter von ATI auf's ganze Bild macht. Zwar nicht stark, aber dennoch.Gut, aber bei momentanen MSAA-Implementationen, die dem falschen Pixel=Rechteck-Modell folgen, hat man doch außerhalb von Kantenpixeln für alle Subpixel den gleichen Farbwert.
Könnte denn eine alternative Zuweisung der Subpixelfarbwerte, die ihnen auch außerhalb von Kantenpixel unterschiedliche interpolierte Werte zuordnet, bei der Verträglichkeit von MSAA und besseren Downfiltern helfen? War so eine spontane, nicht sonderlich durchdachte Idee, aber auch nach einigem Grübeln komme ich auf keine bessere, um auch ohne SSAA auskommen zu können. Also jetzt rein aus Perspektive des GeometrieAA, für ShaderAA außerhalb der Shader wirds weiter den Dampfhammer brauchen.
robbitop
2007-07-13, 14:03:50
Das weißt du woher?
Ist fuer mich intuitiv klar. Ein paar FF Funktionen fuer die Compares sollten so teuer nicht sein.
Mir war schon klar, dass MSAA und bessere Downfilter nicht gut zusammenpassen. Warum das so ist, ist mir aber erst durch diesen Thread aufgefallen:
MSAA fußt auf dem Pixel=Rechteck-Modell und ist somit zwangsläufig ein Hindernis für wirklich gute Grafik - und nicht nur, weil es lediglich die Geometrie feiner abtastet, wie ich bisher dachte.
Doch, eigentlich ist das schon so. MSAA basiert nicht unbedingt auf der Annahme dass Pixel Quadrate sind.
Ist fuer mich intuitiv klar. Ein paar FF Funktionen fuer die Compares sollten so teuer nicht sein.
Und mir ist intuitiv klar dass die niedrige Performance nicht an der Rechenleistung liegt. Falls es irgendwo ein Hardware-Problem gibt dann sollte dies gefixt werden und nicht durch Anflanschen einiger FF-Einheiten umgangen, womit man ja nur eine Hälfte des Problems löst. Downsampling im Shader ist ja immer noch notwendig und sollte dementsprechend auch schnell sein.
Doch, eigentlich ist das schon so. MSAA basiert nicht unbedingt auf der Annahme dass Pixel Quadrate sind.Wenn ich da nichts falsch verstehe liegt das Problem nicht in der Entkopplung von Geometrieabtastung und Textur-/Shaderabtastung/-berechnung, sondern die Rechteckannahme steckt darin, dass alle Multisamples eines Nichtkantenpixels den gleichen unmodifizierten Fabwert zugewiesen bekommen. Müsste der Subpixelfarbwert nicht eigentlich an die Subpixelposition angepasst werden, um die abzutastenden Frequenzen (und die Phase) an einer korrekteren Stelle abzutasten bzw. dieses besser anzunähern?
Wenn ich da nichts falsch verstehe liegt das Problem nicht in der Entkopplung von Geometrieabtastung und Textur-/Shaderabtastung/-berechnung, sondern die Rechteckannahme steckt darin, dass alle Multisamples eines Nichtkantenpixels den gleichen unmodifizierten Fabwert zugewiesen bekommen.
Genau genommen hat ein Nichtkantenpixel nur ein Farbsample. Die angenommene Form eines Pixels hängt vom Samplepattern ab, und es wäre durchaus auch mit Multisampling möglich, Geometriesamples außerhalb des "Pixelquadrats" zu nehmen.
Müsste der Subpixelfarbwert nicht eigentlich an die Subpixelposition angepasst werden, um die abzutastenden Frequenzen (und die Phase) an einer korrekteren Stelle abzutasten bzw. dieses besser anzunähern?
Natürlich müsste man korrekterweise Supersampling nehmen. Bei Multisampling könntest du aber höchstens interpolieren, und dies kann man ja in den Downsample-Filter integrieren.
robbitop
2007-07-14, 01:06:56
Und mir ist intuitiv klar dass die niedrige Performance nicht an der Rechenleistung liegt. Falls es irgendwo ein Hardware-Problem gibt dann sollte dies gefixt werden und nicht durch Anflanschen einiger FF-Einheiten umgangen, womit man ja nur eine Hälfte des Problems löst. Downsampling im Shader ist ja immer noch notwendig und sollte dementsprechend auch schnell sein.
Die Vergleichsoperationen die fuer die edge Detection zusaetzlich zum MSAA Resolve sind sicher nicht soo billig.
Die Vergleichsoperationen die fuer die edge Detection zusaetzlich zum MSAA Resolve sind sicher nicht soo billig.
Dann rechne doch mal vor.
Natürlich müsste man korrekterweise Supersampling nehmen. Bei Multisampling könntest du aber höchstens interpolieren, und dies kann man ja in den Downsample-Filter integrieren.So meinte ichs, Interpolation als Annäherung ans SSAA. Wieviel komplexer würde das den Downsamplefilter denn machen, zuallererst einen Filter pro Subpixel drüberlaufen zu lassen? Und wieviel würde das bringen? Müsste vielleicht mal jemand per D3D10 (oder gehts auch jetzt schon mit OpenGL?) in SW ne Demo zu machen, um es praktisch vergleichen zu können.
CFAA tut im Prinzip genau das – zumindest ist das eine Betrachtungsweise. Sample-Interpolation ist ja wie der Downsample-Filter nur eine gewichtete Summe, und beides lässt sich in einer Operation kombinieren.
Tut es das denn zusätzlich zum Downsamplefilter bzw. darin integriert, oder ist es "nur" der bessere Downsamplefilter?
Hoffentlich liefert NV auch noch bessere Filter nach. Wäre mit den Hybriden und reinen SSAA-Modi enorm schmackhaft.
Tut es das denn zusätzlich zum Downsamplefilter bzw. darin integriert, oder ist es "nur" der bessere Downsamplefilter?
Ähm, beides? Ich verstehe die Frage nicht. Das sind nur zwei Betrachtungsweisen derselben mathematischen Operation.
Zuerst einen Filter, um die Farbwerte der Subpixel an die Subpixelposition anzupassen (und somit mehr den eigentlich korrekten Werten, die durch SSAA erzeugt würden, anzunähern), dann den finalen Downfilter über die so modifizierten Subpixelfarbwerte.
Gut möglich, dass ich hier auf dem Holzweg bin, kenne Signaltheorie schließlich nur von 3dc und b3d sowie den beiden Foren, aber das scheint mir der richtige Weg zu sein.
Zuerst einen Filter, um die Farbwerte der Subpixel an die Subpixelposition anzupassen (und somit mehr den eigentlich korrekten Werten, die durch SSAA erzeugt würden, anzunähern), dann den finalen Downfilter über die so modifizierten Subpixelfarbwerte.
Gut möglich, dass ich hier auf dem Holzweg bin, kenne Signaltheorie schließlich nur von 3dc und b3d sowie den beiden Foren, aber das scheint mir der richtige Weg zu sein.
Wie gesagt, es ist dieselbe mathematische Operation. Zeig mir, wie du die Samples interpolieren willst, und ich zeige dir den Downsamplefilter der genau dasselbe Ergebnis bringt.
Aber ein Downfilter, der für SSAA gut ist, wäre doch nicht gleich gut geeignet für MSAA, oder? Muss der Unterschied in der Natur der zu verrechnenden Samples sich nicht auch im Downfilter niederschlagen?
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.