Shadow Volumes mit beliebiger Geometrie, Teil 2

[Kane]

Was die Performance angeht ließe sich diese, besonders bei einer Portalengine,
mit Hilfe von Scissoroptimierungen und ein paar OpenGL Extensions (GL_NV_depth_clamp, GL_EXT_stencil_two_side etc) verbessern.

Die projizierst das was von einem Frustum nachdem es durch ein Portal weiter
begrenzt wurde übrig bleibt auf die Near-Plane und berechnest dir daraus das Scissorrechteck.
Damit kann man erhebliche Mengen Fillrate (was die StencilShadows zu Hauf verbrauchen) einsparen.

[0x00000001]

Sgt. Nukem schrieb:

TGGC schrieb:

0x00000001 schrieb:

Da kann man massig Granaten abfeuern, und alle werfen ihre eigenen Schatten. Auch in großen Räumen geht das ohne größere Framerateeinbrüche.

Aber dabei ist doch nicht jede Granate eine Lichtquelle, oder etwa doch?

AFAIK in der .KKrieger Demo schon. Schließlich entstehen keine runden Schatten...

Ja bei solchen Spielen mit Schatten haben die Granaten jetzt immer Lichter dran. Macht schon was her.

@rapso:

dann muss deine mindestvoraussetzung größer sein als die, die es bei D3 werden wird, also weit über GF3

Tja sieht so aus. Das einzige was mich am Spiele-machen eigentlich so richtig interessiert ist die Grafik, und die soll diesmal schon was werden. Und da ich frühestens in 2-3 Jahren mit einem fertigen Spiel rechne geht das OK.

Das mit den Shadowmaps reizt mich jetzt schon ziemlich, aber jetzt sitze ich zwischen den Expertenstühlen und weiß nicht weiter.

John Carmack schrieb:

[...]Unfortunately, the quality just isn't good enough unless you use extremely
high resolution shadow maps (or possibly many offset passes with a lower
resolution map, although the bias issues become complex), and you need to
tweak the biases and ranges in many scenes. For comparison, Pixar will
commonly use 2k or 4k shadow maps, focused in on a very narrow field of
view (they assume projections outside the map are NOT in shadow, which
works for movie sets but not for architectural walkthroughs), [.....]

Zum Thema gutes Aussehen habe ich was interessantes gefunden, die nenen das "Smoothies".
Rendering Fake Soft Shadows with Smoothies
Das Blöde dabei ist, dass man da auch so ne Art ShadowVolume an jeder Kante erzeugen muss.
Aber das mit dem Bias-Problem macht mir sorgen. Was für Grafikfehler können damit entstehen?

das geht gut, heißt dual parabolid shadowmapping, ein kleines paper dass dich weiterbrächte wäre das.

hehe, ich glaube Du hast die Konjunktive nicht ganz falsch gewählt.
Also da hat man 2 Kreise, auf denen die Umgebung vorne und hinten abgebildet wird. Hm aber dann versteh ich überhaupt nicht wie man da jetzt zu Schatten kommt und wo/wie ich die dann hinrendern muss.

Ich weiß, viele Fragen. Aber Du bist ja auch selbst schuld wenn Du mich unbedingt von meinen tollen SV's abbringen willst

@Kane: Danke, das ist eine gute Idee. Ich quetsche das Frustrum schon in das Portal rein, aber mit dem Scissor-Test sollte dann noch mehr wegfallen.

[TGGC]

Aber wie zeichnest du das denn überhaupt bei 5 Lichter realistisch? Ich meine, du kannst ja nicht einfach alles, was im Schatten irgendeines Lichtes ist dunkel machen. Theoretisch würde ich erstmal Alles in ambient zeichnen. Dann mach ich die SVs für Licht 1, und addiere dann das Licht an den Stellen ohne Schatten. Das fortgeführt würde dann auch mit mehreren Lichtern korrekten Halbschatten usw. ergeben. Aber bei SVs macht man es doch genau anders rum?

