Ave!

Da es leider kaum Demos zum Thema Shadow (mapping sowie andere Schattenmethode) für OpenGL und Delphi gibt, hab ich mir gestern mal ein wenig Zeit genommen und ein Shadowmapping-Programm von <a href='http://www.codesampler.com' target='_blank'>http://www.codesampler.com</a> nach Delphi konvertiert.

Es erstellt mittels eine Pixelpuffers eine Tiefentextur aus Sicht der Lichtquelle und projeziert diese dann auf die komplette Szene, so daß die Geometrie ohne großen Aufwand mitschattiert wird.Durch die Schattenprojektion schattieren sich die Objekte natürlich auch selbst.

Leider ist das nur ne recht simple Demo, und es gibt je nach Position der Lichtquelle Probleme bei der Schattendarstellung (im Originalprogramm ist dies leider auch der Fall).Ich werde mich in nächster Zeit aber wohl mit der Portierung eines Shadowmapping-Programmes aus der nVidia-Entwicklersektion auseinandersetzen, das diese Probleme nicht hat.

Allerdings gibt diese Demo (die natürlich mit Quellcode kommt) einen guten Einblick in die Funktion des Shadowmapping.
Den Download gibts hier : <a href='http://www.delphigl.de/files/shadowmap.zip' target='_blank'>http://www.delphigl.de/files/shadowmap.zip</a> (~250KByte)
Der Quellcode ist recht aufergäumt, und ich hab mir beim Kommentieren recht viel Mühe gegeben.


Als Schmankerl hier noch ein Screenshot (animiert sieht das Ganze natürlich noch besser aus) :

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hi,

der Screenshot sieht klasse aus. Leider kommt unter einer GF4MX zu folgender Fehlerndermeldung:

wglBindTexImageARB(PBuffer.Handle, WGL_DEPTH_COMPONENT_NV)

Gruß
KidPaddle

_________________
http://www.seban.de

Auf deiner GF4 MX440 wirds leider nix mit der Demo, da sie die Hardware Schattenfähigkeiten von Grafikkarten der GF3/4/FX-Klasse nutzt, die von der GF4MX natürlich nicht unterstützt werden, da diese noch auf der GF2-Architektur basiert.

Damit die Demo korrekt funktioniert, muß die Grafikkarte die GL_SGIX_depth_texture-Erweiterung unterstützen.Wie auf folgendem Link : <a href='http://www.delphi3d.net/hardware/extsupport.php?extension=GL_SGIX_depth_texture' target='_blank'>http://www.delphi3d.net/hardware/extsuppor...X_depth_texture</a> zu sehen, tun das leider nicht sehr viele Grafikkarten.

das ist nunmal das Problem mit der Implementation neuer Techniken.Entweder man lässt Personen mit älterer Hardware aussen vor (schlechte Idee), oder man programmiert verschiedene Renderpfade (für ne kleine Demo allerdings leider oft viel zu aufwendig).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Kein Problem, war eher als Hinweis für andere gedacht, da Du darauf hingewiesen hast, das Karten von anderen Hersteller Probleme machten könnten.

KidPaddle

_________________
http://www.seban.de

löppt und sieht klasse aus - der erste blick in den Code war auch erfreulich. Wie du schon sagtest sehr aufgeräumt und vorallem gut kommentiert. Ich werd mir bei Gelegenheit mal die passenden dokus rauskramen und das ganze in Ruhe durchgehen. Sieht so aus als ließe sich daran bequem viel lernen
Schönen Dank!

_________________
Selber Denken macht klug!

ich kann es leider nicht anschauen (nur ne geforce ddr im rechner, vielleicht später auf dem von meinem bruder, der hat ne geforce4 drin soweit ich weiß..), aber der screenshot sieht spitze aus

_________________
http://www.rochus.net

Ich hatte mir das auch mal angesehen. Und muss sagen bei mir funzt das genau so wenig wie auf der gf4mx von KidPaddle. Und das obwohl ich mir erst eine neue Radeon 9500 Pro gekauft habe.

