Shadow Volumes mit beliebiger Geometrie, Teil 2
-
Hi,
ich möchte hier mal eine Diskussion zu einem Problem anregen, das bei Verwendung von Shadow Volumes auftritt.
Ich habe schonmal danach gefragt, aber da war ich zu schlecht vorbereitet und das eigentliche Thema wurde verfehlt.Das Problem ist, einen Algorithmus zu finden, um von einem beliebigen (Innen)Level ShadowVolumes (SVs) zu erzeugen. Das Hauptproblem dabei ist die Rendergeschwindigkeit.
Ich sag erstmal wie mein Level strukturiert ist:
Grundsätzlich mal ist es eine Portal Engine ( soll ja angeblich modern sein, also hab ichs mal genommen
). Der Level ist in Sektoren aufgeteilt, die untereinander durch Portals verbunden sind.
Jeder Sektor wiederum ist in einem Octree sortiert.Bisher habe ich es so gemacht, dass einfach immer der ganze Sektor zu einem SV wird. Ich verschiebe die Polygone, die vom Licht abgewendet sind, nach hinten und die anderen lasse ich einfach wo sie sind. An den 'Knickstellen' werden dann noch Rechtecke eingefügt, die die beiden Teile miteinander verbinden. So entsteht ein schönes, geschlossenes SV wie man es für die Z-Fail Methode braucht.
Jetzt gibt es aber 2 Probleme:
1. langsam. Vor allem, wenn sich in einem großen Raum irgendwo in der Ecke eine kleine Funzel befindet. Da werden dann die Schatten für den ganzen Raum berechnet obwohl sie nur in einer Ecke nötig wären.
2. An den Sektorgrenzen hat das SV jeweils ein Loch, was zu Grafikfehlern führt.Wie kann man diese beiden Probleme lösen?
Folgendes habe ich mir überlegt, scheint mir aber nicht sonderlich gut zu sein:
Von jedem Octree-Blatt, das in Reichweite des Lichts ist, nimmt man die Polygone, und erstellt daraus ein oder mehrere SV (je Nachdem ob die Polygone überhaupt zusammenhängen). Es muss dabei so erstellt werden, dass es unabhängig von anderen Octree-Teilen funtkioniert. Man kann ja vorher nicht wissen, welche und wieviele Blätter vom Licht beeinflusst werden.
Das Hauptproblem dabei ist wohl, dass da dann viele Flächen doppelt vorkommen. Und das geht bitter an die Füllrate.Wäre schön, wenn Ihr dazu eine Idee habt und die dann auch noch aufschreiben könntet.
-
0x00000001 schrieb:
1. langsam. Vor allem, wenn sich in einem großen Raum irgendwo in der Ecke eine kleine Funzel befindet. Da werden dann die Schatten für den ganzen Raum berechnet obwohl sie nur in einer Ecke nötig wären.
das ist der grund weshalb D3 maximal 2 schatten werfende lichtquellen hat, meißt nur eine und ein paar statisch projezierte schadowmaps.
0x00000001 schrieb:
2. An den Sektorgrenzen hat das SV jeweils ein Loch, was zu Grafikfehlern führt.
komisch, bei mir nicht, da mußt du was falsch machen, vielleicht vergisst du es die objekte im nebensector zu beleuchten.
0x00000001 schrieb:
Wie kann man diese beiden Probleme lösen?
1.1. modeller genau anweisen wieviel von welchen lichtquellen sie nutzen dürfen.
1.2. shadowmaps nutzen, ist fixer und in genausovielen lagen flexibler wie es unflexibler
2. nebensektor mitbeleuchten falls das portal dazu beleuchtet wird bzw in leuchtweite ist.rapso->greets();
-
Hi, Danke für die Antwort.
das ist der grund weshalb D3 maximal 2 schatten werfende lichtquellen hat, meißt nur eine und ein paar statisch projezierte schadowmaps.
Diese statisch projezierten 'Shadowmaps' hab ich schon eingebaut. Ich meine damit eine Cube Textur, die das Licht in alle Richtungen filtert. Ich denke das wirst Du wohl auch meinen.
Aber 2 Lichter sind mir zu wenig, ich will volle Kanne Schatten für alles
. Jeder Schuss, jede Lampe, alles. Das sollte auch gehen, man kann es zB in der Amp2 Engine bestaunen. 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.komisch, bei mir nicht, da mußt du was falsch machen, vielleicht vergisst du es die objekte im nebensector zu beleuchten.
Das kommt daher, dass ich die Kanten immer nur innerhalb eines Sektors suche. D.h. bei den Portals hat die Geometrie keine richtige Verbindung zum Nachbarsektor sondern eben einfach ein Loch. Aber das sollte nicht so das Problem sein.
Shadowmaps:
Ich habe mir grade eben einiges dazu durchgelesen, kenne mich aber nicht so gut damit aus.
Ich glaube, dass es einigen meiner Anforderungen nicht entspricht.
zB sollte ein Punktlicht Schatten in alle Richtungen werfen können. Geht das mit Shadowmaps?
Naja aber ehrlichgesagt bin ich da nicht so überzeugt davon, denn einerseits bekommt man bei einiger Enfernung so pixelige Schatten und zum anderen wollte ich noch Soft-Shadows einbauen wenn ich mal in den Genuss einer PS 2.0 Karte komm. Und zum Glück basiert die Technik auch auf SV's:
http://www.ce.chalmers.se/staff/tomasm/soft/Wenn sonst keiner eine Idee hat probier ich halt mal aus ob meine oben genannte Idee funktioniert.
-
0x00000001 schrieb:
Hi, Danke für die Antwort.
das ist der grund weshalb D3 maximal 2 schatten werfende lichtquellen hat, meißt nur eine und ein paar statisch projezierte schadowmaps.
Diese statisch projezierten 'Shadowmaps' hab ich schon eingebaut. Ich meine damit eine Cube Textur, die das Licht in alle Richtungen filtert. Ich denke das wirst Du wohl auch meinen.
Aber 2 Lichter sind mir zu wenig, ich will volle Kanne Schatten für alles. Jeder Schuss, jede Lampe, alles. Das sollte auch gehen, man kann es zB in der Amp2 Engine bestaunen. 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.dann muss deine mindestvoraussetzung größer sein als die, die es bei D3 werden wird, also weit über GF3
0x00000001 schrieb:
komisch, bei mir nicht, da mußt du was falsch machen, vielleicht vergisst du es die objekte im nebensector zu beleuchten.
Das kommt daher, dass ich die Kanten immer nur innerhalb eines Sektors suche. D.h. bei den Portals hat die Geometrie keine richtige Verbindung zum Nachbarsektor sondern eben einfach ein Loch. Aber das sollte nicht so das Problem sein.
tja, wenn du nur innerhalb eines sektors beleuchtest solltest du dich nicht über die unbeschatteten nachbarräume wundern.
0x00000001 schrieb:
Shadowmaps:
Ich habe mir grade eben einiges dazu durchgelesen, kenne mich aber nicht so gut damit aus.
Ich glaube, dass es einigen meiner Anforderungen nicht entspricht.
zB sollte ein Punktlicht Schatten in alle Richtungen werfen können. Geht das mit Shadowmaps?das geht gut, heißt dual parabolid shadowmapping, ein kleines paper dass dich weiterbrächte wäre das.
0x00000001 schrieb:
Naja aber ehrlichgesagt bin ich da nicht so überzeugt davon, denn einerseits bekommt man bei einiger Enfernung so pixelige Schatten und zum anderen wollte ich noch Soft-Shadows einbauen wenn ich mal in den Genuss einer PS 2.0 Karte komm. Und zum Glück basiert die Technik auch auf SV's:
http://www.ce.chalmers.se/staff/tomasm/soft/Softshadows sind eigentlich "for free" bei shadowmaps, bei shadowvolumes mußt du noch extra aufwand betreiben. Den algorithmus hab ich auch schon irgendwo in einem buch gelesen
rapso->greets();
-
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? Also einfach nur 10 Granaten + 1 Licht = 10 Schatten. Möchtest du denn bewegliche Lichtquellen? Bei statischen Lichtquellen kann man einen Teil vorberechnen. Ich nehme mal an, das auch D3 genau das machen wird.
Bye, TGGC \-/
-
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...
-
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.
-
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.
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.
-
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 \-/
-
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.
-
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!
-
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 \-/
-
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 GehirnschmalzDieses 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 seinDie Seite:
http://www.theprodukkt.comScreenshots:
http://www.theprodukkt.de/files/kkrieger_snapshots.zip
-
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 \-/
-
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
-
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!
-
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 gerendertDie 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.
-
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 gerendertDie 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();
-
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 \-/
-
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 istzudem 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
-
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();