Und dieses kkrieger funktioniert auf meinem Rechner leider nicht so ganz. (Oder anders: wenn das so aussehen soll wie bei mir, dann ist es Mist.)

Bye, TGGC \-/

[0x00000001]

TGGC schrieb:

Theoretisch würde ich erstmal Alles in ambient zeichnen. Dann mach ich die SVs für Licht 1, und addiere dann das Licht an den Stellen ohne Schatten. Das fortgeführt würde dann auch mit mehreren Lichtern korrekten Halbschatten usw. ergeben. Aber bei SVs macht man es doch genau anders rum?

Ja genauso wie Du es gesagt hast wird es auch gemacht. Man muss die Schatten nicht unbedingt schwärzen, man kann genausogut nur da rendern wo Licht hinfällt. Das Problem dabei ist, dass man bei nur einem Licht keine Ambientz (?) hat. D.h. die Schatten sind einfach pechschwarz.
A pro pos Ambientes Licht: Schon das Unreal3 Tech-Video gesehen?
12 MB, WMF
Die benutzen da auch erstmal Soft-Shadows und dann noch Spherical Harmonic Lighting. Trotz der miesen Qualität des Videos hat mich das fast umgehauen. Ich denke in 10 Jahren wird es nicht mehr möglich sein ein PC Spiel von einem Foto zu unterscheiden (wenns gut gemacht ist).

Und dieses kkrieger funktioniert auf meinem Rechner leider nicht so ganz. (Oder anders: wenn das so aussehen soll wie bei mir, dann ist es Mist.)

Bei mir funktionieren auch die Schatten nicht richtig (nur bei mir?). Wenn man am Anfang auf den Boden schaut dann sieht man irgendwelche Schatten, man kann aber nicht sagen wo die herkommen. Das hat mich aber ehrlichgesagt richtig gefreut, bin ich wenigstens nicht der einzige der Probleme damit hat Wobei man natürlich auch bedenken muss, dass die bei ihren 96 KB wohl kaum die riesen Algorithmen schreiben konnten um Grafikfehler wegzubekommen.

[rapso]

0x00000001 schrieb:

Das mit den Shadowmaps reizt mich jetzt schon ziemlich, aber jetzt sitze ich zwischen den Expertenstühlen und weiß nicht weiter.

John Carmack schrieb:

[...]Unfortunately, the quality just isn't good enough unless you use extremely
high resolution shadow maps (or possibly many offset passes with a lower
resolution map, although the bias issues become complex), and you need to
tweak the biases and ranges in many scenes. For comparison, Pixar will
commonly use 2k or 4k shadow maps, focused in on a very narrow field of
view (they assume projections outside the map are NOT in shadow, which
works for movie sets but not for architectural walkthroughs), [.....]

schau dir die ATI demo an zu der ich oben verlinkt habe oder das unreal engine NV40 movie (zu dem ich ebenfalls oben verlinkt habe), dann kannst du sehen dass shadowmaps wirklich gute qualität liefern können, mit ps 2.0 kannst du sogar entfernungsabhängiges soften durchführen, schaut sehr gut aus

0x00000001 schrieb:

das geht gut, heißt dual parabolid shadowmapping, ein kleines paper dass dich weiterbrächte wäre das.

hehe, ich glaube Du hast die Konjunktive nicht ganz falsch gewählt.
Also da hat man 2 Kreise, auf denen die Umgebung vorne und hinten abgebildet wird. Hm aber dann versteh ich überhaupt nicht wie man da jetzt zu Schatten kommt und wo/wie ich die dann hinrendern muss.

Ich weiß, viele Fragen. Aber Du bist ja auch selbst schuld wenn Du mich unbedingt von meinen tollen SV's abbringen willst

ich finde SV's auch toll, so simpel und gut aussehend, aber die brauchen extrem viel performance und funktionieren nur auf wirklicher geometrie (ein zaun mit alphatest würde nicht klappen), deswegen hab ich bei mir die SMs eingebaut. bei Dual parabolid mapping, wie der name schon sagt, gibt es zwei parabolid maps. du unterteilst den 'space' in zwei bereiche z.b. auf der z achse in vor und hinter der lichtquelle, davon abhängig zeichnest du dann die negativen vertices auf die eine map die positiven auf die andere map (zwei passes möglicherweise).