Ich hatte auch mal geschaut und festgestellt, dass diese Karte eine GL_ARB_depth_textur unterstützt. Weiß jemand wo die Unterschiede liegen und wäre es dann nicht eventuell praktischer diese zu verwenden? Weil das ja nun wirklich Klasse aussieht und nicht unbedingt von Nachteil wäre, wenn es auf mehr Karten gehen würde.

Hab mir grade mal die Infos zur GL_ARB_DEPTH_TEXTURE angesehen ( <a href='http://oss.sgi.com/projects/ogl-sample/registry/ARB/depth_texture.txt' target='_blank'>http://oss.sgi.com/projects/ogl-sample/reg...pth_texture.txt</a> ), und es scheint so als sei dies eine Erweiterung der im Demo genutzten GL_SGIX_depth_texture-Extension.

Rein theoretisch müsste sich das Demo also ohne Probleme auf diese Extension portieren lassen.Ich werds mal probieren, und dann ggf. bei Erfolg ne neue Version hochladen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich hab die Demo jetzt auf die neue Extension umgeschrieben, so dass neben GeForce 3/4/FX nun auch Besitzer von Radeon9500/9700-Karten auf ihre Kosten kommen sollten.
(Mehr Infos zur Unterstützung von GL_ARB_DEPTH_TEXTURE : <a href='http://www.delphi3d.net/hardware/extsupport.php?extension=GL_ARB_depth_texture' target='_blank'>http://www.delphi3d.net/hardware/extsuppor...B_depth_texture</a> )

Allerdings hab ich in der neuen Version vom PixelPuffer Abstand genommen und bin auf simples Rendern in eine Textur umgestiegen, da der PixelPuffer auch auf einige nVidia-spezifische Extensions im Bezuf auf die Tiefentextur aufsetzte, für die ich auf die schnelle keine allgemeinen Extensions gefunden habe.

Positiver Nebeneffekt : Im Demo kann man jetzt mittels der Taste "t" die Größe der Tiefentextur zur Laufzeit verändern (Nachteil von RenderToTexture : Wenn der Viewport kleiner als die Textur ist, gibts Darstellungsprobleme).Außerdem kann man nun etwas mehr bei der Anzeige der Tiefentextur erkennen.Der Link ist immernoch der selbe!

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Funktioniert wunderbar. B)
Echt klasse.

Schatten sind geil, und besonders wenn sie so einfach zu implementieren sind...ich kann jedem von euch diese Methode der Schattendarstellung nur ans Herz legen.Ich hab nämlich grad wieder ein wenig rumgespielt, und ein 3D-Modell mit recht vielen Polygonen in meine Shadowmap-Demo geladen.Der Unterschied zwischen unschattierter und schattierter Szene ist gewaltig, und Performancetechnisch gibts dank Hardwarebeschleunigung selbst bei der recht hohen Polygonzahl des Modells (12k) keinen großen Unterschied.

Auf den folgenden zwei Screenshots könnt ihr euch mal nen Eindruck machen, welchen Unterschied die Schatten machen (Klicken um zu Vergrößern) :
<a href='http://www.delphigl.de/misc/shadowmap_off.jpg' target='_blank'></a> <a href='http://www.delphigl.de/misc/shadowmap_on.jpg' target='_blank'></a>


P.S. : Hat jemand von euch schonmal andere Schattentechniken implementiert (ausser Shadowmaps und projezierte Schatten via Stencilpuffer)?

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

In Mcad 2.0 stehen zwei Arten von Shadow Volumes zur Verfügung (bin mir jetzt aber nicht sicher, ob die bei dir auch unter "projezierte Schatten" fallen - eigentlich sind sie es jedoch nicht, da nicht die Projektion auf eine bestimmte Ebene berechnete wird) : die "Normalen" Stencil Shadows (der Umriß des Körpers aus der Perspektive der Lichtquelle wird in Richtung der Lichstrahlen extrudiert) und Carmacks Reverse (funktioniert ähnlich, benötigt aber mehr Geometriedaten - dafür kann auch der Betrachter im Schatten stehen - was sonst schwierig zu implementieren ist).

Mit Tiefentexturen habe ich leider keine Erfahrung (ich vermeide die Verwendung von Extensions, die nicht in der OpenGL Standardspezifikation vorhanden sind), macht hier die Position des Betrachters eigentlich Probleme ?

Das Problem mit Shadow Volumes ist, dass man verflixt aufpassen muss, diese nicht zu zeichnen, wenn der Schatten eigentlich nicht sichtbar wäre (z.B. Schattenwerfendes Objekt hinter einer Tür in einem Raum - sonst wird die dickste Mauer auf einmal papierdünn B) . Wer Morrowind gespielt hat, wird das Problem sicher kennen. Ansonsten sind sie cool und machen auch keine Probleme (z.B. kann man eine Lichtquelle in eine Laterne hineinstellen - und die Geometrie an den Ecken wirft tatsächlich in alle Richtungen Schatten. (Der Ritter auf dem Mcad 2.0 Demoscreenshot ist ein Beispiel für ein Shadow Volume).
Stencil Shadows haben übrigens den Vorteil, dass man "realistische Schatten" werfen könnte - soll heißen, die Schattenflächen werden nicht einfach nur abgedunkelt, sondern man zeichnet die Szene mehrmals - einmal mit Licht, dann Schatten in den StencilBuffer, dann nochmals ohne Licht - und lässt die Szene ohne Licht nur dort durchscheinen, wo es der Stencilbuffer erlaubt (für mehrere Lichtquellen braucht man dann dementsprechend mehr Renderdurchläufe).

Das größte Problem ist eigentlich, den Umriß eines komplexen Objektes aus der Sicht der Lichtquelle zu finden - und das sollte man schon, theoretisch könnte man zwar die einzelnen Polygone extrudieren - dann wirds aber extrem langsam.
Shadow Volumes kann man übrigens leicht optimieren, indem das Mesh des Schattenwerfenden Objektes weniger komplex ist, als das des gezeichneten Objektes.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Carmack's Methode ist mir auch ein Begriff, zumal ich darüber einiges in den entsprechenden nVidia-Dokumenten gelesen hab.Allerdings haben mich sowohl der recht große mathematisch Aufwand als auch die Sache mit der Schilouttenfindung abgeschreckt.Wenn ich allerdings irgendwann den Drang verspüre, mich mit dieser Schattenmethode zu befassen, werd ich dazu vielleicht auch ne kleine Demo schreiben...


Eigentlich sollten sich Tiefentexturen auch ohne Extensions wie z.B. GL_ARB_DEPTH_TEXTURE umsetzten lassen.Dann allerdings weder hardwarebeschleunigt noch so einfach wie das mit der entsprechenden Extension der Fall ist.Der Vorteil ist natürlich die recht einfache Implementierung, sowie die Tatsache das man (im Gegensatz zu Schattenvolumen) keine Ahnung von der Szenegeometrie haben muß und die Projektion auch von der Grafikkarte mittels glTexGen erledigen lässt.Mathematische Kenntnisse werden für diese Methode deshalb auch kaum gebraucht.
Auch das Positionieren des Betrachters "innerhalb" eines Schattens (da die Tiefentextur ja projeziert wird, gibts in dem Sinne kein innerhalb) macht bei dieser Methode keine Probleme.
Weiterer Vorteil : Man braucht die Schattentextur für die statische Geometrie nur einmal zu generieren, und muss dann später nur noch die Schatten für dynamische Objekte generieren.Bei Schattenvolumen findet eine Berechnung ja AFAIK in jedem Frame für die komplette Geometrie stat.

Nachteile sind die Tatsache, das Texturenspeicher doch recht wertvoll ist, und die Performance natürlich mit steigender Auflösung der Tiefentextur sinkt.Probleme gibts (meiner Erfahrung nach, allerdings hab ich mich noch nicht nach einem Ausweg ausgesehen) wenn die Lichtquelle zu nah an ein Objekt gerät, so dass dieses teilweise ausserhalb des Lichtfrustums liegt.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

So kompliziert sind StencilShadows eigentlich auch nicht - obwohl ich zugeben muss, dass ich einige Stunden brauchte, bis ich wirklich verstanden hatte, was da eigentlich passiert (besonders Carmacks Reverse verblüffte mich Anfangs, bis ich dann einen Artikel von ihm zum fünften oder zehnten Mal las - und dann endlich kapierte, dass er eigentlich nur die logischen Operationen mehrerer Stencildurchläufe zusammenfasst, was die ganze Zeit klar und deutlich dagestanden wäre).

Die Silhouette zu finden ist auch nicht so schlimm: man verwaltet zu jedem Polygon die den Kanten angrenzenden Flächen - ist das Polygon (aus der Sicht der Lichtquelle) sichtbar, die angrenzende Fläche unsichtbar, so ist die Kante Teil der Silhouette und muss extrudiert werden.

Es hat mich dann doch in den Fingern gejuckt, ein kleines Demo zu Schattenvolumen zusammenzustellen - ich habs in der Projektsektion unter Mcad 2.0 abgelegt. Ich nehme aber an, dass viele Leute, die selber Engines entwickeln, dennoch froh wären, wenn du ein eigenes Demo erstellst, da sie sich sonst den ShadowVolume spezifischen Code aus der Ogl Bibliothek zusammenklauben müssten (was eigentlich eh den Lizenzbestimmungen widerspricht, mir aber relativ egal ist).

Hier ein Vorgeschmack:


Das Demo läuft auf jeder OpenGL Implementation ab Version 1.1 (theoretisch also auch mit den Microsoft Software Treibern und "braucht" also nicht mal einen 3D-Beschleuniger).

Übrigens könnten ShadowVolumes für statische Geometrie ebenfalls vorberechnet und z.B. in einer DisplayList abgelegt werden - allerdings nur, solange sich die Position der Lichtquelle nicht ändert - weswegen ich für statische Objekte dann doch stark zu einer Shadowmap tendieren würde (der verbratene Texturspeicher stört mich dabei ja nicht mal so sehr - eher die verlorene Texureinheit, von denen haben ja sogar viele moderne Consumerkarten nur zwei oder drei Stück).
Der bessere Weg zum Optimieren ist daher in meinen Augen die Reduktion der Schnittpunktdaten der schattenwerfenden Modelle: da das Mesh ohnehin bekannt sein muss, ist das ja nicht das große Problem und kann im Voraus berechnet werden.
Da das ganze ShadowVolume eh nur im Stencilbuffer gezeichnet wird (keine Farbwerte, Farbinterpolation, Texturkoordinaten, Normalvektoren, Z-Werte), ist der FillRate Overhead auch nicht so riesengroß (aber natürlich da).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Hab mir deine ShadowVolume-Demo angesehen, und fand sie recht interessant...Vorteil dieser Methode ist halt die Tatsache, das dafür weder ne extra Textureneinheit verbraten wird (das war übrigens das beste Feature an meiner alten KyroII...die konnte 8 Texturen in einem Pass darstellen), noch gibts Probleme, wenn ein schattenwerfendes Objekte außerhalb des Lichtfrustums liegt (soweit ich die Sache zumindest verstanden habe).

Der größte (optische) Nachteil in meinen Augen ist jedoch die Tatsache das eigentlich alle via Stencilpuffer realisierten Schatten scharfkantig sind, und man dies nur mit sehr viel Aufwand und unter großer Grafikkartenlast ändern kann.Bei ner Schadowmap hab ich ja meine Textur, die ich dann recht einfach manipulieren kann und so schnell (ohne die Geometrie mehrmals zeichnen zu müssen) weiche Schatten erstellen kann.


P.S. : Ich schraub grad ne eigene Klasse zusammen, die ShadowMaps einfach nutzbar macht...wenn Ineresse besteht kann ich dir dann die entsprechende Unit zukommen lassen, damit du ShadowMaps evtl. im nächsten MCAD-Release implementieren kannst.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)