antialiasing manuell (software-mode) nachprogrammieren.

[LastManStanding]

Hi!

Stimmt beim Anti Aliasing (Multi Sampling) wird ein Bild vergößert, und anschließend auf die Ausgangsgröße gerendert.

Wenn du hilfe brauchst schau mal hier rein:
[url] www.spieleprogrammierer.de[/url]

Es geht hier zwar um 3D aber ich bin mir sicher du findest hier hilfe.

Wieso willst du es eigentlich Software - mäßig implementieren?

mfg LastManStandind

[interpreter]

LastManStanding schrieb:

Hi!

Stimmt beim Anti Aliasing (Multi Sampling) wird ein Bild vergößert, und anschließend auf die Ausgangsgröße gerendert.

Nein. Das was du beschreibst ist Supersampling und ist EINE (zienlich schlechte) Möglichkeit Anti-Aliasing zu implementieren. D3D verwendet z.B. Multisampling.

[TGGC]

Ist Antialiasing nicht einfach nur eine Faltung.

Bye, TGGC (Wähle deine Helden)

[DocJunioR]

*gg* also wenn ich bilder sehe, die aus einem Faltungsalgorithmus kommen, denk ich schon, dass sie einfach nur weicher gezeichnet sind

Was aber am Ende beim Antialiasing rauskommt sind einfach nur weiche Übergänge bei hohen Kontrasten. Wäre auch ne Möglichkeit, dieses "Weichzeichnen" nur da anzuwenden wo der Farbunterschied einen bestimmten Wert überschreitet.

[rapso]

interpreter schrieb:

LastManStanding schrieb:

Hi!

Stimmt beim Anti Aliasing (Multi Sampling) wird ein Bild vergößert, und anschließend auf die Ausgangsgröße gerendert.

Nein. Das was du beschreibst ist Supersampling und ist EINE (zienlich schlechte) Möglichkeit Anti-Aliasing zu implementieren. D3D verwendet z.B. Multisampling.

auch bei multisampling wird das bild in vielfacher auflösung gerendert und dann runterskaliert. informier dich über den wahren unterschied

DocJunioR schrieb:

*gg* also wenn ich bilder sehe, die aus einem Faltungsalgorithmus kommen, denk ich schon, dass sie einfach nur weicher gezeichnet sind

TGGC schrieb:

Ist Antialiasing nicht einfach nur eine Faltung.

rapso->greets();

[DocJunioR]

Anhand der Stellung der Worte in dem Satz erkenne ich den Kommentar
IST ANTI-ALIASING NICHT NUR EINE FALTUNG.
Trotz des Punktes am Ende als Fragesatz.

Wenn ich das jetzt fehlinterpretiert hab, dann liegts an meiner Brainware, die wurde seit Tagen nicht runtergefahren..

[loki1985]

ok, nach nochmaliger untersuchung der wikipedia habe ich gemerkt, dass es verschiedene methoden gibt, mein ansatz aber scheinbar nicht dazugehört. das problem ist dass ich das ganze möglichst schnell (da nicht HW-beschleunigt) und wenn möglich speicher-sparend implementieren möchte.

ich persönlich glaube zum beispiel, dass die methode mit dem vergrößern und dann wieder runtersampeln etwas zu krass ist für realtime-rendering.

gibts da irgendwelche simplen methoden (auch wenn das ergebnis dann nicht so dolle ist) ?

[rapso]

manche systeme (z.b. ps2) machen "edge antialiasing"