die projektion ist ziemlich einfach, du subtrahierst die lichtquellenposition von der vertexposition, die länge des vectors ist der z-value den du schreibst, der normalisierte vector ist (mit mad ,,.5f,.5f) die pixelposition auf die parabolidmap projeziert.

ne demo gibt es hier <--vorsicht, link, nicht wieder übersehen

rapso->greets();

ps. bei shadowmaps kann man mit pixelshadern 3.0 noch ziemlich rumtriksen und die performance fast verdoppeln!

[TGGC]

0x00000001 schrieb:

TGGC schrieb:

Theoretisch würde ich erstmal Alles in ambient zeichnen. Dann mach ich die SVs für Licht 1, und addiere dann das Licht an den Stellen ohne Schatten. Das fortgeführt würde dann auch mit mehreren Lichtern korrekten Halbschatten usw. ergeben. Aber bei SVs macht man es doch genau anders rum?

Ja genauso wie Du es gesagt hast wird es auch gemacht. Man muss die Schatten nicht unbedingt schwärzen, man kann genausogut nur da rendern wo Licht hinfällt. Das Problem dabei ist, dass man bei nur einem Licht keine Ambientz (?) hat.

Würde das aber nicht bedeuten pro Licht wird die gesamte Geometrie nochmal gerendert? Diese Methode erscheint mir jedenfalls sehr viel aufwendiger, denn man muss die Geometrie mindestens 2 mal zeichnen.

Könnte evtl. jemand mal einen _aussagekräftigen_ Screenshot von diesem kkrieger posten? Würde ich gerne mal genau ansehen.

Bye, TGGC \-/

[H.L.T.O]

TGGC schrieb:

Könnte evtl. jemand mal einen _aussagekräftigen_ Screenshot von diesem kkrieger posten? Würde ich gerne mal genau ansehen.

Bye, TGGC \-/

Dieses Problem kann der Poster IMHO selbst lösen. Unter Umständen ist dazu eines der folgenden Hilfsmittel zu nutzen:
- Dokumentation zur benutzen API
- google
- FAQ/Suche dieses Boards
- Debugger
- geringe Mengen Gehirnschmalz

Dieses Posting wurde nicht automatisch generiert sondern per Hand eingefügt. Beschwerden werden trotzdem ignoriert.

Disclaimer: dies ist kein direkter persönlicher Angriff.

cu HLTO

Das musste jetzt sein

Die Seite:
http://www.theprodukkt.com

Screenshots:
http://www.theprodukkt.de/files/kkrieger_snapshots.zip

[TGGC]

Die sind alle verkleinert, da erkennt man nicht wirklich was. Im Thread nebenan, sieht man nur wenigen Schatten ziemlich weit entfernt. Mit aussagekräftig, meine ich sowas wie: fetter Schatten direkt vor der Nase am besten mit 2 Lichtquellen.

Bye, TGGC \-/

[H.L.T.O]

Also ich habe versucht ein paar Screenshots zu machen. Doch das ist sehr schwer. Es läuft alles etwas sehr schnell ab. Doch die Screenshots in der Zip-Datei sehen doch recht gut aus. Du musst das alles noch in Bewegung vorstellen. Ist schon sehr beeindruckend.

http://mitglied.lycos.de/gidxgraphic/temp/kkrieger_scr1.JPG
http://mitglied.lycos.de/gidxgraphic/temp/kkrieger_scr2.JPG

[Sgt. Nukem]

0x00000001 schrieb:

Ich denke in 10 Jahren wird es nicht mehr möglich sein ein PC Spiel von einem Foto zu unterscheiden (wenns gut gemacht ist).

Früher!

0x00000001 schrieb:

TGGC schrieb:

