Archiv verlassen und diese Seite im Standarddesign anzeigen : Was ist post processing?
BlackArchon
2004-12-19, 00:33:17
Beim rumspielen mit den Optionen des 3DMark03 ist mir die Option 'Post processing' aufgefallen. Wenn ich das aktiviere, sieht die Beleuchtung in den Game Tests viel intensiver aus. Da ist mir auch eingefallen, dass diese Option beim 3DMark05 standardmäßig aktiv ist.
Was macht das Post processing eigentlich genau? Und wo wird das noch eingesetzt?
Beim rumspielen mit den Optionen des 3DMark03 ist mir die Option 'Post processing' aufgefallen. Wenn ich das aktiviere, sieht die Beleuchtung in den Game Tests viel intensiver aus. Da ist mir auch eingefallen, dass diese Option beim 3DMark05 standardmäßig aktiv ist.
Was macht das Post processing eigentlich genau? Und wo wird das noch eingesetzt?Post Processing heißt nur Nachbearbeitung. Was das "genau" macht, hängt davon ab.
TobiWahnKenobi
2004-12-20, 11:44:35
es macht dass dieser benchmark endlich die entsprechende optik bekommt.
leider büsst man dann auch 1000 punkte ein.. sieht aber um längen besser aus.
mfg
tobi
Savay
2004-12-21, 00:32:56
nunja es heißt ja das etwas nachgearbeitet wird...d.h. wenn das bild fertig gerendert ist und theoretisch dargestellt werden kann, es letztendlich nochmal auf irgendeine weise gefiltert oder manipuliert wird....
hmm ist dann nich auch SSAA quasi post processing :conf: jojo lol muss an der urzeit liegen aber ich glaube da schon selbst fast dran :rolleyes:
hmm ist dann nich auch SSAA quasi post processing Nein.
Nein.
Dito. Post-Processing glättet das Bild zwar auch, aber eben nicht wie (SS)AA das tut. PP ist meist eine Art "Filter" über der Anwendung, welcher Unschärfe-Effekte ins Spiel bringt oder, wie hier im 3DMark oder Prince of Persia 4, Farben heller leuchten lässt. Blöderweise kostet das nicht nur Performance, sondern ist auch manchmal inkompatibel mit AA.
MfG,
Raff
Demirug
2004-12-21, 07:24:47
Ganz streng genommen ist auch jegliche Form von AA als Postprocessing zu bezeichnen. Denn auch dabei wird ein Filter (in der Regel ein Downfilter) auf das fertig gerenderte 2D Bild angewendet. Der Unterschied dabei ist nur das dieses Postprocessing von der Grafikkarte direkt angeboten wird. Es wäre aber genauso denkbar zum Beispiel einen Glowfilter im Panel anzubieten.
Fruli-Tier
2004-12-21, 08:00:27
Kann vielleicht jemand mal ein paar Vergleichsbilder posten? Der Unterschied würde mich mal interessieren.
BlackArchon
2004-12-21, 11:07:05
Hier Vergleichsbilder. Achtung, das sind alles PNG-Bilder (~1 MB pro Bild), verlustfrei komprimiert. Auf den Bildern schlecht zu sehen ist die Unschärfe im Hintergrund, die recht realistisch wirkt.
GT2 (Proxycon)
ohne PP (http://home.arcor.de/blackarchon81/GT2-normal.png)
mit PP (http://home.arcor.de/blackarchon81/GT2-pp.png)
GT3 (Troll)
ohne PP (http://home.arcor.de/blackarchon81/GT3-normal.png)
mit PP (http://home.arcor.de/blackarchon81/GT3-pp.png)
GT4 (Nature)
ohne PP (http://home.arcor.de/blackarchon81/GT4-normal.png)
mit PP (http://home.arcor.de/blackarchon81/GT4-pp.png)
[ohne (http://moon3d.sourceforge.net/pp-fx/q3dm17-noglow.png)] [mit (http://moon3d.sourceforge.net/pp-fx/q3dm17-glow.png)]
Die am meisten verbreitete Effekt scheint zur Zeit der "glow-effekt" zu sein.
Wen es interessiert, wie man den implementieren kann: [Beispiel mit Shadern (http://collective.valve-erc.com/index.php?go=tron1)] [Beispiel ohne Shader (http://collective.valve-erc.com/index.php?go=tron2)]
Prinzipiell sind alle möglichen Effekte denkbar, allerdings geht die Performance recht schnell aufgrund der langsamen AGP Lesegeschwindigkeit in die Knie.
MadManniMan
2004-12-29, 01:27:55
Hm, gut zu sehen an seth verlinkten Bildern: trotz Glow muß das Bild nicht zwangsweise vermatscht sein - warum aktivieren Bloom in der gemoddeten UE2 und die PP-Filter beim Murks zusätzlich Blur?
hmm, ich muss sagen der 3dmark03 sieht bei mir schon so aus ohne daß ich das aktiviere, so scheint es mir jedenfalls, keine lust jetzt zu instalieren nur um das zu überprüfen. aber hier
http://koti.mbnet.fi/kegetys/rbr/index.php?p=rbrdll
das ist ein mod für richard burns rally der das unterstützt. und ich muss sagen. da gibts eigentlich keine performance nachteile, ich spüre sie jedenfalls nicht mit meiner 9700pro.
loewe
2004-12-31, 21:48:12
um mal wieder was zum Thema bei zu tragen:
http://gb.espacenet.com/search97cgi/s97is.dll?Action=View&ViewTemplate=e/gb/en/viewer.hts&collection=dips&SearchType=1&VdkVgwKey=GB2403115A
Schon gelesen? :)
mapel110
2005-01-01, 03:03:55
um mal wieder was zum Thema bei zu tragen:
http://gb.espacenet.com/search97cgi/s97is.dll?Action=View&ViewTemplate=e/gb/en/viewer.hts&collection=dips&SearchType=1&VdkVgwKey=GB2403115A
Schon gelesen? :)
1.Was hat das mit dem thema post processing zu tun?
2. iirc wendet doch der Deltachrom sowas an?!
3. Lange nicht gesehen, frohes neues Jahr. :)
/edit
hat sich erledigt, ich sollte doch hinundwieder auf mitrax.de vorbei schauen. :)
Demirug
2005-01-01, 16:29:00
um mal wieder was zum Thema bei zu tragen:
http://gb.espacenet.com/search97cgi/s97is.dll?Action=View&ViewTemplate=e/gb/en/viewer.hts&collection=dips&SearchType=1&VdkVgwKey=GB2403115A
Schon gelesen? :)
Ist man dort jetzt neben S3 und nVidia auch auf den Trichter gekommen. Wobei es sich ja um eine Variante handelt die primär keine Füllrate sondern Bandbreite spart.
loewe
2005-01-01, 18:55:23
Ist man dort jetzt neben S3 und nVidia auch auf den Trichter gekommen. Wobei es sich ja um eine Variante handelt die primär keine Füllrate sondern Bandbreite spart.
Naja, so ganz neu ist das ja wohl auch für ImgTec nicht.
Die Sache mit den MipMaps macht ja schon KYRO wenn wohl auch noch nicht so vollständig in Hardware und auch das Filtering ist schon länger in Arbeit.
Mir sagt vor längerer Zeit schon mal einer der Ings, wir sollen aufhören mit unseren Testprogrammen mit den gefärbten MipMap Stufen, die geben keine hinreichende Aussage bezüglich der Filterung. Ihre Verfahren werden dadurch nicht erkannt und auch nicht angezeigt.
MBX liefert ja wohl schon einiges davon, aber wer hat schon ein Gerät mit MBX? Über andere Dinge wollen wir gar nicht sprechen.
Egal, auf jeden Fall allen ein gesundes neues Jahr. :)
Demirug
2005-01-02, 00:07:03
Naja, so ganz neu ist das ja wohl auch für ImgTec nicht.
Die Sache mit den MipMaps macht ja schon KYRO wenn wohl auch noch nicht so vollständig in Hardware und auch das Filtering ist schon länger in Arbeit.
Mir sagt vor längerer Zeit schon mal einer der Ings, wir sollen aufhören mit unseren Testprogrammen mit den gefärbten MipMap Stufen, die geben keine hinreichende Aussage bezüglich der Filterung. Ihre Verfahren werden dadurch nicht erkannt und auch nicht angezeigt.
MBX liefert ja wohl schon einiges davon, aber wer hat schon ein Gerät mit MBX? Über andere Dinge wollen wir gar nicht sprechen.
Egal, auf jeden Fall allen ein gesundes neues Jahr. :)
Das war eher in die Richtung gemeint das man sich da auch mal ein Patent in die Richtung beschaft.
Ich sehe zwar durchaus ein das man bei dem Verfahren mit gefärbten Mipmaps nichts mehr sieht. Ist bei S3 ja heute schon so. Darum habe ich ja auch ein anderes Testverfahren entwickelt. Das aber leider auch viel aufwendiger ist. Allerdings bin ich der Meinung der Treiber sollte erkennen wenn eine Mipmap nicht via Boxfilter aus der nächst grösseren gewonnen wurde und dann solche Verfahren deaktivieren. Es gibt nämlich Situationen bei denen der Boxfilter der falsche Filter für den Job ist. Zum Beispiel bei Normalmaps.
Ist man dort jetzt neben S3 und nVidia auch auf den Trichter gekommen. Wobei es sich ja um eine Variante handelt die primär keine Füllrate sondern Bandbreite spart.
Inwiefern beschleunigen S3 und NVidia die automatische Mipmap-Generierung?
Mr. Lolman
2005-01-02, 01:26:24
3dfx Karten können ja auch Automipmapping. Oder war das ein reines Softwarefeature?
Automipmapping kann praktisch jede Karte. Das Besondere an der PowerVR-Lösung ist, dass man sich einen Teil der benötigten Bandbreite spart
Demirug
2005-01-02, 01:51:45
Inwiefern beschleunigen S3 und NVidia die automatische Mipmap-Generierung?
Wie gesagt bezog sich das ja auf die Patentschriften. S3 benutzt das ganze ja für Fast-TRI und nVidia hat dafür ein Patent angemeldet nutzt es aber AFAIK bisher noch nicht.
zeckensack
2005-01-02, 03:34:12
3dfx Karten können ja auch Automipmapping. Oder war das ein reines Softwarefeature?Software.
MadManniMan
2005-01-02, 03:44:17
Wie gesagt bezog sich das ja auf die Patentschriften. S3 benutzt das ganze ja für Fast-TRI und nVidia hat dafür ein Patent angemeldet nutzt es aber AFAIK bisher noch nicht.
Errm, spart Fast-Tri nich auch Füllrate? Das ist es doch, was Tri-Pipes ausmacht, oder nicht?
Das war eher in die Richtung gemeint das man sich da auch mal ein Patent in die Richtung beschaft.
Ich sehe zwar durchaus ein das man bei dem Verfahren mit gefärbten Mipmaps nichts mehr sieht. Ist bei S3 ja heute schon so. Darum habe ich ja auch ein anderes Testverfahren entwickelt. Das aber leider auch viel aufwendiger ist. Allerdings bin ich der Meinung der Treiber sollte erkennen wenn eine Mipmap nicht via Boxfilter aus der nächst grösseren gewonnen wurde und dann solche Verfahren deaktivieren. Es gibt nämlich Situationen bei denen der Boxfilter der falsche Filter für den Job ist. Zum Beispiel bei Normalmaps.Ich überlege seit einiger Zeit, ob man den 4x4 Filterkernel auch zum AF missbrauchen kann. In 4x4 Texeln bekommt man mit etwas Glück 2 oder 3 bi-Samples rein. Die Idee wäre, trilineare Samples indirekt zu erzeugen, in dem auf der Line of Anisotropy X bi-Samples und auf der nächstkleineren Mip X/2 bi-Samples genommen werden, alles wird dann zusammengemischt. Hat man mit dem 4x4-Kernel 2 Bi-Samples pro Takt, spart man über 60% der Füllrate ein – ohne die Qualität zu verschlechtern.
Wie gesagt bezog sich das ja auf die Patentschriften. S3 benutzt das ganze ja für Fast-TRI und nVidia hat dafür ein Patent angemeldet nutzt es aber AFAIK bisher noch nicht.
Ich sehe nur nicht ganz was dieses Patent mit Fast-Trilinear zu tun haben soll.
PowerVR nutzt auch Fast-Trilinear, zumindest in Verbindung mit DXT1, da es damit nochmal wesentlich einfacher ist (man interpoliert nicht mehr Farben, sondern Indizes). Und das ist auch patentiert, IIRC.
Demirug
2005-01-02, 10:57:16
Ich überlege seit einiger Zeit, ob man den 4x4 Filterkernel auch zum AF missbrauchen kann. In 4x4 Texeln bekommt man mit etwas Glück 2 oder 3 bi-Samples rein. Die Idee wäre, trilineare Samples indirekt zu erzeugen, in dem auf der Line of Anisotropy X bi-Samples und auf der nächstkleineren Mip X/2 bi-Samples genommen werden, alles wird dann zusammengemischt. Hat man mit dem 4x4-Kernel 2 Bi-Samples pro Takt, spart man über 60% der Füllrate ein – ohne die Qualität zu verschlechtern.
Für Fast-Tri wird aber kein echter frei nutzbarer 4*4 Kernel benutzt.
Demirug
2005-01-02, 11:03:32
Ich sehe nur nicht ganz was dieses Patent mit Fast-Trilinear zu tun haben soll.
PowerVR nutzt auch Fast-Trilinear, zumindest in Verbindung mit DXT1, da es damit nochmal wesentlich einfacher ist (man interpoliert nicht mehr Farben, sondern Indizes). Und das ist auch patentiert, IIRC.
In beiden Fällen geht es darum mit speziellen zusätzlichen Schaltkreisen Mipmaps automatisch zu erzeugen um Bandbreite zu sparen. Die Grundidee ist daher die gleiche.
loewe
2005-01-02, 11:37:03
Ich sehe nur nicht ganz was dieses Patent mit Fast-Trilinear zu tun haben soll.
Eigentlich wenig, aber es ermöglicht eben durch die pre und post Filter jede Art von Filtering zu realisieren. Dazu gehören dann auch bi und trilineare Filter oder auch Aniso, wenn man dann bereit ist die Hardware dafür zu implementieren.
PowerVR nutzt auch Fast-Trilinear, zumindest in Verbindung mit DXT1, da es damit nochmal wesentlich einfacher ist (man interpoliert nicht mehr Farben, sondern Indizes). Und das ist auch patentiert, IIRC.
Besser "PowerVR nutzte bei KYRO".
Das dortige Verfahren wird in den nachfolgenden Generationen nicht mehr weiter verwendet, dort bekommen wir dann echtes Trilineares Filtering, auch ohne TC. ;)
Eigentlich wenig, aber es ermöglicht eben durch die pre und post Filter jede Art von Filtering zu realisieren. Dazu gehören dann auch bi und trilineare Filter oder auch Aniso, wenn man dann bereit ist die Hardware dafür zu implementieren.
Texturfilterung (im Sinne von: Filtern beim Samplen) kann man nicht durch diese Pre- oder Postfilter realisieren.
Besser "PowerVR nutzte bei KYRO".
Das dortige Verfahren wird in den nachfolgenden Generationen nicht mehr weiter verwendet, dort bekommen wir dann echtes Trilineares Filtering, auch ohne TC. ;)
Eigentlich schade, die Grundidee dahinter ist verdammt clever, und äußerst sparsam was Transistoren angeht.
loewe
2005-01-02, 18:26:30
Texturfilterung (im Sinne von: Filtern beim Samplen) kann man nicht durch diese Pre- oder Postfilter realisieren.
Versteh ich nicht, kannst du das erklären?
Bilineares, Trilineares, Anistropes Filtering sind durch diese Pre- und Post-Filter möglich, warum nicht???
Versteh ich nicht, kannst du das erklären?
Bilineares, Trilineares, Anistropes Filtering sind durch diese Pre- und Post-Filter möglich, warum nicht???
Weil man dafür Texturkoordinaten und Gradienten bräuchte. Wo sollten die denn hier herkommen?
loewe
2005-01-03, 00:04:49
Weil man dafür Texturkoordinaten und Gradienten bräuchte. Wo sollten die denn hier herkommen?
Ok, mein Problem wird schlimmer! :)
Wieso brauche ich für normales Filtering wie bi,tri oder aniso Texturkoordinaten und Gradienten?
Ich habe ein 32x32 Raster der Textur und damit habe ich doch erst einmal alles was ich brauche, außer im Randbereich, aber das ist lösbar.
Diese Texturarbeit wird nach dem HSR (ISP) im TSP durchgeführt, sprich es erfolgt sowieso nur für Texturen die gebraucht werden und wo auch genau bekannt ist welche(s) Pixel die Textur erhalten werden, wieso sollte da noch ein Problem mit den Texturkoordinaten auftreten?
loewe
2005-01-03, 00:13:17
Eigentlich schade, die Grundidee dahinter ist verdammt clever, und äußerst sparsam was Transistoren angeht.
Wenn ich ein Verfahren habe, was immer anwendbar ist und auch noch die bessere Qualität liefert, wird jedes weitere Verfahren zur Verschwendung bzw. Belastung, auch dann wenn es in speziellen Fällen noch so clever ist. :)
Ok, mein Problem wird schlimmer! :)
Wieso brauche ich für normales Filtering wie bi,tri oder aniso Texturkoordinaten und Gradienten?
Ich habe ein 32x32 Raster der Textur und damit habe ich doch erst einmal alles was ich brauche, außer im Randbereich, aber das ist lösbar.
Für Trilinear brauchst du erst mal zwei Mipmap-Stufen, und die stehen weder dem Input- noch dem Output-Filter hier zur Verfügung. Außerdem noch die Gradienten, weil du sonst keinen LOD hast.
Bilinear und AF kann man im Prinzip auch für Up- und Downscaling verwenden, nur sehe ich hier nichts was darauf hindeutet dass Input und Output für die beiden Filter unterschiedliche Größen haben sollten. Das einzige was überhaupt erwähnt wird ist ein Low-Pass-Filter für Video-Inhalte. Edge Enhancement, Median, etc. wäre noch denkbar, also das ganze Photoshop-Arsenal. Aber mit dem üblichen Textur-Samplen zum Texturieren von Polygonen hat das nichts zu tun.
Diese Texturarbeit wird nach dem HSR (ISP) im TSP durchgeführt, sprich es erfolgt sowieso nur für Texturen die gebraucht werden und wo auch genau bekannt ist welche(s) Pixel die Textur erhalten werden, wieso sollte da noch ein Problem mit den Texturkoordinaten auftreten?
Diese Auto-Mipmap-Generierung ist zwar so ausgelegt, dass sie auch nur bei Bedarf erfolgen kann, aber das Patent erwähnt nicht, dass irgendwie beachtet würde welche Teile der Textur später zum Einsatz kommen. Also entweder "Textur wird nicht benötigt, tue nichts", oder "Generiere alle Mipmaps vollständig". Es geht hier nicht um das On-the-fly-Generieren virtueller Mipmaps während dem Samplen, wie das bei Fast-Trilinear der Fall ist.
loewe
2005-01-03, 10:46:53
Für Trilinear brauchst du erst mal zwei Mipmap-Stufen, und die stehen weder dem Input- noch dem Output-Filter hier zur Verfügung. Außerdem noch die Gradienten, weil du sonst keinen LOD hast.
Ddie erzeugten Mip Stufen können/werden sowohl im externen Texturspeicher als auch im internen Speicher abgelegt. Beides ist vorgesehen und ja aucxh intern kein Problem, da ja maximal für alle Mip Stufen zusammen noch einmal ein drittel des Speicherplatzes der Ausgangstextur benötigt wird.
Schon in Figur 2 ist der Output Filter erst hinter der Schleife angeordnet und somit liegen dort dann auch alle Mip Stufe vor und können verwendet werden.
Diese Auto-Mipmap-Generierung ist zwar so ausgelegt, dass sie auch nur bei Bedarf erfolgen kann, aber das Patent erwähnt nicht, dass irgendwie beachtet würde welche Teile der Textur später zum Einsatz kommen. Also entweder "Textur wird nicht benötigt, tue nichts", oder "Generiere alle Mipmaps vollständig". Es geht hier nicht um das On-the-fly-Generieren virtueller Mipmaps während dem Samplen, wie das bei Fast-Trilinear der Fall ist.
Das stimmt, die Mip Stufen werden entweder je Bild oder je Tile erzeugt und verwendet, hier geht es wohl eher um eine Erzeugung je Tile. Dabei wird erst einmal nicht berücksichtigt, welcher Teil der Mip Map überhaupt verwendet werden wird.
Ich werde mich noch einmal erkundigen, was hier alles getan wird oder werden kann. :)
Ddie erzeugten Mip Stufen können/werden sowohl im externen Texturspeicher als auch im internen Speicher abgelegt. Beides ist vorgesehen und ja aucxh intern kein Problem, da ja maximal für alle Mip Stufen zusammen noch einmal ein drittel des Speicherplatzes der Ausgangstextur benötigt wird.
Schon in Figur 2 ist der Output Filter erst hinter der Schleife angeordnet und somit liegen dort dann auch alle Mip Stufe vor und können verwendet werden.
Die vorherige Mipmap wird im internen Speicher durch die neue Mipmap überschrieben. Der Output-Filter bekommt immer nur jene Mipmap, die gerade erzeugt wurde und in den externen Speicher geschrieben werden soll. Und was wollte man schon mit mehreren Mipmaps tun, wenn man keinen LOD hat?
loewe
2005-01-03, 19:04:49
Die vorherige Mipmap wird im internen Speicher durch die neue Mipmap überschrieben.
Das stimmt so nicht und steht dort auch nicht. Dort steht das man den speicher entsprechend klein halten kann, aber es muss auch nicht sein. wenn ich wie dort auch angesprochen von einem 32x32 Pixel Speicherbereich ausgehe, belegen alle weiteren Mip Stufen zusammen von den 1024 Pixeln nur 341 Pixel. Es passen also alle weiteren Mip Stufen völlig problemlos in den internen Speicher, wenn nur die erste Stufe ausgelagert wird.
Der Output-Filter bekommt immer nur jene Mipmap, die gerade erzeugt wurde und in den externen Speicher geschrieben werden soll. Und was wollte man schon mit mehreren Mipmaps tun, wenn man keinen LOD hat?
Das ist dort so auch nicht geschrieben, viel mehr hält man sich alle Optionen offen.
Das stimmt so nicht und steht dort auch nicht. Dort steht das man den speicher entsprechend klein halten kann, aber es muss auch nicht sein. wenn ich wie dort auch angesprochen von einem 32x32 Pixel Speicherbereich ausgehe, belegen alle weiteren Mip Stufen zusammen von den 1024 Pixeln nur 341 Pixel. Es passen also alle weiteren Mip Stufen völlig problemlos in den internen Speicher, wenn nur die erste Stufe ausgelagert wird.
Es steht da nicht dass überschrieben werden muss. Aber es steht da dass überschrieben werden kann, und dass es im Prinzip keinen Unterschied macht. Wozu sollte man die größeren Mipmaps auch noch verwenden?
Das ist dort so auch nicht geschrieben, viel mehr hält man sich alle Optionen offen.
Nein, das Diagramm gibt nichts anderes her. Außerdem beantwortet das meine Frage nicht.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.