[OPENGL] Kein Flickern auf Distanz bei Modellen

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Antworten
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

[OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Eisflamme »

Hey Leute,

Also ich habe einen recht unangenehmen Effekt bei Modellen, die in den Hintergrund gehen oder sich drehen etc. Ich habe mir jetzt verschiedene Möglichkeiten angeschaut:
* ARB_MULTISAMPLE (http://nehe.gamedev.net/data/lessons/le ... ?lesson=46)
* glHint mit GL_POINT_SMOOTH/GL_LINE_SMOOTH/GL_POLYGON_SMOOTH (http://glprogramming.com/red/chapter06.html#name2)
* Accumulation Buffer (http://www.cse.msu.edu/~cse872/tutorial5.html)

Irgendwie ist das alles nix. Bei 1) sehe ich im Beispiel nicht Mal den Unterschied, bei 2) sehe ich überhaupt keinen Unterschied, wenn ich das selbst etwas teste und bei 3) ist die Performance halt total im Eimer.

Was ist denn eine zeitgemäße Methode, was benutzt ihr so, was benutzen gut aussehende Spiele? Man sieht ja sehr viele Demos von den Grundlagen in OpenGL/DX und die haben ja alle diese harten Kanten und sind halt nicht wirklich "schön" dadurch. Da möchte ich weg. Bin nicht sicher, ob das direkt Antialising ist, vielleicht braucht man auch schönere Texturfilter.

Über Ideen oder ein paar Quellen würde ich mich freuen.

Ich hoffe, ihr wisst, was ich meine, sonst poste ich Mal einen Screenshot. :)

Viele Grüße und Danke
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Aramis »

Poste mal einen Screenshot, damit klar wird ob du von Z-Fighting o.ae. (Loesung: mehr Depth-Bits, bessere Tiefenaufteilung der Objekte), von Artefakten verursacht durch die Rasterisierung (Loesung: Multisampling) oder von Texturflimmern auf hohe Entfernung (Loesung: guter Texturfilter + MIPs) redest :-)
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Eisflamme »

Hi,

Also ich meine erstmal z.B. so was:
Bild
Oben sind das halt kantige Ränder, unten sind das so blöde vereinzelte Pixel und oben links (ohne Kreis) sieht man ja auch viele weiße, unschöne Pixel.

Ich habe auch Mal eine Gitarre gerendet, da sind die Seiten je nach Winkel auch seeehr seeehr kantig.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Aramis »

Ok. Einzelne Flackerpixel in Texturen werden durch MIP-Levels sowie qualitativ hochwertige Texturfilter (Trilinear aufwaerts) eliminiert. Entstehen kann sowas aber auch durch Fehler im Shading oder in den Normalen - oben links scheint das Licht gerade so von der Seite zu kommen dass nur einzelne Pixel beleuchtet werden, koennte evtl. durch weicheres Shading behebbar sein (sieht fuer mich nach Gouraud aus).

Filigrane Geometrie neigt dazu ohne Multisampling zu flackern bzw. haessliche Treppen und Einzelpixel von 1 px Breite zu werfen, das koennte unten Rechts der Fall sein.

Mehr kann ich aus dieser Aufloesung aber leider nicht herausraten - hast du ein 56k Modem oder wieso zeigst du nur so ein Mini-Bildchen? :-)
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Eisflamme »

Cool, danke schon Mal. :)

Na ja, so ähnlich. Von nahem sieht das halt nicht so schlecht aus mit den Pixelfehlern... Habs mal hochskaliert:
Bild

Zu den Filtern probier ich Mal ein wenig rum, habe da aber überhaupt keine Ahnung. Du hast nicht zufällig ne empfehlenswerte Seite dazu? Google liefert natürlich viel Zeug, da schau ich Mal durc.
Zuletzt geändert von Eisflamme am 22.06.2010, 14:53, insgesamt 1-mal geändert.
Benutzeravatar
TGGC
Establishment
Beiträge: 569
Registriert: 15.05.2009, 18:14
Benutzertext: Ich _bin_ es.
Alter Benutzername: TGGC
Echter Name: Ich _bin_ es.
Wohnort: Mainz
Kontaktdaten:

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von TGGC »

Koennten auch T-Cracks sein.
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Krishty »