Und dieses kkrieger funktioniert auf meinem Rechner leider nicht so ganz. (Oder anders: wenn das so aussehen soll wie bei mir, dann ist es Mist.)

Bei mir funktionieren auch die Schatten nicht richtig (nur bei mir?). Wenn man am Anfang auf den Boden schaut dann sieht man irgendwelche Schatten, man kann aber nicht sagen wo die herkommen. Das hat mich aber ehrlichgesagt richtig gefreut, bin ich wenigstens nicht der einzige der Probleme damit hat Wobei man natürlich auch bedenken muss, dass die bei ihren 96 KB wohl kaum die riesen Algorithmen schreiben konnten um Grafikfehler wegzubekommen.

Jo, sie schreiben ja auf ihrer Seite, daß die Demo ziemlich buggy ist und sie ein größeres Teil, fehlerfreier und mit mehr Content, irgendwann releasen werden.

BTW: Hab' seit gestern statt 'nem Athlon XP 1800+ / Radeon 9500 Pro einen Athlon 64 3200+ / Radeon 9800 Pro (mit aktualisierten Treibern) und jetzt sieht .KKrieger auch bei mir total scheisse aus! Buggy Schatten... etc. naja!
Macht man nix!

[0x00000001]

Bei mir sind die Texturen viel niedriger aufgelöst als auf den Bildern, und wie gesagt auch das Problem mit den Schatten. Aber egal, wenn Doom3 gut läuft (und das kommt ja recht bald), dann bin ich wunschlos glücklich.

TGGC schrieb:

Würde das aber nicht bedeuten pro Licht wird die gesamte Geometrie nochmal gerendert? Diese Methode erscheint mir jedenfalls sehr viel aufwendiger, denn man muss die Geometrie mindestens 2 mal zeichnen.

Jo, 2x pro Licht ist schon ziemlich bitter, aber in Wirklichkeit ist es noch viel schlimmer . Es sind nämlich 3n + 1 Renderpasses. Einmal wird die ganze Szene ohne Farbe gerendert, um den z-buffer vollzukriegen.
Dann wird für jedes Licht:
- Das Shadow-Volume gerendert
- Die Beleuchtungsstärke in den Alpha-Kanal gerendert
- Die Farbe gerendert

Die letzten beiden Schritte brauchen 6-7 Texturen, deshalb geht es nicht in einem Zug.

rapso schrieb:

vorsicht, link, nicht wieder übersehen

Also ich hab mir alle Deine Links genau angeschaut. Aber den Link auf das Unreal Video hab ich nach dreimaligem Abgrasen Deiner Beiträge immer noch nicht gefunden. Also entweder verwechselst Du grad die Foren oder ich bin bei weitem kurzsichtiger als ich dachte Naja ist ja egal.

ps. bei shadowmaps kann man mit pixelshadern 3.0 noch ziemlich rumtriksen und die performance fast verdoppeln!

Na toll, die Reichen werden noch reicher

Ich habe mich jetzt entschlossen, einfach beide Schattenvarianten mal einzubauen und dann zu schauen. Beide Verfahren haben irgendwie genausoviele Vor- wie Nachteile.

Du sagst zwar, dass die Maps viel schneller sind, aber irgendwie kann ich mir das nicht vorstellen. Ich muss ja, für ein Punktlicht zumindest, ersmal die ganze Szene vom Licht aus zweimal rendern, vorne und hinten. Bei meinen Ansrpüchen brauch ich dazu 2 mal mindestens eine 1024^2 Textur. Dann brauche ich 4 Passes pro Licht, wenn sich das Licht bewegt. Bei statischen Lichtern ist die Technik dann besonders schnell, braucht aber leider viel Speicher. Ich denke, dass ich immer die Shadowmaps rendern und zwischenspeichern werde die gerade gebraucht werden.

Kannst Du mal ein paar Bilder oder sogar eine Demo von dem zeigen was Du da grade mit Schatten machst? Würde mich mal interessieren. Auf Deiner Seite sieht man dazu nix.