dabei ist es wichtig dass man von hinten nach vorne zeichnet. das zeichnen der einzelnen elemente z.b. dreiecke läuft dann so ab, dass erst das innere gezeichnet wird (auf normale art und weise).
danach (jetzt kommt's ) die kanten des elementes, dabei wird "line antialiasing" gemacht, das kann man ziemlich gut optimieren und muss schlussendlich auch keine vergrößerte version des ganzen bildes zeichnen, sondern mischt temporär pro linie.

natürlich ist das ab einer gewissen anzahl von linien langsammer als normales MSAA.

rapso->greets();

[Helium]

Was aber am Ende beim Antialiasing rauskommt sind einfach nur weiche Übergänge bei hohen Kontrasten. Wäre auch ne Möglichkeit, dieses "Weichzeichnen" nur da anzuwenden wo der Farbunterschied einen bestimmten Wert überschreitet.

Anti-Aliasing hat absolut gar nichts mit Weichzeichnen zu tun.

Offensichtlicher wird das ganze, wenn man das ganze aus dem Audio-Bereich kennt. Dann versteht man z.B. auch warum das überhaupt Aliasing heißt: Bei einer bestimmten Samplerate kann man maximal Frequenzen darstellen, die halb so hoch sind, wie die Samperate. Wenn man versucht eine höhere Frequenz darzustellen erhäklt man stattdessen einen Alias, der dem eigentlichen ton entspricht, nur um die halbe Samplerate gespiegelt (Nyquist-Frequenz). Solche Aliasse stören. Die lösung ist einfach eine höhere Samplerate zu nehmen (z.B. doppelt so hoch) und anschließend alle Frequenzen über der halben Ziel-Samplerate rauszufiltern und dann die Samplerate runterzurechnen.

Bei der Bildbearbeitung ist es nicht anders. Dinge, die quasi eine zu hohe "Frequenz" für die Auflösung haben (sprich kleiner sind als ein Pixel) führen zu Aliasen (das Phänomen des Alias könnte man nur wirklich erkennen, wenn man das Bild in den Frequenz-Bereich transformieren würde). Wenn man eine höhere Auflösung verwendet sind Dinge, die vorher zu klein waren möglicherweise nicht mehr zu klein und passen nun auf einen Pixel.
Kanten von Objekten sind quasi unendlich dünn. Deswegen kann man sie auch durch Oversampling nie komplett Alias-frei halten. Dennoch kann man die Qualität deutlich verbessern.

[interpreter]

[quote="rapso"
auch bei multisampling wird das bild in vielfacher auflösung gerendert und dann runterskaliert. informier dich über den wahren unterschied
[/quote]
Quellen? Bei Multisampling wird eben nicht in höherer Auflösung gerendert.

[rapso]

interpreter schrieb:

rapso schrieb:

auch bei multisampling wird das bild in vielfacher auflösung gerendert und dann runterskaliert. informier dich über den wahren unterschied

Quellen?

informier dich einfach. nvidia.com ati.com usw.

interpreter schrieb:

Bei Multisampling wird eben nicht in höherer Auflösung gerendert.

sind wir im kindergarten?
doch
nein
doch
nein

rapso->greets();

[interpreter]

rapso schrieb:

informier dich einfach. nvidia.com ati.com usw.

Ich habe meine Infos aus der DX9 Doku. Die Infos da sollten wohl stimmen, oder?

[0x00000001]

@loki:

Wie wäre es mit einem Alphakanal für die Bitmap? Entweder Du tust ihn schon im Grafikprogramm dazu oder erechnest ihn beim Laden der Bitmap. Benötigt zwar 33% mehr Speicher, aber dafür ersparst Du Dir die ganzen Vergleiche beim blitten.

[rapso]

interpreter schrieb:

rapso schrieb:

informier dich einfach. nvidia.com ati.com usw.

Ich habe meine Infos aus der DX9 Doku. Die Infos da sollten wohl stimmen, oder?

die infos stimmen, vielleicht aber deine interpretation davon nicht, oder dein englisch.

schau dir einfach diese presentation von nvidia an, die haben sogar bunte bildchen die das verdeutlichen dass auch bei msaa der framebuffer in vielfacher größe existiert.

rapso->greets();

[rapso]

0x00000001 schrieb:

@loki:

Wie wäre es mit einem Alphakanal für die Bitmap? Entweder Du tust ihn schon im Grafikprogramm dazu oder erechnest ihn beim Laden der Bitmap. Benötigt zwar 33% mehr Speicher, aber dafür ersparst Du Dir die ganzen Vergleiche beim blitten.

die vergleiche beim blitten resultieren in zwei "and" und einem "or". beim blenden müßte er hingegen 2"mul" und ein "add" haben.

aber er hätte weniger aliasing, da hast du recht

rapso->greets();

[loki1985]

0x00000001 schrieb:

@loki:

Wie wäre es mit einem Alphakanal für die Bitmap? Entweder Du tust ihn schon im Grafikprogramm dazu oder erechnest ihn beim Laden der Bitmap. Benötigt zwar 33% mehr Speicher, aber dafür ersparst Du Dir die ganzen Vergleiche beim blitten.

auch keine schlechte idee.... ich denke das teste ich mal aus.

dürfte ja fast meiner ersten überlegung entsprechen.

[0x00000001]

rapso schrieb:

die vergleiche beim blitten resultieren in zwei "and" und einem "or". beim blenden müßte er hingegen 2"mul" und ein "add" haben.

Versteh ich nicht. 2 AND und 1 OR? Er muss doch die Pixel in der Nachbarschaft anschauen ob die transparent sind. Wenn man das ganz naiv implementiert hat man schonmal 8 Vergleiche.
Mit dem alphakanal hat man zwar die langsameren operationen, aber dafür nur einmal pro Pixel.

Erklär mal bitte genauer wie Du das meinst, ich komm nicht drauf

[rapso]

0x00000001 schrieb:

rapso schrieb:

die vergleiche beim blitten resultieren in zwei "and" und einem "or". beim blenden müßte er hingegen 2"mul" und ein "add" haben.

Versteh ich nicht. 2 AND und 1 OR? Er muss doch die Pixel in der Nachbarschaft anschauen ob die transparent sind. Wenn man das ganz naiv implementiert hat man schonmal 8 Vergleiche.
Mit dem alphakanal hat man zwar die langsameren operationen, aber dafür nur einmal pro Pixel.

Erklär mal bitte genauer wie Du das meinst, ich komm nicht drauf

da er ja auf geschwindigkeit aus ist, unterstell ich ihm dass er das möglichst schnell machen möchte.

eine möglichkeit wäre

im main loop

for(u32 a=0;a<pixelzahl;a++)
{
  u32 MaskIndex = (pScreen[a]==ALPHAPIXEL);
  MaskIndex--;
//hier die 2und und ein or, kann man mit mmx schneller machen, oder cmov
//man sparrt zwar den vergleich nicht, doch der kostet kaum was,
//was man einsparrt ist ein conditionaljump was auf nem p4 bis zu 30takte kostet
  pOut[a]  = (pScreen[a]&MaskIndex) | (pOut[a]&(MaskIndex^0xffffffff)); 
}

rapso->greets();

[0x00000001]

OK der Code da mag schnell sein, aber glätten tut der nix
Ich mit meinem Halbwissen würde nach wie vor behaupten, dass ein vorberechneter Alphakanal die schnellste Möglichkeit ist.

[rapso]

0x00000001 schrieb:

OK der Code da mag schnell sein, aber glätten tut der nix
Ich mit meinem Halbwissen würde nach wie vor behaupten, dass ein vorberechneter Alphakanal die schnellste Möglichkeit ist.

ich hab ja auch nichts anderes behauptet, ich merkte nur an dass er 2and und ein or gegen 2mul und 1add tauscht was sehr viel langsammer sein kann, zumal er, wenn er per channel blendet, er 6 oder 8 muls 3 oder 4 add und noch ne menge maskierung hat (esseiden er nimmt mmx).

es würde also eventuell sogar schneller sein wenn er FSAA machen würde
wäre aber fallspezifisch .

rapso->greets();