Problem in Spielen: "Weiße Linien" (Polygaps) und Texturflackern (Z-Fighting)

[Zulumann]

Hallo,

ich jetzt schon in einigen Spielen festgestellt, daß an den Textur-/Polygon übergängen weiße, gestrickchelte Linien zum Vorschein kommen.

1. Beispiel: GTA 3 (http://mitglied.lycos.de/zulushome/Bilder/gta3%201.jpg)
2. Beispiel: GTA 3 (http://mitglied.lycos.de/zulushome/Bilder/gta3%202.jpg)
3. Beispiel: GTA3 (http://mitglied.lycos.de/zulushome/Bilder/gta3%203.jpg)
4. Beispiel: Mafia (http://mitglied.lycos.de/zulushome/Bilder/mafia.jpg)
6. Beispiel: Halo (http://mitglied.lycos.de/zulushome/Bilder/halo.jpg)
7. Beispiel: Warcraft 3 (http://mitglied.lycos.de/zulushome/Bilder/war3.jpg)
8. Beispiel: Simpsons Hit&Run (http://mitglied.lycos.de/zulushome/Bilder/Simpsons.jpg)
8. Beispiel: Simpsons Hit&Run (http://mitglied.lycos.de/zulushome/Bilder/simpsons2.jpg)
9. Beispiel: Medal of Honor (http://mitglied.lycos.de/zulushome/Bilder/mohaa.jpg)

Außerdem hab ich in manchen Spielen auch ein "Texturflackern", d.h. 2 Texturen überlagern sich anscheinend und rufen dann diese Flackern hervor (soweit ich weiß bezeichnet man das als Z-Fighting). Kommt bei mir z.B. bei Blut in Medal of Honor (hab nen Blutmod), bei Mafia (Bremsspuren, Teile von Gebäuden) und bei GTA Vice City (es flackert z.B. der Regalschatten im Anfangsintro, wo die Mafiosos am Tisch sitzen ->Video (400kb) (http://mitglied.lycos.de/zulushome/Bilder/vicecity2.avi)) vor.
Da man dieses Falckern logischerweise nicht mit einem Screenshot zeigen kann, hab ich mal 2 gemacht.

Screen 1 (http://mitglied.lycos.de/zulushome/Bilder/mafia1.jpg)
Screen 2 (http://mitglied.lycos.de/zulushome/Bilder/mafia2.jpg)


Kann man diese oben genannten Fehler irgendwie beseitigen? Es stört nämlich schon ein bisschen, vor allem wenn es so extrem ist, wie in GTA 3. :(
Oder anders gefragt: An was liegt dieser Fehler? Meine Grafikkarte kann ich eigentlich ausschließen, da die gleichen Fehler mit einer anderen Radeon 9800Pro auch auftreten.

Mein System:
AMD XP2500+ @2100Mhz
Abit NF7 2.0
TwinMOS 2x256MB (DDR400)
Radeon 9800 Pro mit aktuellem Catalyst
Netzteil: Tagan U01-TG380

Die Fehler müssten sich irgendwie beseitgen lassen, da andere diese Probleme (egal ob mit ATI- oder nVidia-Karten)scheinbar nicht haben.
Wer weiß Rat?


Danke
Zulumann

[q@e]

Ab ins ATi-Unterforum damit....

[Jesus]

hattest du vorher ne andere ATI Karte drin ? oder vielleicht gar ne NVIDIA (!!!) ? :)

dann am besten mal Drivercleaner probieren und neu installiern.

[Crushinator]

*verschieb* (/edit: erstmal ins ATI-Forum)

[Zulumann]

Original geschrieben von q@e
Ab ins ATi-Unterforum damit....
Scheint aber kein generelles Problem von ATI zu sein, da es auch mit einigen nVidia-Karten auftritt und auf einigen ATI's wiederum nicht.
Deshalb finde ich, sollte der Thread im Grafikchipsforum bleiben. :)

EDIT: Nein, ich hatte das Problem von Anfang an, auch mit einer 2ten Radeon 9800Pro. Selbst mit einer Geforce FX5600 ließen sich diese Fehler nicht beseitigen (auch auf einem anderen Rechner). Hab schon fast sämtliche Treiber ausprobiert und weiß nun nicht mehr weiter.

EDIT: Hab auch immer schön mit DriverCleaner alles deinstalliert. Auch einige Format C:'s hab ich schon hinter mir.

[Crushinator]

Ist noch jemand der Meinung, daß der Thread zurück sollte?

[MadMan2k]

Original geschrieben von Crushinator
Ist noch jemand der Meinung, daß der Thread zurück sollte?
*meld*

wobei man vielleicht noch das verwertbare aus diesem Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=115237&highlight=Polygaps+gta) hier reinmergen könnte...

[Crushinator]

Bei dem Versuch verwertbares in dem besagten Thread zu finden, tat mir der damals so leidende Hund von Thowe der Art leid, daß ich wohl etwas länger brauche, um die Verwertung durchzuführen. Der Thread kommt jedenfalls erstmal wieder zurück. *zurückschieb* :)

[Mr. Lolman]

In solchen Fällen hilft es meist, AA anzumachen.

Die Fehler sind hauptsächlich auf die Unzulänglichkeiten der Spiele Engines zurückzuführen.

Bei NV Karten kann es sein, dass dort die Fehler nicht sichtbar sind, da die tw. vor einem schwarzen Hintergrund rendern. Die weissen Pixelfehler wären halt schwrz, und dementsprechend nicht mehr so sichtbar...

Das Flackern bei Mafia liegt am Pfusch der Gamedesigner. 2 Polygone streiten sich um denselben Platz. (Z-Fighting) Vielleicht kanns hier helfen, den W-Buffer zu aktivieren (mittles rTool z.B.)

Warcraft 3, Simsons H&R, Mafia und GTA3 sollten eigentlich mit 6xAA noch schnell genug sein. Bei Medal of Honor würd' ich 4xAA nehmen. Bei Halo funktioniert ohne 'ini' Hack (der aber manche Shader niocht mer rendert) AA leider nicht.

[Coda]

Die nVidia Karten haben einen höhere subpixel accuracy und deshalb ist dort das Problem weniger sichtbar.

Das Problem tritt nur dann auf wenn die Designer sogenannte T-Juncs in den Models übriglassen, d.h ein polygon das an einer kante vorbeigeht (siehe den Simpsons Screenshot)
Normalerweiße müsste man dann aus dem Polygon 2 machen, damit der Fehler nicht auftritt.

Das Flackern bei Mafia liegt am Pfusch der Gamedesigner. 2 Polygone streiten sich um denselben Platz. (Z-Fighting) Vielleicht kanns hier helfen, den W-Buffer zu aktivieren (mittles rTool z.B.)
W-Buffer ist Müll.

[Mr. Lolman]

Original geschrieben von Coda
W-Buffer ist Müll.

Sorgt der nicht für einen lineareren Wertebereich in der Z-Ebene?

[Coda]

W-Buffer ist ein bischen wie z-bias, das funktioniert mal und manchmal nicht.
Auf nVidia Karten funktionierte früher auch Cube Mapping nicht mehr, ich weiß nicht ob das inzw. gelöst ist
ATi Hardware unterstützt AFAIK gar keinen W-Buffer mehr.

Sorgt der nicht für einen lineareren Wertebereich in der Z-Ebene?
Der Depthbuffer darf überhaupt nicht linear sein. Die Präzision nimmt mit der Entfernung ab, sonst würde sie in der Nähe nicht genügen.

[Blutgrätsche]

Zuluman, weisst du eigentlich, dass du da ein anspruchsvolles Tech-Thema ausgegraben hast? Und Crushi, der andere Thread ist tatsächlich voller Müll.

Für Polygaps und Z-Fighting können sowohl Software (Engine, Geometrie-Model) als auch Hardware (Chip, Treiber) verantwortlich sein.

Ich bewege mich hier jetzt auf dünnem Eis, aber meines Wissens ist bei HW-Problemen (besonders die Polygap-Fehler) die Rechengenauigkeit nicht wirklich das Problem, entgegen (älteren) renomierten Aussagen, die das Gegenteil behaupten. Das Problem sollte aber inzwischen auf HW-Seite durch eine sorgfältige mathematische Lösung behoben worden sein.

[Zulumann]

@Blutgrätsche:
Nein, wusste ich nicht. ;)
Ich hoffe, das dies hier nicht auch in so einen sinnlosen Flamethread wie der oben verlinkte ausartet.
Ich bitte deshalb um eine sachliche Diskussion.

Im Grunde genommen will ich nur wissen, ob diese Fehler an einem Defekt meiner Grafikkarte liegen, oder, falls ersteres nicht zutrifft, wie man diese störenden Fehler softwaremäßig (Treiber, Tweaks, Patches, ...) beseitigen kann.
Und falls auch dies nicht möglich sein sollte, würde ich gerne wissen, warum dieselben Probleme bei anderen (sowohl nVidia- als auch ATI-User) scheinbar nicht auftreten. ->siehe meinen Thread auf computerbase.de (http://www.computerbase.de/forum/showthread.php?t=70032)


@Mr. Lolman
AA und W-Buffer hilft leider nicht. Und bei GTA3 kann ich sowieso nur mit max. 2xAA spielen (ohne Framelimiter) sonst ruckelts zu arg. Leider läuft GTA3 wesentlich schlechter als Vice City, das kann ich mit 4xAA-16xAF fast ruckelfrei spielen. Finde ich sehr schade, da GTA3 ohne diese Kinderkrankheiten wirklich ein Top-Spiel wäre. :(


Daß nVidia hinsichtlich der Polygaps besser geeignet ist, kann ich so auch nicht bestätigen (siehe auch den oben erwähnten Flamethread). Ich hatte mit einer FX5600 bei GTA3 genausoviele "weiße Linien" wie mit meiner Radeon 9800Pro. In anderen Spielen kann's aber wieder anders aussehen.


Original geschrieben von Blutgrätsche
Das Problem sollte aber inzwischen auf HW-Seite durch eine sorgfältige mathematische Lösung behoben worden sein.
Meinst du damit die neuen Karten wie X800Pro oder Geforce 6800? Tritt das Problem damit nichtmehr auf?

[Jesus]

also wenn du GTA 3 nur mit 2xAA spielen kannst bei deinem System dann stimmt ganz bestimmt was nicht bei deinen Treibern

[StefanV]

Original geschrieben von Zulumann
Die Fehler müssten sich irgendwie beseitgen lassen, da andere diese Probleme (egal ob mit ATI- oder nVidia-Karten)scheinbar nicht haben.
Wer weiß Rat?


Danke
Zulumann

Kill die Programmierer, die habens vergeigt.

Diese Polygaps sind meist auch nur dann wirklich sichtbar, wenn man drauf achtet (was man bei ATi HW stärker tut als bie nV :eyes: ).

Ganz ab davon sind meist die Gamedesigner schuld, die die Modelle nicht ganz richtig zusammenkleben...

PS: auch ein gutes Beispiel für Polygaps ist z.B. Luigis Mansion...
Aufm Gamecube...

[winter]

Die Polygaps hatte ich bei GTA3 manchmal, interessanterweise anscheinend abhängig vom Graka-treiber, ich erinnermich nicht mehr, um welche Version es da konkret ging... Ich benutze eine TI4200.
Das Texturflackern kenne ich seit Unreal, und es kam bei fast jedem OpenGL Game (und interessanterweise nur da) vor. ich habe nie herausgefunden woran das lag...

[Piffan]

Original geschrieben von winter
Die Polygaps hatte ich bei GTA3 manchmal, interessanterweise anscheinend abhängig vom Graka-treiber, ich erinnermich nicht mehr, um welche Version es da konkret ging... Ich benutze eine TI4200.
Das Texturflackern kenne ich seit Unreal, und es kam bei fast jedem OpenGL Game (und interessanterweise nur da) vor. ich habe nie herausgefunden woran das lag...

Wahrscheinlich in OpenGl nur in 16bit Farbtiefe gezockt. Dann ist nämlich der Z-Buffer auch nur in 16bit afaik. Mir fiel es besonders bei Rune auf, weil ich eine Herkules MX zum Zocken hatte, die bei 32bit nicht wirklich schnell war.

Wie sich ein fehlender Z-Buffer auswirkt, konnte man früher gut bei Tombraider sehen. Bevor die Voodoo dieses Spiel beschleunigte und dann auch ein Z-Buffer genutzt wurde, flackerten da die Texturen um die Wette....

[mictasm]

Also diese unglaublich flackernden Texturen bei Mafia habe ich auch mit meiner 5700U. An vielen Stellen.

Und wenn ich mich richtig an GTA3 erinnere, hatte ich dort auch manchmal diese Streifen. (TI 4200)

Generell würde ich sagen, dass es fast immer an der Gameengine oder der mangelnden Sorgfalt der Spieledesigner liegt. Aber da gibt es viele Beispiele. Wenn man z.B. bei Mafia über die große Brücke fährt, sind die Begrenzungen nur 1 Pixel tief (nur die Textur). Das sieht einfach dämlich aus. Wenn man es als Rechteckprofil aufgebaut hätte, wäre es viel natürlicher.

Gruß,

MIC

[tokugawa]

Original geschrieben von mictasm
Also diese unglaublich flackernden Texturen bei Mafia habe ich auch mit meiner 5700U. An vielen Stellen.

Und wenn ich mich richtig an GTA3 erinnere, hatte ich dort auch manchmal diese Streifen. (TI 4200)

Generell würde ich sagen, dass es fast immer an der Gameengine oder der mangelnden Sorgfalt der Spieledesigner liegt. Aber da gibt es viele Beispiele. Wenn man z.B. bei Mafia über die große Brücke fährt, sind die Begrenzungen nur 1 Pixel tief (nur die Textur). Das sieht einfach dämlich aus. Wenn man es als Rechteckprofil aufgebaut hätte, wäre es viel natürlicher.


Das ist nicht vergleichbar. Alphatexturen sind halt üblich, wenn man Polygone sparen möchte. Sind vielleicht nicht schön, aber sie funktionieren und sind eine halt eine Vereinfachung.

T-Vertices (also wenn ein Vertex entlang einer Kante eines benachbarten Dreiecks liegt), auch T-Junctions genannt, sind echte Fehler, die entweder am Modeller (wenn er schlampt und eben keine "waterproof" Models erstellt) oder an der Engine generell (etwa bei LOD-Algorithmen) liegen. Das Problem läßt sich eigentlich relativ leicht lösen, während Z-Fighting teilweise auch einfach ein Präzisionsproblem sein kann, und ein Image-Space Z Offset da helfen kann oder nicht... aber das so einzustellen dass es passt ist echt ziemlich ein "Schmerz im Hintern" (Z-Fighting kann leider in ziemlich vielen Fällen auftreten, da Situationen, wo zwei Flächen relativ "eng" aufeinander kleben, recht oft vorkommen, etwa bei Decals, oder bei Shadowmaps).

[Zulumann]

Original geschrieben von Jesus
also wenn du GTA 3 nur mit 2xAA spielen kannst bei deinem System dann stimmt ganz bestimmt was nicht bei deinen Treibern
Wüßte nicht, was an meinem System nicht stimmt, hab normale 3DMark2001SE- (ca. 16500) und 3DMark03-Ergebnisse (5495).
GTA3 läuft ja die meiste Zeit auch flüssig, aber ruckelt halt immer wieder an den gleichen Stellen. Wenn ich mehr als 2xAA einstelle, dann ruckelt's eben an noch mehr Stellen.
Dafür hasse ich die Programmierer, daß sie dieses geniale Spiel so schlampig umgesetzt haben. :(
Vice City läuft dagegen um längen besser (auch wenn ich hier das Problem mit den spätladenden Texturen habe).

Original geschrieben von Stefan Payne
Diese Polygaps sind meist auch nur dann wirklich sichtbar, wenn man drauf achtet (was man bei ATi HW stärker tut als bie nV :eyes: ).

Aber in GTA3 sind diese Polygaps wirklich extrem, die kann man eigentlich gar nicht übersehen.

Original geschrieben von tokugawa
Das Problem läßt sich eigentlich relativ leicht lösen, während Z-Fighting teilweise auch einfach ein Präzisionsproblem sein kann, und ein Image-Space Z Offset da helfen kann oder nicht... aber das so einzustellen dass es passt ist echt ziemlich ein "Schmerz im Hintern" (Z-Fighting kann leider in ziemlich vielen Fällen auftreten, da Situationen, wo zwei Flächen relativ "eng" aufeinander kleben, recht oft vorkommen, etwa bei Decals, oder bei Shadowmaps).
Genau, das Z-Fighting tritt bei mir oft bei Decals (z.B. Blut bei MOHAA) und "Shadowmaps" auf (siehe flackernder Regalschatten von Vice City).
Ich kann mich erinnern, daß ich dieses Z-Fighting auf meinem alten P2 350Mhz (mit Voodoo2) bei den Decals von Counter-Strike/Half-Life hatte. Damals ließ sich das ganz einfach durch einen Befehl in der Konsole lösen. Der Befehl verschob sozusagen das Decal einfach ein wenig von der anderen Textur weg und schon war die Welt wieder in Ordnung.

Kann man dies bei den "Z-Fighting"-Spielen nicht auch irgendwie machen? Vielleicht ne ini-Datei ändern oder durch Konsolenbefehle?

[Gast]

Den selben Fehler wie der Threadersteller hatte ich sowohl mit einer Radeon 9500 nonPro, Radeon 9500 nonPro @ 9700, Radeon 9800 Pro und Radeon 9800 XT. Wenn man die 3DMark 01 Demo auf hohen Details spielt gibt es übrigens Schattengeflackere pur.

[Aquaschaf]

Original geschrieben von Zulumann

Vice City läuft dagegen um längen besser (auch wenn ich hier das Problem mit den spätladenden Texturen habe).



Schalte den Framelimiter ein, dann gibts keine Probleme mit den Texturen.

[Zulumann]

Original geschrieben von Aquaschaf
Schalte den Framelimiter ein, dann gibts keine Probleme mit den Texturen.
Nee, 30FPS sind mir nicht flüssig genug. ;)

Bei anderen lässt sich das mit dem Kompatiblitätsmodus (Wi98/Me) beheben. Bei mir funktionierte das nur bei GTA3, bei Vice City komischerweise nicht.


An alle Radeon (9800Pro) Besitzer:
Wer von euch hat die oben genannten Probleme (Polygaps + Z-Fighting) nicht? Bitte genau hinschauen. ;)

[Coda]

Wieso sollte das jemand nicht haben? Das ist eine Hardwarelimitierung.

[Blutgrätsche]

Vorab: Zuluman, ich kann dir bei deinem Problem auch nicht helfen. Wenn Spiele-Entwickler Mist bauen, kann man selten was dagegen tun.

Vor einigen Jahren gab es (glaube ich) in den Treiber-Einstellungen eine Option, Polygap-Fehler zu minimieren. Die Einstellung hat aber wohl nur versucht Software-Fehler zu beheben. Polygap-Fehler in HW sollten eigentlich schon seit einigen Jahren nicht mehr auftreten. Trotzdem kann es natürlich sein, dass dasselbe Spiel auf der einen HW Fehler zeigt und auf der anderen nicht, ohne dass der Chip damit fehlerhaft sein muss. Wie bereits gesagt, Polygap-Fehler sind heutzutage mehr als unnötig.

Auch die üblichen Z-Fighting-Fehler (übereinanderliegende Polygone) kann man in Software verhindern, erfordert allerdings ggf. etwas mehr Aufwand. Meines Wissens ist ein konstanter Z-Offset schon längst überholt, da nur ein steigungsabhängiger Faktor das Problem beseitigt. Man kann es natürlich auch auf andere Weise ohne Z-Offset (z.B. Kombinationen aus Multitexturing, identischen Polygonen, Clipping-Planes, Texture-Kill oder Texture-Austausch) hinbekommen.

Für andere, sehr seltene Z-Fighting-Probleme (durchschneidende Polygone) gibt es meines Wissens keine brauchbaren Software-Lösungen. Hier entscheidet dann endgültig die Z-Buffer Genauigkeit, wobei eine höhere Genauigkeit die Fehlerwahrscheinlichkeit nur verringert, jedoch nicht sicher beseitigt (und damit nach meiner Ansicht kein wirkliches Genauigkeitsproblem darstellt). Wichtig ist vielleicht noch, dass der Z-Buffer zwar 24 oder 32 Bit Speicherplatz beansprucht, aber die Z-Interpolation muss nicht unbedingt 24 oder 32 Bit effektive Z-Buffer-Genauigkeit sicherstellen (andere Unterschiede wie FP-Formate oder W-Interpolation mal aussen vor gelassen).

[Zulumann]

Original geschrieben von Coda
Wieso sollte das jemand nicht haben? Das ist eine Hardwarelimitierung.
Weil manche Leute in anderen Foren behaupten, sie hätten diese Fehler nicht, mit der gleichen Grafikkarte.

[Blaire]

Original geschrieben von Zulumann
Nee, 30FPS sind mir nicht flüssig genug. ;)

Bei anderen lässt sich das mit dem Kompatiblitätsmodus (Wi98/Me) beheben. Bei mir funktionierte das nur bei GTA3, bei Vice City komischerweise nicht.


An alle Radeon (9800Pro) Besitzer:
Wer von euch hat die oben genannten Probleme (Polygaps + Z-Fighting) nicht? Bitte genau hinschauen. ;)

Ich kenne sie nur allzu gut.
Quake3,Farcry,Callof Duty sowie Comanche4 um nur einige Beispiele zu nennen.
Hatte Radeon 8500,9700Pro sowie 9800Pro und bei allen Karten war es der Fall.
Bei meiner jetzigen 6800 Ultra hab ich noch keine gesehn. Beim 3D Mark 03 gleich beim Flugzeugtest waren die Konturen des Flugzeugs mit schwarzen Linien übersäht. Das ist bei der Geforce 6800 nicht mehr der Fall.
Man hat bis heute keine Lösung dafür gefunden oder man sieht es als normal an, was es aber meiner Meinung nach nicht ist.

MfG

[q@e]

Meint ihr sowas?
Mal mehr, mal weniger stark ausgeprägt?

http://home.arcor.de/quasat/3DC-Pics/a_proe01Full.png
http://home.arcor.de/quasat/3DC-Pics/b_proe01Full.png

[Blaire]

So ähnlich kann man sagen. Wer den Comanche4 Benchmark kennt, der sollte ihn mal durchlaufen lassen und ganz am Ende wenn der Tanker versinkt auf das Meer achten. Dort blitzen kurz weisse Punkte oder Linien auf.

MfG

[ow]

Original geschrieben von q@e
Meint ihr sowas?
Mal mehr, mal weniger stark ausgeprägt?



Oben ATi, unten NV?

[Demirug]

Alle Jahre wieder?

Das Thema hatten wir doch schon öfter?

Das ganze ist eine Folge von unterschiedlicher Subpixel Precision im Rasterisierer. nVidia nutzt da verschwenderische 12 Bits. Bei ATI weiss man es nicht so genau weil die Kanadier AFAIK dazu keine Angaben machen. Aber wer den Sparfimmel von ATI kennt...

[ow]

Original geschrieben von Demirug
Alle Jahre wieder?

Das Thema hatten wir doch schon öfter?

Das ganze ist eine Folge von unterschiedlicher Subpixel Precision im Rasterisierer. nVidia nutzt da verschwenderische 12 Bits. Bei ATI weiss man es nicht so genau weil die Kanadier AFAIK dazu keine Angaben machen. Aber wer den Sparfimmel von ATI kennt...

Der ATi Treiber meldet 4 Bits für OpenGL SUbpixle precision.

[Blaire]

Original geschrieben von ow
Der ATi Treiber meldet 4 Bits für OpenGL SUbpixle precision.

Sehr interessant. Und genau bei OpenGL Quake3 Engines fielen sie mir häufiger auf diese weissen Striche oder Linien.
Kann es sein daß Ati damit Performance einspart?

MfG

[Demirug]

Original geschrieben von Blaire
Sehr interessant. Und genau bei OpenGL Quake3 Engines fielen sie mir häufiger auf diese weissen Striche oder Linien.
Kann es sein daß Ati damit Performance einspart?

MfG

Nein, Transitoren. ATI ist ja bekannt dafür bei der Rechengenauigkeit zu knausern.

[Coda]

Wobei subpixel accuracy bei Spielen eigentlich egal sein sollte wenn man die Geometrie richtig erstellt.

Weil egal wie hoch die accuracy ist wird man durch t-juncs immer Fehler haben.

[Aquaschaf]

Original geschrieben von Zulumann
Nee, 30FPS sind mir nicht flüssig genug. ;)


Die 30FPS hat man dafür aber auch wirklich konstant, wenn man sich nicht die ganze Zeit schnell um die eigene Achse dreht wirkt das IMO schon flüssig genug... abgesehen davon, dass es mit den spät aufpoppenden Texturen beschissen ausschaut ;)

[zeckensack]

Warum koplanare Polygone stinken (http://www.zeckensack.de/misc/coplanar.zip)

Das hat auch garantiert nichts mit der verwendeten Grafikkarte zu tun. Krasse Artefakte sind garantiert.
Die Ansicht rechts zeigt, dass es auch besser geht, und in Drahtgitteransicht ("W") wird auch erkennbar wie es besser geht.

[Tigerchen]

Original geschrieben von Demirug
Alle Jahre wieder?

Das Thema hatten wir doch schon öfter?

Das ganze ist eine Folge von unterschiedlicher Subpixel Precision im Rasterisierer. nVidia nutzt da verschwenderische 12 Bits. Bei ATI weiss man es nicht so genau weil die Kanadier AFAIK dazu keine Angaben machen. Aber wer den Sparfimmel von ATI kennt...


Leider reichen die vielen nV-Bits auch nicht. Hab auch mit der GF3 oft genug PolyGaps gesehen.

Gibt aber auch einen Haufen Spiele ohne diese Fehler , selbst bei ATI. Also ist daß wohl vermeidbar.

[Piffan]

Original geschrieben von Demirug
Nein, Transitoren. ATI ist ja bekannt dafür bei der Rechengenauigkeit zu knausern.

Allgemein oder bezogen auf diesen Punkt?

Polygaps kenne ich übrigens auch von der GF3. Also scheint die höhere Genauigkeit keinen absoluten Schutz zu gewähren.

[Demirug]

Original geschrieben von Piffan
Allgemein oder bezogen auf diesen Punkt?

Bei den linearen Filterstufen ist es ja das gleiche.

Polygaps kenne ich übrigens auch von der GF3. Also scheint die höhere Genauigkeit keinen absoluten Schutz zu gewähren.

Die GF3 hat AFIAK nur 4 Bit Genauigkeit. Die 12 Bit wurden auf jeden Fall erst mit den FXen eingeführt. Zudem wenn die Geometrie Löcher zwischen den Polys hat nützt die beste Rechengenauigkeit nichts.

[Blutgrätsche]

Original geschrieben von Coda
Wobei subpixel accuracy bei Spielen eigentlich egal sein sollte wenn man die Geometrie richtig erstellt.Die Subpixel-Genauigkeit als Kriterium zu nehmem, um Löcher zwischen Polygonen zu erklären, halte ich ebenfalls für ziemlichen Unsinn. Ohne wasserdichte Gegenargumente bleibe ich auch erst mal bei dieser (vielleicht etwas harten) Aussage. Die Subpixel-Bits sagen weder etwas über den verwendeten Algorithmus aus noch über die interne Rechengenauigkeit.

Die Motivation, 12 Bits anzubieten, bleibt mir ebenfalls schleierhaft.

Original geschrieben von Coda
Weil egal wie hoch die accuracy ist wird man durch t-juncs immer Fehler haben. Je nach Verfahren und Rechengenauigkeit können auch fehlerhafte Modelle "zufällig" korrekt oder weniger oft falsch gerendert werden. Ist aber IMO ein recht sinnloses Unterfangen, weil es Fehler nicht grundsätzlich ausschliesst bzw. ausschliessen kann.

[Piffan]

Original geschrieben von Blutgrätsche
Die Subpixel-Genauigkeit als Kriterium zu nehmem, um Löcher zwischen Polygonen zu erklären, halte ich ebenfalls für ziemlichen Unsinn. Ohne wasserdichte Gegenargumente bleibe ich auch erst mal bei dieser (vielleicht etwas harten) Aussage. Die Subpixel-Bits sagen weder etwas über den verwendeten Algorithmus aus noch über die interne Rechengenauigkeit.

Die Motivation, 12 Bits anzubieten, bleibt mir ebenfalls schleierhaft.

Je nach Verfahren und Rechengenauigkeit können auch fehlerhafte Modelle "zufällig" korrekt oder weniger oft falsch gerendert werden. Ist aber IMO ein recht sinnloses Unterfangen, weil es Fehler nicht grundsätzlich ausschliesst bzw. ausschliessen kann.

Nachdem mir in KOTOR in einigen Szenen weiße Linien auffielen, werde ich noch mal mit der GF4 probieren, die afaik 8bit Subpixel- Genauigkeit hat.
Die höhere Subpixel- Genauigkeit der NV- Hardware wurde damals nicht zuletzt mit der professionellen Nutzbarkeit (3D- CAD)begründet. NV hat sich ja schon früh auf diesem Sektor engagiert. Angeblich brauchen komplexere Modelle auch höhere Präzision. Sogar die c't hat mal sowas zum Besten gegeben.
Da kann ich als Laie ja nur "glauben".

Wahrscheinlich liegt die Wahrheit wie immer in der Mitte: Es wird Spiele geben, die auf NV und Ati- Hardware Gaps zeigen, aber wohl auch Beispiele, wo es bei Ati mehr auffällt. So ganz für die Katz werden die 8 bzw. 12 bit wohl nicht sein. Zumal es ein Wert ist, mit dem man auf dem Karton nicht protzen kann oder sonstwie DAU- Fang betreiben kann.

[zeckensack]

Will sich niemand zu meinem Progrämmli (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1954068#post1954068) äussern? ;(

[Blutgrätsche]

Original geschrieben von Piffan
Angeblich brauchen komplexere Modelle auch höhere Präzision. Sogar die c't hat mal sowas zum Besten gegeben.
Da kann ich als Laie ja nur "glauben".Die Subpixel-Bits sagen aus, wie exakt man das Modell reproduzieren kann (auch bei sehr hohen Auflösungen mit evtl. mehreren virtuellen Ansichten). Ohne Grund wird es NV ja nicht gemacht haben, nur hat das nichts mit Fehlern oder deren Vermeidung zu tun.

Original geschrieben von Piffan
Wahrscheinlich liegt die Wahrheit wie immer in der Mitte: Es wird Spiele geben, die auf NV und Ati- Hardware Gaps zeigen, aber wohl auch Beispiele, wo es bei Ati mehr auffällt. So ganz für die Katz werden die 8 bzw. 12 bit wohl nicht sein. Zumal es ein Wert ist, mit dem man auf dem Karton nicht protzen kann oder sonstwie DAU- Fang betreiben kann.Bei einer solchen Argumentation kann ich auch einfach aufgeben dagegen zu halten. Ist zwar nicht nett gesagt, aber richtig und notwendig.

[Blutgrätsche]

Original geschrieben von zeckensack
Will sich niemand zu meinem Progrämmli (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1954068#post1954068) äussern? ;( An diese schicke Lösung hatte ich noch gar nicht gedacht. Schönes Posting.=) (Für das Shadow-Buffer Verfahren allerdings ungeeignet.)

[Piffan]

Original geschrieben von Blutgrätsche
Bei einer solchen Argumentation kann ich auch einfach aufgeben dagegen zu halten. Ist zwar nicht nett gesagt, aber richtig und notwendig.

Tschulligung für meine Unkenntnisse. Nochmal: Ich rede hier nur über die Gaps, über feine Striche oder Pünktchen, die mir "Lücken" zwischen den Polygonen zeigen. Und da wurde und wird von vielen gesagt, dass diese Lücken hardware-abhängig sind (zu ungenaue Subpixel) und andere sagen das Gegenteil, dass die Modelle schlampig sind und die Fehler nichts mit der Hardware zu tun haben.

Sind doch ziemlich kräftige Pole, oder nicht? Wieso ist meine Vermutung schlecht, dass sowohl als auch stimmen könnte?
Wie auch immer, bei Kotor habe ich zwischen einer Radeon 9700 und einer GF4 Ti4200 verglichen. Dabei habe ich Gaps bei beiden Karten gefunden, logischerweise an identischen Stellen. Aber die Gaps bei der NV waren wesentlich schmaler und schwer zu finden, bei der Ati springen sie gelegentlich ins Auge.
Für mich ist daher die Frage nach der "Schuld" klar beantwortet: Die Ursache für die von mir beorbachteten Gaps bei KOTOR liegt wohl klar am Spiel selbst, aber wenn ich nicht spinne, dann gibts noch graduelle Unterschiede zwischen der GF4 und der Radeon. :ratlos:

[aths]

Original geschrieben von zeckensack
Will sich niemand zu meinem Progrämmli (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1954068#post1954068) äussern? ;( Hast fein gemacht, zecki.

Und auf NV40: Flicker, flacker, Hühnerkacker ...

[q@e]

Auf R9600SE ebenfalls.
Default flackert das linke (coplanare?) Gebilde, im Wireframe dagegen überlagern im rechten Gebilde random blue pixels das gelbe Dreieck.

[zeckensack]

Original geschrieben von q@e
Auf R9600SE ebenfalls.
Default flackert das linke (coplanare?) Gebilde, im Wireframe dagegen überlagern im rechten Gebilde random blue pixels das gelbe Dreieck. Ya. Dass die Wireframe-Ansicht ebenso unter z fighting leidet ist ein Nebeneffekt, der nicht speziell erwünscht war ... jedenfalls ist es kein Grund zur Sorge. Das ganze soll ja nur zeigen, wie die Geometrie strukturiert werden muss, damit bei "normalem" Rendering keine Artefakte auftreten.

Kurz gesagt ist "Drübermalen" verboten. Auch wenn von der Mathematik her beide Flächen auf der gleichen Ebene liegen.

Der viel zitierte "painter's algorithm" ist für 3D-Grafik unpraktikabel, und sollte IMO viel seltener zitiert werden ;)

Zufüg0r:
"Koplanar" ist schon der richtige Begriff (Genus Geometricus Mathematipeng). Will meinen dass zwei (oder mehr) Flächen in der gleichen Ebene liegen.

Man könnte auch sagen "parallel und Abstand=0", aber dann müsste man die für diesen Kontext anzuwendende Definition von "Abstand" beilegen :zunge:

[MadManniMan]

Original geschrieben von zeckensack
Kurz gesagt ist "Drübermalen" verboten. Auch wenn von der Mathematik her beide Flächen auf der gleichen Ebene liegen.


Ui, dann will ich nicht die Geometrie bei Doom3 sehen ?-) j/k

[zeckensack]

Original geschrieben von MadManniMan
Ui, dann will ich nicht die Geometrie bei Doom3 sehen ?-) j/k Okay, war ein bisserl unpräzise formuliert ("kurz gesagt"<=>Lüge für Kinder). Bei exakt gleichen Eckpunktpositionen ist Drübermalen erlaubt, und nennt sich dann "multipass rendering" ?-) j/k
:bäh:

Das Problem z fighting tritt immer dann auf, wenn man zwei Sachen übereinandermalt, die eigentlich wahrhaftig koplanar sind, aber wo man dies uneigentlich nicht garantieren kann -- Stichwort begrenzte Algebra-Tauglichkeit von handelsüblichen Gleitkommazahlen.

[Gast]

Original geschrieben von zeckensack
Okay, war ein bisserl unpräzise formuliert ("kurz gesagt"<=>Lüge für Kinder). Bei exakt gleichen Eckpunktpositionen ist Drübermalen erlaubt, und nennt sich dann "multipass rendering" ?-) j/k
:bäh:

Das Problem z fighting tritt immer dann auf, wenn man zwei Sachen übereinandermalt, die eigentlich wahrhaftig koplanar sind, aber wo man dies uneigentlich nicht garantieren kann -- Stichwort begrenzte Algebra-Tauglichkeit von handelsüblichen Gleitkommazahlen.

Werden beim Multipass nicht die Farben geblendet? Dann kann es doch kein Flackern geben. :kratz:

[Piffan]

Der Gast war ich.

Noch mal zu den Gaps: Liege ich nun mit meinen laienhaften Vorstellungen richtig oder nicht?
Was mir auffällt ist die Polarität der Aussagen von Leuten, die es wohl wissen sollten.

[Piffan]

Original geschrieben von Gast
Werden beim Multipass nicht die Farben geblendet? Dann kann es doch kein Flackern geben. :kratz:

Da fällt mir ein, dass bei UTK2003 manchmal die Schattentexturen flackern, und zwar bei sehr flachem Blickwinkel....Also sind die Schattentexturen eher nicht koplanar, aber recht dicht übereinander. Oder so.

[Xmas]

Original geschrieben von Gast
Werden beim Multipass nicht die Farben geblendet? Dann kann es doch kein Flackern geben. :kratz:
Es könnte Flackern geben, wenn das darüber gemalte Polygon an manchen Stellen als "verdeckt" behandelt wird. Aber da bei normalem Multipass Rendering die Geometrie identisch ist, bekommt man auch die identischen Z-Werte und benutzt dann als Vergleichsfunktion EQUAL.


zeckensack,
das Programm ist ja schön und gut, nur bringt das nichts bei Decal-"Flicken" mit Blending (Einschusslöcher, etc.), da man dort drübermalen muss.

[Blutgrätsche]

@piffan
Kleine Entschuldigung für meine etwas harsche Antwort. Zur Klarstellung:
Frage: Ist die Anzahl der Subpixel-Bits wichtig bei korrekter Geometrie?
Antwort: Nein.
F: Ist die Anzahl der Subpixel-Bits wichtig bei inkorrekter Geometrie?
A: Offensichtlich.
F: Rendert NV (da mehr Subpixel-Bits) inkorrekte Geometrie "besser" als ATI?
A: Ja.
F: War das von NV beabsichtigt?
A: Wohl kaum.
F: Kann man ATI daraus einen Strick drehen?
A: Nein.
F: Wenn mir das aber wichtig ist, sollte ich dann eher zu NV greifen?
A: Ja.

@Xmas
Die Polygone müssen natürlich unterteilt werden bevor man den Hintergrund überhaupt rendert.

[zeckensack]

Original geschrieben von Piffan
Werden beim Multipass nicht die Farben geblendet?IdR ja. Wenn die vorherigen passes bereits eine Farbe erzeugt haben, würde man diese einfach überschreiben/ersetzen, wenn man nicht blendet. Dann hätte man sich das auch schenken können.
Dann kann es doch kein Flackern geben. :kratz: Doch, kann es. Das hat auch nichts mit der Farbe zu tun, sondern mit dem Inhalt des Z Buffers.

Wenn der zweite Pass nicht exakt die gleichen Z-Werte liefert wie der erste Pass, dann bekommt man die gleiche Sorte Artefakte. XMas hat ja schon geschrieben, dass man das vermeiden kann, indem man die exakt gleichen Geometriepositionen benutzt (Farbe und Texturkoordinaten kann man gefahrlos variieren).

Das ist bei "richtigem" Multipassing auch keine grosse Herausforderung :)

Und nochmal siehe XMas: "Decals" (zB das orange Dreieck in meinem Artefakt-Erzeuger ;)) sind problematisch, weil die drübegemalte Geometrie von Hause aus andere Eckpunktpositionen hat.

Original geschrieben von Piffan
Noch mal zu den Gaps: Liege ich nun mit meinen laienhaften Vorstellungen richtig oder nicht?Polygaps bekommt man "am besten" durch "T junctions". Ich habe auch schon an einem kleinen Progrämmli dafür geschraubt, leider will es mir noch nicht so recht gelingen, deutliche Artefakte zu erzeugen.
Vielleicht mache ich später noch ein Bild, das wenigstens erklärt was eine "T junction" ist.

Ansonsten siehe Blutgrätsche.
Was mir auffällt ist die Polarität der Aussagen von Leuten, die es wohl wissen sollten.Was meinst du damit? ?(

[zeckensack]

Original geschrieben von Xmas
zeckensack,
das Programm ist ja schön und gut, nur bringt das nichts bei Decal-"Flicken" mit Blending (Einschusslöcher, etc.), da man dort drübermalen muss. Es gibt ja auch noch PolygonOffset ...
Das Primärziel des Programms war es erstmal zu demonstrieren, dass z fighting prinzipiell alle IHVs betrifft, und keine Hardware-Unzulänglichkeit, sondern ein lösbares* Applikationsproblem ist. Damit keiner daherkommt und behauptet sowas gäbe es nur bei ATI-Karten, wie das ja gerne getan wird ...

*Ist natürlich auch eine Frage des Aufwands, aber ein bisschen Mühe sollten sich Entwickler IMO schon geben.

[zeckensack]

Original geschrieben von Piffan
Da fällt mir ein, dass bei UTK2003 manchmal die Schattentexturen flackern, und zwar bei sehr flachem Blickwinkel....Also sind die Schattentexturen eher nicht koplanar, aber recht dicht übereinander. Oder so. :D
Die Schatten sollen koplanar sein, dh sie sollen exakt auf dem Fussboden zu liegen kommen.

Rechenbeispiel mit zwei koplanaren Geraden:
Gerade "A" stehe stellvertretend für den Fussboden. Sie soll durch die 2D-Punkte (0;5) und (9;2) verlaufen.
Gerade "B" stehe stellvertretend für das "Decal", bzw den Schlagschatten. Verläuft durch die Punkte (3;4) und (6;3) verlaufen.Wenn du jetzt mal ein Geodreieck und ein Blatt Papier hernimmst, wirst du festellen, dass die zwei Geraden gleich sind ("koplanar"). Die Stützpunkte sind unterschiedlich, aber die Punkte dazwischen (und darüberhinaus) sind deckungsgleich.

Welche y-Koordinate gehört zu x-Koordinate 5? Gerade A:
Geradengleichung ist y=5-3*(x/9)
y(x=5)=
5-3*5/9=
5-(15/9)=
(45/9)-(15/9)=
(30/9)=
(10/3)
Gerade B:
Geradengleichung ist y=4-((x-3)/3)
y(x=5)=
4-((5-3)/2)=
4-(2/3)=
(12/3)-(2/3)=
(10/3)

qed

Das ganze Problem bei der Geschichte ist, dass das nur theoretische Geometrie ist, und die Hardware nur mit begrenzter Präzision arbeitet. Rundungsfehler treten immer wieder zwischendurch auf, und deswegen sind die von der Hardware errechneten Werte nicht genau deckungsgleich. Insbesondere schleift die Hardware keine mathematischen Terme durch, noch dazu mit Brüchen, sondern eben nur Zahlen, die im intern benutzten Format irgendwie darstellbar sind.

Ich bau jetzt mal einen klitzekleinen Fehler bei den Divisionen ein ... dadurch werde ich auch die Brüche los.
Gerade A:
Geradengleichung ist y=5-3*(x/9):=5-0,33*x
y(x=5)=
5-5*0,33=
5-1,65=
3,35
Gerade B:
Geradengleichung ist y=4-((x-3)/3):=4-(x-3)*0,33
y(x=5)=
4-(5-3)*0,33=
4-2*0,33=
4-0,66=
3,34

3,35=3,34?

[Gast]

Original geschrieben von zeckensack
:D
Die Schatten sollen koplanar sein, dh sie sollen exakt auf dem Fussboden zu liegen kommen.



Ja was jetzt, ich hab gedacht koplanar=flackern=böse

MfG

[zeckensack]

Original geschrieben von Gast
Ja was jetzt, ich hab gedacht koplanar=flackern=böse

MfG Genau so ist's ja auch.
Sie sollen koplanar sein, aber weil der Grafikchip nur mit endlicher Präzision rechnet, sind sie es letztendlich nicht. Deswegen flackern die Schatten in UT, und deswegen sind koplanare Polygone in 3D-Grafik generell shice.


Nur um's nochmal zusammenfassend zu formulieren ...
Zwischen zwei Dreiecken gibt's folgende mögliche Beziehungen:
1)Parallel. Spezialfälle davon:
1.1)koplanar. Spezialfälle:
1.1.1)keine Berührung - unproblematisch
1.1.2)Berührung nur an einer Kante. Spezialfälle:
1.1.1.1)Gemeinsame Kante wird erzeugt durch exakt gleiche
Eckpunkte - unproblematisch
1.1.1.2)Gemeinsame Kante wird erzeugt durch abweichende
Eckpunkte (andere Anzahl oder (kleine) Abweichungen
der Positionen) - problematisch
=> führt zu "poly gaps"
1.1.3)Schnitt. Spezialfälle:
1.1.3.1)exakt deckungsgleich - unproblematisch
1.1.3.2)nicht exakt deckungsgleich - problematisch
=>führt zu "z fighting"
1.2)nicht koplanar - unproblematisch