[rapso]

0x00000001 schrieb:

Bei mir sind die Texturen viel niedriger aufgelöst als auf den Bildern, und wie gesagt auch das Problem mit den Schatten. Aber egal, wenn Doom3 gut läuft (und das kommt ja recht bald), dann bin ich wunschlos glücklich.

TGGC schrieb:

Würde das aber nicht bedeuten pro Licht wird die gesamte Geometrie nochmal gerendert? Diese Methode erscheint mir jedenfalls sehr viel aufwendiger, denn man muss die Geometrie mindestens 2 mal zeichnen.

Jo, 2x pro Licht ist schon ziemlich bitter, aber in Wirklichkeit ist es noch viel schlimmer . Es sind nämlich 3n + 1 Renderpasses. Einmal wird die ganze Szene ohne Farbe gerendert, um den z-buffer vollzukriegen.
Dann wird für jedes Licht:
- Das Shadow-Volume gerendert
- Die Beleuchtungsstärke in den Alpha-Kanal gerendert
- Die Farbe gerendert

Die letzten beiden Schritte brauchen 6-7 Texturen, deshalb geht es nicht in einem Zug.

heftig, ich komme mit weitaus weniger texturen und passes hin, aber ich spiel auch mit den ps2.0

0x00000001 schrieb:

rapso schrieb:

vorsicht, link, nicht wieder übersehen

Also ich hab mir alle Deine Links genau angeschaut. Aber den Link auf das Unreal Video hab ich nach dreimaligem Abgrasen Deiner Beiträge immer noch nicht gefunden. Also entweder verwechselst Du grad die Foren oder ich bin bei weitem kurzsichtiger als ich dachte Naja ist ja egal.

hmm.... ich hatte den link extra kopiert aber ich find ihn hier auch nicht mehr... hmm... dummheit meinerseits

0x00000001 schrieb:

ps. bei shadowmaps kann man mit pixelshadern 3.0 noch ziemlich rumtriksen und die performance fast verdoppeln!

Na toll, die Reichen werden noch reicher

Ich habe mich jetzt entschlossen, einfach beide Schattenvarianten mal einzubauen und dann zu schauen. Beide Verfahren haben irgendwie genausoviele Vor- wie Nachteile.

Du sagst zwar, dass die Maps viel schneller sind, aber irgendwie kann ich mir das nicht vorstellen. Ich muss ja, für ein Punktlicht zumindest, ersmal die ganze Szene vom Licht aus zweimal rendern, vorne und hinten. Bei meinen Ansrpüchen brauch ich dazu 2 mal mindestens eine 1024^2 Textur. Dann brauche ich 4 Passes pro Licht, wenn sich das Licht bewegt. Bei statischen Lichtern ist die Technik dann besonders schnell, braucht aber leider viel Speicher. Ich denke, dass ich immer die Shadowmaps rendern und zwischenspeichern werde die gerade gebraucht werden.

bei den shadowvolumes mußt du auch die beiden seiten der volumes zeichnen, vom overdraw her ist das also theoretisch gleich, wobei die volumes meißt quer über den bildschirm gehen und sehr viel mehr overdraw produzieren, besonders wenn du die volumes mit carmacks reverse trick schliessen mußt. dagegen ist ne shadowmap recht billig.
zudem möchtest du softshadows, die bekommst du mit 512*512 ziemlich gut hin, schau dir einfach das unreal video an, die arbeiten viel mit shdowmaps, mit ps2.0 kannst du locker 20mal aus den texturen lesen und somit ein wirklich gutes antialiasing herstellen. und ja, vorberechnet hast du da ziemlich viel was du cachen kannst, bei langsammen lichtquellen kannst du auch nur jedes x-te frame die maps generieren.

wobei dein problem wohl am meißten die 'schlechte' graka ist, mit <ps2.0 sind shadowvolumes auf diese weise sehr langsam, da macht man eher erst die beleuchtung, dann die volumes und dann einfach nur ein graues quad über den screen, schaut nicht super aus, aber ausreichend und zudem fixer.

