spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hab die Engine.cpp nochmal geupdated, die Render-Methode ist nun besser strukturiert und kommentiert.
http://dl.dropbox.com/u/12845003/ShadowTest.zip

omg, es funktioniert endlich! Ich kanns kaum glauben xD
Folgender fießer Fehler war dran Schuld:

sollte eigentlich

heißen.

Danke für eure Hilfe!

Zitat von »David Scherfgen«

Cool
Aber eigentlich hast du dir ja selbst geholfen
Zeig doch nochmal einen Screenshot!

ok, da hast du recht
Dann aber auf jeden Fall danke für eure Hilfsbereitschaft

Hier mal noch die 2 Test-Szenarios mit nun funktionierenden (aber noch ungefilterten) Schatten:





Falls ich Zeit finde, werde ich vielleicht mal noch ein Tutorial zu diesem Thema verfassen.

Zitat von »David Scherfgen«

Nice
Ich wollte auch immer mal Cube-Shadow-Maps implementieren.
Planst du auch selektive Updates einzelner Faces, z.B. wenn sich nur in einer Richtung etwas verändert, was ein neues Rendern der Shadow-Map erfordern würde?

Hab ich noch nicht wirklich drüber nachgedacht. Für Lichter mit statischen Positionen könnte sich das ja durchaus lohnen.

Da ich voraussichtlich eine statische Map mit dynamischen Entitäten verwenden werde, könnte man eventuell für die Lichter die im View-Frustum liegen checken ob sich Positionen/Richtungen der Entitäten die innerhalb der Licht-View-Frustas (Frusten, Frusti?) liegen sich verändert haben, und nur die Flächen wo sich Objekte verändert haben neuberechnen.

Oder eventuell die Depthmaps der statischen Map bei der Initialisierung berechnen und bei jedem Frame über diese Ausgangsdepthmaps die dynamischen Entitäten drüberrendern. Dabei könnte man eventuell noch die Entitäten aussortieren, die nicht im Lichtfrustum liegen und nicht in den Octree-Zellen liegen die im PVS der Licht-Zelle sind.

Ich überlege mir im Moment ob es nicht vielleicht ne Möglichkeit gibt die Shadowcubemap in nur einem Pass zu berechnen. Da man aufgrund der OpenGL-Rasterisierung nicht so in eine Cubemap rendern kann wie man daraus liest (also mit Richtungsvektor) kann man nicht einfach die Projektionsmatrix weglassen und gl_Position auf den Richtungsvektor von Licht zu Fragment setzen, aber eventuell kann man eine 2D-Textur nehmen und irgendwie die Richtungsvektoren in 2D-Koordinaten umrechnen ohne das Koordinaten verschwendet werden oder doppelt vorkommen. Mal genauer drüber nachdenken...

Zitat von »David Scherfgen«

Das würde ich mir auch wünschen (direktes Rendern in eine Cube-Map).
Es gibt die Möglichkeit, mit Geometry Shadern zumindest jedes Dreieck nur einmal an die Karte schicken zu müssen, im Prinzip ist das nur 1 Pass. Im Shader musst du dann schauen, welche Faces ein Dreieck abdeckt.

Hab ich auch schon von gelesen, allerdings hat man immer noch 6 Pässe beim Fragmentshader, was glaub ich das rechenintensivste ist.
Ist die Frage welche Methode effektiver ist, mit der Methode mit Geometry Shader würde man der Lokalität der Vertexdaten entgegenkommen, mit 6 komplett getrennten Pässen würde man eventuell der Lokalität der Cubemap-Textur entgegenkommen (nicht sicher wie diese intern angelegt ist, aber durch die initialisierung würde ich Schätzen dass die im Speicher einfach als 6 2D-Texturen vorzufinden ist).
Ich könnte mir vorstellen, dass die Methode mit Geometry-Shader nochmal etwas schneller ist, da eine Textur sich AFAIK wesentlich besser für Random-Access eignet als der Speicher in dem die Vertex-Daten stehen.

edit: @dot: Danke für die Infos, allerdings schon bekannt