2)nicht parallel. Spezialfälle:
2.1)keine Berührung - unproblematisch
2.2)Berührung nur an einer Kante. Spezialfälle:
2.2.1)Gemeinsame Kante wird erzeugt durch exakt gleiche
Eckpunkte - unproblematisch
2.2.2)Gemeinsame Kante wird erzeugt durch abweichende
Eckpunkte (andere Anzahl oder (kleine) Abweichungen
der Positionen) - problematisch
=> führt zu "poly gaps"
2.3)Schnitt - unproblematisch (Ausnahme: Matrox' FAA)

Ich hoffe jetzt sind alle Unklarheiten ausgeräumt :)

[zeckensack]

"T junction"

Im Anhang links. Rechts ist die vernünftige Version.

[Blutgrätsche]

Original geschrieben von zeckensack
2.3)Schnitt - unproblematisch (Ausnahme: Matrox' FAA)Nur eine kleine Ergänzung: Fast coplanare Polygone, die sich schneiden (Schnitt unter sehr flachen Winkeln), zeigen ebenfalls z-fighting. Die Z-Steigungen in X- und Y-Richtung müssen dabei ungleich Null sein, sonst funktioniert es wieder. (Edit: Vielleicht muss auch ein Vorzeichen unterschiedlich sein :kratz2: )

[Gast]

Original geschrieben von zeckensack
Genau so ist's ja auch.
Sie sollen koplanar sein, aber weil der Grafikchip nur mit endlicher Präzision rechnet, sind sie es letztendlich nicht. Deswegen flackern die Schatten in UT, und deswegen sind koplanare Polygone in 3D-Grafik generell shice.



Ja eben also WIE soll man Schatten, Decals usw. implementieren:
1) Koplanar: "richtig", aber führt zu flackern
2) Nicht koplanar (mit z-offset o.ä.): nicht "richtig" decals "schweben" über der fläche -> auch nicht ideal

falls es doch noch eine 3. möglichkeit gibt mich bitte darauf hinzuweisen :)

MfG

p.s: man kann doch auch nicht jedes mal das poly auf dem man das decal haben will aufsplitten...

[tokugawa]

Original geschrieben von Gast
Ja eben also WIE soll man Schatten, Decals usw. implementieren:
1) Koplanar: "richtig", aber führt zu flackern
2) Nicht koplanar (mit z-offset o.ä.): nicht "richtig" decals "schweben" über der fläche -> auch nicht ideal

falls es doch noch eine 3. möglichkeit gibt mich bitte darauf hinzuweisen :)

MfG

p.s: man kann doch auch nicht jedes mal das poly auf dem man das decal haben will aufsplitten...

Das Z-Offset bedeutet nicht, dass das Decal über der anderen Fläche schwebt da Z-Offset ein Z-Offset im Image-Space, nicht im World-Space ist. Es wird also parallel zur Blickrichtung im Image-Space "versetzt". Von da her würde man hier, wenn man die zwei koplanaren FLächen von der Seite sieht, jene doch auch koplanar aussehen.