0x00000001 schrieb:

Kannst Du mal ein paar Bilder oder sogar eine Demo von dem zeigen was Du da grade mit Schatten machst? Würde mich mal interessieren. Auf Deiner Seite sieht man dazu nix.

ich bin momentan im urlaub und somit nicht an meinem pc, hier hab ich nichts an eigenem code/screens.

rapso->greets();

[TGGC]

Also zu dem kkrieger nochmal. Anhand der Screenshots hab ich mir mal zusammengereimt, wie es so ungefähr funktionieren müsste. Erstmal ist alles aufgeteilt in die Wände/Boden, und in Säulen/Gegner. Auf ersterem (A) sind die Schatten, zweitere (B) werfen die Schatten. Dann wird das ganze Schattenzeug in ein zweites Rendertarget, welches lediglich 512x256 ist, reingezeichnet. Dort werden also dann nach der Methode von oben die Lichter nacheinander reingehauen. Dabei gibts wohl auch Lichter, die gar keinen Schatten machen (z.b. unten an den Säulen). Bei der Aktion besteht die Geometrie erstmal nur aus A. Da kommt dann 'ne Textur raus, welche die Schatten auf A repräsentiert (z.b. voll Licht=undurchsichtig, kein Licht = durchsichtig). Dann wird A normal gezeichnet, und mit der Textur die Schatten draufgebracht. Zum Schluss wird B und dann noch die Waffe gezeichnet.

Bye, TGGC \-/

[0x00000001]

rapso schrieb:

heftig, ich komme mit weitaus weniger texturen und passes hin, aber ich spiel auch mit den ps2.0

Bei den Anforderungen schreib ich dann hin "Wer Geforce4 oder kleiner benutzt ist selbst schuld."
Ich glaub D3 macht das ziemlich genauso wie ich. Und das macht mir Sorgen. Dann brauch ich 2 Passes pro Licht obwohl meine Graka ja eh schon etwas lahm ist

zudem möchtest du softshadows, die bekommst du mit 512*512 ziemlich gut hin, schau dir einfach das unreal video an, die arbeiten viel mit shdowmaps, mit ps2.0 kannst du locker 20mal aus den texturen lesen und somit ein wirklich gutes antialiasing herstellen.

joa...also das Unreal Video ist jetzt mal ein wirklich überzeugendes Argument für Shadow-Maps (Wenns denn auch welche sind, aber ich denk das hast Du recherchiert.)
Hm Anialiasing der Schatten? Was ich möchte ist folgendes:
In der Nähe des Schattenwerfers soll der Schatten eine harte kante haben, und je weiter weiter man wegkommt desto weicher soll der Schatten sein. Wie schnell das geht sollte von der größe der Lichtquelle abhängig sein.
Ich habe aber noch nichts gefunden was das kann, außer diese Smoothies. Aber die brauchen Kantenberechnung. (An den Modellkanten werden da Quads vom Licht aus gesehen aufgespannt, und die dann in eine 2. Shadowmap gerendert). Geht das auch auf Pixelbasis? Und wenn ja, Link?

So weit es das kommende Semester und anderes Zeugs zulässt werde ich jetzt endlich mal drangehen das Zeugs einzubauen. (Zwischen)Ergebnisse sowie weitere Fragen werden dann hier präsentiert

[rapso]

das ist nicht schwer zu realisieren, du hast pro pixel
-die position im worldspace vom pixel
-position der lichtquelle (ist ja const)
-aus der shadowmap den abstand der lichtquelle in diese richtung zum object (also den zbuffer wert der shadowmap)

nun berechnest du den abstand von lichtquelle zur aktuellen pixelposition, dann teilst das durch den wert aus der shadowmap (nennen wir das mal 'delta')

falls nun der pixel im shatten ist, kannst du im kreis drumherum die entfernungen auslesen, dabei ist der radius des kreises * 'delta' und schon hast du den gewünschten effekt.