Ja, du suchst definitiv AA und AF.

Multisample-Anti-Aliasing entpixelt die Objektkanten … netter Vergleich hier (ohne) und hier (mit 4×).

Dann brauchst du Mip-Maps für deine Texturen, die verhindern, dass deine Texturen auf Distanz verpixeln und flimmern (wie es z.B. gut in der Bildmitte zu sehen ist). Beispiel links ohne, rechts mit. Übrigens wird durch Mip-Maps auch alles wieder schneller.

Jedoch werden die Texturen dadurch verwaschen. Anisotrope Filterung sampled die Texturen präziser und gibt ihnen dadurch Schärfe zurück (links ohne, rechts mit), quasi der ideale Mittelweg zwischen verpixelt und verwaschen.

Bleibt die Frage, wie stark das eingestellt werden soll. Das hängt von der Qualitätsstufe ab – auf niedrigster Stufe lass alles so, wie es ist, aber füg Mip-Maps und trilinearen Filter hinzu. Auf mittlerer Qualitätsstufe 2×MSAA und 4×AF, das sieht zwar noch nicht ganz so sauber aus, aber ist von den meisten GPUs fix bewältigt. Auf höchster Qualitätsstufe 4- oder 8×MSAA und 16×AF (4×MSAA ist ab D3D10-level garantiert, 16×AF auch – wie es mit 8×MSAA aussieht, weiß ich nicht. ATI-Karten schaffen künstlich 24×AA, was allerdings kaum einen sichtbaren Unterschied zu 8×AA macht (im Gegensatz zu AF, wo man bis 64× noch Verbesserungen ausmachen kann). Außerdem gibt es noch SS-AA, wo alles einfach in n-facher Auflösung gerendert und vor dem Anzeigen runterskaliert wird, das ist aber enorm ineffizient. Letztendlich musst du das auf Basis der verwendeten Hardware entscheiden bzw den User entscheiden lassen. Normalerweise kann man solche Einstellungen im Grafiktreiber treffen, unter D3D jedoch nur bis exklusive 10.0, ob und wie die Einstellungen für OpenGL übernommen werden, weiß ich nicht).

Gruß, Ky

Edit: Und ganz unten sehe ich auch noch Z-Fighting :) Benutzt du einen Z-Buffer oder einen W-Buffer? Im Falle eines Z-Buffers ziehe die Far Plane so nah es dir die Szenerie erlaubt an dich ran und, 10× wichtiger, schiebe die Near Plane so weit wie möglich von dir weg. Zusätzlich kannst du auch noch die BitTiefe des Tiefenpuffers erhöhen, sofern es die Kompatibilität zulässt.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Eisflamme »

Hi,

Cool, danke für die starke Antwort.

Die ersten zwei Links (Multisampling AA) gehen bei mir nicht. Unabhängig davon sehen die KAnten bei mir aber immer noch kantig aus im Beispiel: http://nehe.gamedev.net/data/lessons/le ... ?lesson=46
Vll. unterstütz ich das einfach wieder Mal nicht mit meinem Laptop mit ATI Radeon Mobility blub?

Antisotrope Texturfilterung sieht super aus, aber ich kriege die wohl nicht so gut hin. Ich habe mal nach trilinearer Filterung geschaut erstmal in so einer TAbelle, wo man für MIN irgendwie LINEAR und für MAG LINEAR_MAG_LINEAR oder irgend so was nehmen sollte, um trilinear filtern zu können, allerdings verschwindet bei mir dann die Textur. KA, ob man daraus schon was erkennen kann.

Z-Buffer Near Plane möglichst nah und Far Plane möglichst weit weg? Wenn die Near sehr nah ist, hab ich aber sehr viele Grafikfehler. Wenn sie weiter weg ist, geht besser. Aber vll. hab ich das jetzt falsch gelesen, da stand ja zwei Mal far plane. :)

Danke schon Mal! Hier lernt man echt viel. Hoffe, das ist ok, dass ich hie so Löcher in den Bauch frage.
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Krishty »

