Registriert: Di Sep 06, 2005 18:34 Beiträge: 362 Wohnort: Hamburg
Hi ...
Ich habe, seit ich SDL benutze ein Problem mit meinen Stencil-Schatten.
Und zwar flimmern die Schatten seit dem, obwohl ich den Z-Buffer mit 24 Bit initialisiert habe und glDepthFunc(GL_LEQUAL) eingestellt habe.
Das könnte ich umgehen in dem ich statt der ganzen Szene (Bälle und Terrain), nur die Schatten-Volumen als Schattenflächen zeichnen würde, da die ein klein wenig grösser sind als die Bälle selber.
Allerdings beißen sich die Volumes mit dem Nebel. Ich habe heraus gefunden, dass die Nebel berechnung bei Vertexes die mit glVertex4 erstellt sind nicht funktioniert. D.h. egal wie weit weg die Bälle sind, der Schatten ist genau so dunkel wie nah dran, d.h. irgwendwann sieht man nur noch den Schatten und den Ball nicht mehr (egal ob ich nun glHint(GL_FOG_FOG_HINT,GL_NICEST) (pixel-berechnung) aktiviere oder nicht.
Weiß hier jemand ob das normal ist, oder ob das an meiner alten Graka liegt?
Ich könnte das Problem wahrsch. auch mit glPolygonOffset umgehen, allerdings habe ich da irgendwelche Verständnis-Probleme.
Ich weiß nicht genau was die beiden Parameter nun aussagen und wie sich das dann im Endeffekt auswirkt ... kann mir das evtl mal einer genau erklären? Werde da aus dem Wiki irgendwie nicht schlau. Hab damit auch schon rumprobiert, mit dem Erfolg, dass die Schatten ganz verschwunden sind (wahrsch. falsche Parameter, aber welche soll ich nun benutzen???)
Hoffe mir kann da jemand helfen
Gruß
Shai
_________________ Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)
Registriert: Di Sep 06, 2005 18:34 Beiträge: 362 Wohnort: Hamburg
Hi ...
Habs jetzt mit glPolygonOffset geschafft. Hab noch n bissl rum probiert. Mir war nicht klar, dass man da negative Werte einsetzen muss. Funktioniert jetzt aber.
Würd mich aber dennoch über ne genaue Erklärung der beiden Parameter und ihre Folgen freuen ...
Gruß
Shai
_________________ Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Da würden wir uns auch drüber freuen. Das ist ein Befehl, bei dem die meisten nicht wirklich wissen was hinten rauskommt. Du kannst das ja mal wissenschaftlich untersuchen, und uns deine Erfahrungen mittelen. Wäre wirklich nötig.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Der Offset wird dann zum wirklichen Z-Wert addiert.
D.h.
o < 0 => Verschiebung zur Near-Clipping-Plane
o > 0 => Verschiebung zur Far-Clipping-Plane
Im Wiki werden const1 und const2 DZ und r genannt und so beschrieben:
DZ: die Maßeinheit für die Tiefenverschiebung relativ zum Bildschirmbereich des Polygons
r: der kleinste Wert, der garantiert noch eine gültige Verschiebung für die aktuelle OpenGL Implementation liefert
Was das nun genau bedeutet, ist mir nicht ganz klar, aber die Werte sind wohl immer positiv.
Wenn ich jetzt glPolygonOffset(-1,0) verwende (bei meinem oben geschilderten Problem), bekomme ich die Ergebnisse, die ich haben will. Wenn ich aber glPolygonOffset(0,-1) verwende, verändert sich nichts, warum das so ist verstehe ich auch nicht.
Im Gamedev.net-Forum habe ich mir auch einige Beiträge dazu durchgelesen und dort wird davon abgeraten PolygonOffset zu verwenden. Statt dessen wird eine Methode mit einer veränderten Projection-Matrix vorgeschlagen, über die ich jetzt auf die Schnelle aber keine näheren Informationen finden konnte.
Dazu ein Beitrag aus dem Gamedev.net-Forum:
Zitat:
Hi --
There are some performance reasons not to use glPolygonOffset. Since the polygon slope is factored into the actual distance that fragments are moved forward or backward in the z-buffer, fragments inside very steeply sloped (with respect to the camera) polygons can end up having a z value anywhere in the entire depth range. For this reason, hardware hierarchical z-culling algorithms have to be disabled or severely limited for regions in which polygons are rendered with glPolygonOffset turned on.
An alternative is to modify your projection matrix to perform a z-offset. You can read about this technique in Game Programming Gems 1, Section 4.1, or in Mathematics for 3D Game Programming and Computer Graphics, Section 9.1. Source code can be found here:
Diese Technik mit der veränderten Projection-Matrix würde mich mal interessieren, vll hat oder findet dazu ja jemand Informationen ...
Gruß
Shai
_________________ Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)
Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.