du kannst den effekt verbessern indem du den ersten wert aus der shadowmap mittelst aus 4 oder 5 werten die du aus der shadowmap ausließt. das lesen aus der map ist dabei nicht teuer da die pixel ja alle recht nah beieinander liegen und somit im cache sind, du solltest mit 2texeln/takt hinkommen.

den kreis um den schattenpunkt kannst du mit den restlichen freien texturereads bekommen, müßten ca 10 sein.

in pixelshader 3.0 sind da durchaus mehr reads drinne.

das schöne an pixelshader 3.0 ist, dass du am anfang testen kannst ob ein pixel bzw triangle zum pointlight backfacing ist und dafür im pixelshader die berechnung gleich abbrechen, das kann sehr viel performance bringen die für die anderen pixel bleibt. (kann man im vertexshader heutzutage auch schon zum teil machen,aber das ist um einiges aufwendiger weil die geometrie angepasst werden müßte (wie bei den SVs)

rapso->greets();

[TGGC]

Jetzt muss ich aber doch nochmal fragen (denn in dem alten Thread wurde das eigentlich nie beantwortet). Warum kann ich die ZFunc nicht einfach umdrehen? Ich sehe da höchstens ein Problem, wenn die SVs bis hinter die far clipping plane reichen.

Bye, TGGC \-/

[0x00000001]

Ich habe jetzt mal eine Frage zur Implementierung. Und zwar habe ich Probleme mit dem z-Vergleich. Die Shadowmap wird korrekt erzeugt und in den Level zurückprojeziert (mit normaler textur getestet). Wenn ich allerdings die Shadowmap benutze, bleibt der ganze Level schwarz, bis auf einen dünnen Streifen. Dieser Streifen liegt genau "in der Ebene des Lichts", hier mal ein Screen

An was kann das liegen? Muss man etwas bestimmtes bei den Projektionsmatrizen vom Licht und von der Kamera beachten? Darin ist ja jeweils der z-Bereich festgelegt, und ich habe in beiden Matrizen die gleichen Werte angegeben.

Was auch seltsam ist: Wenn ich in die Shadowmap nichts reinrendere, sondern die nur auf 1.0f Clear()e, dann ist nicht etwa alles im Licht, sondern es gibt diesen Grieseleffekt. Ca. die Hälfte der Pixel ist dann zufällig schwarz, die andere Hälfte farbig.

Weiß jemand Rat?

[TGGC]

Ich verstehe nicht so recht, was du mit "Ebene des Lichts" meinst? Für mich sieht das fast so aus, als würden nur noch ein paar Polygone gezeichnet, pixelgenau dürfte der Schatten ja nicht sein.

Bye, TGGC \-/

[0x00000001]

Also die Position des Lichtes ist ein Punkt in der Ebene, und der Normalenvektor der Ebene entspricht dem Richtungsvektor des Lichts.
Der sichtbare Streifen ist aber unabhängig von irgendwelchen Polygonen, hier nochmal ein Bild mit dem Wireframe in grün.

Es scheint so, als ob der ganze z-Bereich in diesen dünnen Streifen gequetscht wird. Dadurch dann wohl auch die Pixelgenauigkeit.

Wie kann ich denn am einfachsten mal testen, ob der z-Buffer der Shadowmap (also die Shadowmap selbst) richtig erzeugt wird? Am besten als schwarzweiß Bild anzeigen lassen. Geht das?

Ansonsten sieht es so aus, als ob mir wieder einige glückliche Stunden mit Rumprobieren bevorstünden. Ist irgendwie jedesmal so, wenn ich was neues mit D3D machen will.... ich hoffe weiterhin auf Ratschläge von Euche.

[rapso]

fang doch mal mit einer einfachereren scene an z.b. zwei planes/boxen, eine kleine auf einer grossen und ne lichtquelle davor.

so ist das echt schwer zu sagen woran es liegen könnte, gibt unheimlich viel was man bei shadowmaps beachten muss und zudem viele implementationsvariationen...

rapso->greets();