Eisflamme hat geschrieben:Die ersten zwei Links (Multisampling AA) gehen bei mir nicht.
Ups, die wollen wohl kein Hotlinking. Kopieren und in der Adresszeile einfügen, dann funktionieren sie. Und beim Wechseln auf die Türme links von der Mitte achten.
Eisflamme hat geschrieben:Unabhängig davon sehen die KAnten bei mir aber immer noch kantig aus im Beispiel: http://nehe.gamedev.net/data/lessons/le ... ?lesson=46
Vll. unterstütz ich das einfach wieder Mal nicht mit meinem Laptop mit ATI Radeon Mobility blub?
Kann sein … früher gab es auch mal die Beschränkung, dass AA nur im Framebuffer und nicht in anderen Render-Targets funktionierte … vielleicht stimmt auch nur irgendein Parameter nicht … als OpenGL-Analphabet kann ich da aber nicht wirklich helfen.
Eisflamme hat geschrieben:Antisotrope Texturfilterung sieht super aus, aber ich kriege die wohl nicht so gut hin. Ich habe mal nach trilinearer Filterung geschaut erstmal in so einer TAbelle, wo man für MIN irgendwie LINEAR und für MAG LINEAR_MAG_LINEAR oder irgend so was nehmen sollte, um trilinear filtern zu können,
MIN (Minification) gibt an, wie die Textur aus der Entfernung gefiltert wird (wenn die Texel kleiner sind als die Pixel auf dem Bildschirm). Da sollte möglichst Anisotropie rein. LINEAR tut es auch, dann wird es aber stark verwaschen. POINT flimmert oft.
MAG (Magnification) gibt an, wie die Textur gefiltert wird, wenn sie so nah ist, dass die Texel größer als die Pixel auf dem Bildschirm sind. Da sollte LINEAR reichen (die meisten Karten unterstützen hier auch kaum was Anderes), mit POINT haben die Pixel das typische Rechteckmuster.
MIP gibt an, wie zwischen den einzelnen Mip-Maps interpoliert wird. Ist das POINT, sieht man, wie sich die Auflösung vor einem herschiebt, LINEAR sorgt für weiche Übergänge.
Solange du nicht anisotrop filterst, werden die Texturen aber eher ziemlich verwaschen sein.
Eisflamme hat geschrieben:allerdings verschwindet bei mir dann die Textur. KA, ob man daraus schon was erkennen kann.
Kann bedeuten, dass du zwar Mip-Levels angelegt hast, sie aber nicht befüllt wurden.
Eisflamme hat geschrieben:Aber vll. hab ich das jetzt falsch gelesen, da stand ja zwei Mal far plane. :)
Ja, Zudomon hat mich gestern schon freundlicherweise drauf aufmerksam gemacht, da warst du aber schon weg … ich editiere eh immer alles dauernd, darum kann es sich lohnen, zehn Minuten später nochmal zu lesen ;) Die Near Plane muss so weit wie möglich weg, die Far Plane so nah wie möglich ran. Je näher sich die beiden kommen, desto präziser kann der begrenzte Speicherplatz der Tiefenwerte zwischen beiden aufgeteilt werden und desto weniger unbeabsichtigte Überlappungen entstehen, wenn sich zwei Polygone nahe kommen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Eisflamme »

Okay. :)

Also es lag tatsächlich daran, dass die MipMaps nicht erzeugt wurden. Ich habe die Textur Mal weggeblendet und die Pixelfehler bleiben allerdings immer noch. Weiß nicht, ob das mit AA weggeht, aber da sehe ich ja wie gesagt eh keinen Unterschied, woraus ich schließe, dass mein Laptop wieder Mal nicht kann.

Sonst noch irgendetwas, was ich tun kann?
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Krishty »

Eisflamme hat geschrieben:Sonst noch irgendetwas, was ich tun kann?
Supersample-Anti-Aliasing … also in hoher Auflösung rendern und dann runterfiltern. Erfordert Render-to-Texture-Fähigkeiten von der GPU, ist furchtbar ineffizient und knifflig zu implementieren (wenn man es richtig machen will). Ist die letzte Bastion wenn du Performance im Überschuss hast oder die Performance egal ist und aufs Verrecken gute Bildqualität brauchst.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: [OPENGL] Kein Flickern auf Distanz bei Modellen

Beitrag von Eisflamme »

Okay, alles klar, danke :)
Antworten