Hallo,

Mein nächstes Problem. Ich habe einen Quader, der sich durch eine teilweise transparente Textur bewegt. Damit nicht entweder die komplette Textur vor oder hinter dem Quader ist, muss ich dazu den Tiefentest anlassen. Dadurch fangen meine Texturen das flackern an.
Wie löst man so etwas elegant in OGL?

Wenn du zu erst den Quader zeihnest und dann mit Tiefentest das Transparente objekt sollte es keine Probleme geben, da die Textur teilweise beschnitten wäre. Also vom Tiefentest.

Vorrausgesetzt ich habe dein Problem richtig verstanden. Da bin ich mir nämlich gerade nicht so sicher. Bin heute nicht so ganz Aufnahmefähig.

Zur Not häng mal nen Bild an. Das ist eigentlich immer eindeutig.

Hier einmal ein Bild.

Die Quader sind besagte Quader. Das Weisse und das Graue sind die beiden teils transparenten Texturen (soll einen Drehscheibe sein) und diese flackern. Ich zeichne bereits erst die Quader und dann die beiden Objekte.

Ich glaube ich hab den Fehler gefunden. Ich hatte ColorBits auf 32 und Z-Buffer auf 24 stehen. Wenn ich beide auf 0 in CreateRenderingContext setze, ist das flackern fast weg. Vermutlich hat er einfach zu lange gebraucht zum Umrechnen.

zu früh gefreut - jetzt bekomme ich streifen in der Textur (siehe Bild)

Öhm...Ich glaube das solltest du dringend wieder umändern. Weil Colorbits sagt wieviele Bits benutzt werden um Farben darzustellen. 32 = 4*8 = RGBA. Und durch die 0 Beim Z-Buffer hast du den Tiefenpuffer unbrauchbar gemacht. Theoretisch(!) würde es jetzt aich nix mehr bringen den Tiefentest zu aktivieren, weil ja jetzt pro Pixel 0 Tiefeninformationen gespeichert sind.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

also, ich hab mittlerweile mit beiden Werten gespielt. Das verhalten hängt eigentlich nur an den Tiefenbufferbitwerten. Ich hatte gedacht 0 bei beiden Einstellungen könnte die default bzw. Desktop-Werte nehmen (da ich im Fenster render). Colorbits hab ich wieder auf 32, und wenn ich Tiefenbuffer auf 16 stelle, bekomme ich die oben gezeigten Streifen. Setz ich ihn auf 24 flackern komplette Teile der Textur.

Da kann ich dir nicht ganz zustimmen. Diese Angaben sind nur ein Vorschlag für den Grafiktreiber. Er kann sich auch darüber hinwegsetzen und die ein ganz anderes verpassen. Als Colorbuffer bekommst du eigentlich grundsätzlich immer das was im Windows eingestellt ist. Ich habe es auch gerade mal mit 0 / 0 und 16 / 8 (Color / Depth) Ausprobiert und habe immer 5 zurückbekommen. Also 32 / 24. Das muss aber nicht immer so seit. Die Wahrscheinlichkeit dafür ist aber rechthoch. Ich meine auf älteren Karten ließ sich so auch die Aufläsung des Z-Buffers beinflussen. Es bietet sich aber an sinnvolle oder gewünschte Werte dafür anzugeben. Eben um auch wenig Interpretationsreiheit für den Treiber zu lassen.

Zu dem Problem. Das sieht fast aus wie ZFighting. Fast. Besteht diese Drehscheibe aus zwei Quads? Wenn du mit LEQUAL als Tiefentest arbeitest dann sollte es eigentlich nicht passieren. Da diese wirklich 100%tig aufeinander liegen werden die dann auch so gezeichnet. Aber ich befürchte ohne Code wird das auch nichts. So ist das mehr oder weniger nur ne Rateaktion.

dem kann abgeholfen werden.

Wird für den Frame aufgerufen wenn er erstellt wird.


die Passende SetupGL:


Die Quader:

wobei renderEinheitsWuerfel(true) einen Würfel mit Kantenlänge 1 zentriert um (0,0,0) rendert. True bedeutet, dass noch ein Rahmen dazugezeichnet wird.

Die Scheiben:

renderQuad -> zentrierter EinheitsQuad um (0,0,0) in der x-z-Ebene

fTexture und fNegativTexture sind glBitmaps von Lossey (danke dafür).

Um es nicht zu vergessen: nearClip ist 1, farClip ist 50

Danke - ZFighting war der richtige Tip!

ich hab den Code hier auf folgendes geändert:



und es funktioniert!

Dann scheinen sich also bei der Rotation auch minimalste Abweichungen einzuschleichen.

Evtl könntest du da auch mit PolygonOffset arbeiten.

Was meinst du mit den Abweichungen?

btw, das spannende an der Sache ist - wenn ich keine Quader durch die Texturen laufen lasse, wird das ganze ohne Flackern gerendert.

Abweichung. Na ja. Wenn du die Punkte direkt übereinander legst, dann stimmen alle texel der Fläche mit der darunterliegenden überein. Wenn du jetzt aber die eine Fläche rotierst dann muss OpenGL ja die Ecken (Vetices) rortieren und dann sollten sie normal auch alle die Selbe Tiefe haben. Das scheint aber nicht der Fall zu sein, da sie sonst ja nicht nach hintengeschoben werden würde. Und die Änderung an deinem Code spricht eigentlich auch dafür, dass dort beim Rotieren die Fläche wohl minimal nach hinten gesetzt wurde.

Danke auf jeden Fall für die Hilfe und die Erklärung.

Das mit der Abweichung ist eher nur ne Vermutung.