Shadow Volumes mit beliebiger Geometrie
-
Stefan Zerbst schrieb:
Hi,
An jeder Kante des Modells ein zu einer Linie degeniriertes Viereck einfügen. Was das für den Vertex-Count des Modells bedeutet dürfte klar sein.So wie du es erklärst, bleibt er dabei gleich. Für degenerierte Vierecke bräuchte man nur neue Indizes, weil die Vertizen ja gleich sein müssen. (Ich weiss nicht wie es funktioniert, nur das was du hier geschrieben hast.)
-
rapso schrieb:
wobei wird er der erste sein?
bumpmapping wie "expandeble" zu haben? schatten mit stencilbuffern wie schon fussballsimulationen? wüste gerne was du meinst.
vielleicht sind ja auch die grafiker das, was deren hype ausmacht, ziemlich gut was die aus den bescheidenen möglichkeiten zaubern, die sie haben, mit max2 lichtquellen jedes objekt auszuleuchten und zumeinst nur eine im raum die schatten wirft...
"expandeble"? OMG...
Stimmt, Fußball-Sims sehen einfach genial aus...
Klar, die Grafiker können et. Und Paul und Tim als Leveldesigner waren auch immer schon genial...
Tja, nur der Romero fehlt...
Aber der macht ja jetzt in PDAs...
DOS-Setup-Routinen werden halt nit mehr gebraucht... :p
-
Stefan Zerbst schrieb:
man sollte beachten, dass Shader==schnell nicht automatisch true ergibt. Es kommt darauf an, was Deine GPU und CPU sonst noch zu tun haben.
wenn man die GPU machen lässt ohne "Lock" dann kann man mit hocher sicherheit davon ausgehen, dass es schneller ist als mit der cpu. alleine schon 2M vertices/s mit allen nötigen daten zu übertragen kann schnell die 512MB/s eines AGP4 sprengen, was nur 40kVertices bei 50fps wären, die bei degenerierten quads also nur ~10k kanten (6.7k bei strips) bedeuten würden... obwohl volumes so sehr fillrate limitiert sind, dass du recht haben könntest, dass es mit nicht schnell laufen _muss_ bloss weil ein shader benutzt wird. Aber auf heutigen Grakas ist ein aufwendiger shader schneller als cpu, nicht weil die cpu langsam sein wuerde, sondern weil der transfer langsam ist und die graka nicht asynchron arbeiten kann. (schliesslich muessen alle vertices bearbeitet worden sein bevor man mit einem lock alle aendert).
Stefan Zerbst schrieb:
Das einfache Ausziehen des Modells in einem Shader funktioniert nur für sehr runde, weiche Modelle halbwegs und setzt voraus, dass die Vertices für mehrere Triangles verwendet werden. Sobald man für angrenzende Triangles auf derselben Position zwei Vertices verwendet oder sehr kantige Modele hat geht das so nicht in einem Shader.
irgendwie kann ich dir hier nicht folgen, koenntest du das anders umschreiben was du sagen moechtest ?Stefan Zerbst schrieb:
Wenn man auf der CPU "lästig" Kanten suchen muss, dann muss man für einen Shader eine andere lästige Setup Arbeit machen. Nämlich das einfügen degenerierter Quads. An jeder Kante des Modells ein zu einer Linie degeniriertes Viereck einfügen. Was das für den Vertex-Count des Modells bedeutet dürfte klar sein. Im Shader kann man dann tatsächlich einfach alle Backfacing Verts in Lichtlaufrichtung ausziehen. Die degenrierten Quads sorgen dann dafür, dass an der Silouhette keine Löcher entstehen weil sie dort zu richtigen Quads ausgezogen werden.
*quizmaster*
- wie soll man mit dem vertexshader quads einfügen? ist das irgendwie anders gemeint?
- "Kante des Modells ein zu einer Linie degeniriertes" meinst du mit linie die kante jedes dreiecks oder der silouhette oder etwas anderes?
- mit Lichtlaufrichtung meinst du den vektor von der lichtquellen position zum vertex? (das "lauf" macht mich confused)so wie ich das jetzt glaube verstanden zu haben möchtest du um jedes dreieck herum, an jede kante ein quad einfügen und falls es ein backface ist dann extrudieren... hmm.. oder?
wuerde das frontface-backface prüfen nicht eigentlich automatisch passieren und man könnte sogar die seperaten operationen für back und frontface für den stencilbuffer nutzen?
hätte man mit der cpu nicht die gleiche arbeit? würde das nicht eventuell langsammer sein, weil z.B. die GPU zum prüfen ob eine kante auch wirklich silouhette ist nur 2 Dotoperationen macht (2takte) und die cpu dafür einiges mehr braucht?
ok, das war's auch scho was mich beschäftigt
hoffe du kannst mich zu deinen gedanken aufklärenrapso->greets();
-
Hi,
@TGGC
Als Der Große Game Coder hast Du sicherlich keine Schwierigkeiten aus meiner wagen Beschreibung zu verstehen wie das funktioniert.Aber natürlich hast Du recht ich habe mich hier sehr kurz gefasst was ja sonst die Spezialität von anderen Leuten ist
Die einzufügenden degenerierten Quads bringen natürlich je vier neue Vertices in das Mesh mit ein, das ist ja Sinn der Sache damit man Vertices zum Ausziehen hat ohne Risse im Mesh zu erzeugen.
Ohne Shader macht man dasselbe. Der Unterschied für die Shader Version ist nur, dass man alle potenziell benötigten zusätzlichen Rechtecke für die Extruierung der Silouhette zur Initialisierungs-Zeit in das Mesh einfügen muss.
Ciao,
Stefan
-
@rapso
Ich meinte mit der CPU und GPU Auslastung was das Programm den jeweiligen Prozessoren noch aufdrückt. Wenn das Programm bereits GPU limited ist, dann wäre es besser die Volumes über die CPU zu machen.Natürlich kann man in einem Shader keine Vertices erzeugen, daher muss man die degenrierten Quads zur Initialisierungszeit dem Mesh einmalig hinzufügen, und zwar für jede Kante. Im Shader werden dann alle Vertices extruiert die von der Lichtquelle wegschauen. Die Backcap verschwindet nach hinten und die degenrierten Quads an der Silouhette werden ausgezogen um die Front- und Back-Cap zu verbinden.
Was die "runden" Modelle angeht so kann man das Mesh einer Kugel z.B. extruieren ohne dass es zu Fehlern kommt, wenn es keine Vertices auf derselben mit unterschiedlichen Normalen gibt so dass angrenzente Triangle verschiedene Vertices verwenden würden. Dann würde man beim Ausziehen einen Riss zwischen Front- und Backcap erhalten.
Bei eckigen Modellen wie z.B. einem Würfel geht das nicht so gut weil der Normalenvektor der Vertices eben nicht dem der Ebene der angrenzenden Triangle halbwegs entsprechen kann.
Ciao,
Stefanvgl. Dempski, K.; Premier Press; S. 537
vgl. Brennan, C.; Wordware; Figure 1, S. 190; in Engel, W. (Hrsg.)
vgl. www.gamedev.net/columns/hardcore/shadowvolume/page5.asp , Abschnitt "Shadow Volumes Powered By Vertex Shaders"
-
Stefan Zerbst schrieb:
Ich meinte mit der CPU und GPU Auslastung was das Programm den jeweiligen Prozessoren noch aufdrückt. Wenn das Programm bereits GPU limited ist, dann wäre es besser die Volumes über die CPU zu machen.
zwar hat man eine bessere lastenverteilung, aber hauptsächlich deswegen weil die cpu beim lock auf die gpu wartet. es seiden man hat nun wirklich sehr viele polys die man mit der cpu verarbeitet, doch dann wird der traffic wieder limitierend und cpu+gpu warten auf den datentransfer.
Stefan Zerbst schrieb:
Natürlich kann man in einem Shader keine Vertices erzeugen, daher muss man die degenrierten Quads zur Initialisierungszeit dem Mesh einmalig hinzufügen, und zwar für jede Kante. Im Shader werden dann alle Vertices extruiert die von der Lichtquelle wegschauen. Die Backcap verschwindet nach hinten und die degenrierten Quads an der Silouhette werden ausgezogen um die Front- und Back-Cap zu verbinden.
hmm.. anhand von was definiert man denn die blickrichtung der vertices die bei dem cap sind? anhand des dreiecks zu dem sie gehören? dann dürfte man aber kein einziges vertex sharen zwischen den dreiecken, oder?
Stefan Zerbst schrieb:
Was die "runden" Modelle angeht so kann man das Mesh einer Kugel z.B. extruieren ohne dass es zu Fehlern kommt, wenn es keine Vertices auf derselben mit unterschiedlichen Normalen gibt so dass angrenzente Triangle verschiedene Vertices verwenden würden. Dann würde man beim Ausziehen einen Riss zwischen Front- und Backcap erhalten.
das mesch selber? ohne die seiten des volumes? dann müßte man ja das volume wirklich auf unendlich-weit extrudieren damit das nicht auffällt *kopfkratz*
Stefan Zerbst schrieb:
Bei eckigen Modellen wie z.B. einem Würfel geht das nicht so gut weil der Normalenvektor der Vertices eben nicht dem der Ebene der angrenzenden Triangle halbwegs entsprechen kann.
wenn man das ebenfalls so ziemlich unendlich weit extrudiert, könnte das stimmen wenn man die box hoch genug tesseliert, or?
Stefan Zerbst schrieb:
vgl. Dempski, K.; Premier Press; S. 537
vgl. Brennan, C.; Wordware; Figure 1, S. 190; in Engel, W. (Hrsg.)
vgl. http://www.gamedev.net/columns/hardcore/shadowvolume/page5.asp , Abschnitt "Shadow Volumes Powered By Vertex Shaders""We need to create a quad for every edge (2 vertices) that is shared by exactly 2 faces. The quad can be viewed as a "degenerate" quad formed by the original edge shared by 2 different faces. Both the faces contribute the same edge to the degenerate quad. Since the edges from both faces are similar, positional wise, the degenerate quad is "zero length". The only difference is that the edges hold the normal information of their respective face. Once in the vertex program, we dot the light vector and the vertex normal. If the result is positive, the vertices pass through the vertex program untouched. If the result is negative, we extrude it in the direction of the light vector. This technique would elegantly generate a closed shadow volume as light facing geometries are left untouched to form the front capping while geometries that faces away from the light are extruded to form the sides of the shadow volume and the back capping."
da frage ich mich, wenn man ein quad generiert pro kante und die kante von zwei triangles geshared wird, wie will man dann rausfinden ob das quad front oder backfaced ist, da die kanten der triangles selbst gegenläufig sind (falls sie richtig gemodellt sind).
rapso->greets();
-
da frage ich mich, wenn man ein quad generiert pro kante und die kante von zwei triangles geshared wird, wie will man dann rausfinden ob das quad front oder backfaced ist, da die kanten der triangles selbst gegenläufig sind (falls sie richtig gemodellt sind).
Die Vertices zweier angrenzender Triangles müssen redundant vorhanden sein. Es dürfen also keine Vertices zwischen Polygonen über Indices geshared werden. Anhand der Normalenvektoren, die das degenerierte Quad dann jweils von den beiden Kantenvertices der beiden Dreiecke erhält kann man die richtige Kante entsprechend ausziehen.
hmm.. anhand von was definiert man denn die blickrichtung der vertices die bei dem cap sind? anhand des dreiecks zu dem sie gehören? dann dürfte man aber kein einziges vertex sharen zwischen den dreiecken, oder?
Anhand der Vertex-Normalen
also letzten Endes i.d.R. über die Triangle Normalen. Zwischen der Triangulation eines ebenen Polygons kann man die Triangles schon über Indices sharen, nicht aber an den Kanten der Polygone das ist korrekt.das mesch selber? ohne die seiten des volumes? dann müßte man ja das volume wirklich auf unendlich-weit extrudieren damit das nicht auffällt *kopfkratz*
Ja so macht es Dempski in seinem sehr einfachen Beispiel. Bei einem Mesh wie einer Kugel geht das, weil dann das Mesh entsprechend gedehnt wird. Alle Vertices werden geshared, es gibt keine redundanten Vertices an derselben Position. Wenn das Mesh geschlossen ist, erhält man auch einen geschlossenen Volume. Ausziehen muss man dann so weit, wie die maximale Entfernung der Ebene auf die Schatten fällt. Diese Technik ist die einfachst, aber wie gesagt keinesfalls robust und in der Realität wohl kaum einsetzbar. Schon allein weil man in seinen Meshs oftmals redundante Vertices einsetzen wird.
wenn man das ebenfalls so ziemlich unendlich weit extrudiert, könnte das stimmen wenn man die box hoch genug tesseliert, or?
Nein, das Problem ist nicht die Tesselierung, sondern die harten Kanten. Anhand der Vertexnormalen entscheidet sich, ob ausgezogen wird oder nicht. Bei runden Objekten hat man keine große Sprünge zwischen den Normalenvektoren angrenzender Polygone, bei kantigen Objekten aber sehr wohl. Daher werden mit hoher Wahrscheinlichkeit Vertices fälschlicherweise ausgezogen obwohl ihre Faces noch frontfacing zum Licht sind und vie versa.
Ciao,
Stefan
-
ok, dieses verfahren hab ich nun intus, quasi ein volume-fake
aber das letzte da was ich getippt habe, dazu keine antwort? ich hab sowas nämlich implementiert, genau auf die selbe art und mir ist dann erst aufgefallen, dass ich garnicht rausfinden kann ob eine kante front oder backface ist, weil sie quasi beides ist.
vielleicht anhand dessen welche normale (von triangle 1 oder 2) backfaced von der lichtquelle ist und dann abhängig davon ob die lichtquelle richtung bildschirm oder davon abgewendet ist?also meine shadowmaps sind mir da vieel lieber und fixer
rapso->greets();
-
Hi,
nein nicht direkt ein Volume Fake. Bei dem herkömmlichen Verfahren für Volumes erzeugst Du ja in jedem Frame (bzw. wenn sich das Objekt oder die Lichtquelle bewegt) den Volume neu, und fügst neue Triangles ein die an der Silouhetten anliegen und die beiden Caps verbinden.
In dem oben beschriebenen fügt man einfach vorweg sämtliche Geometrie ein, die man eventuell dafür brauchen könnte für jede beliebige Lichtposition weil man das im Shader nicht machen kann. Der Rest ist analog zum CPU Shadow Volume.
Was Deine Frage angeht, die habe ich schon beantwortet
Du hast für jeden Vertex einen Normalenvektor gespeichert, und zwar den des zugehörigen Triangles. Für die degenerierten Quads nimmt man auf einer Kante die Normalen des einen Tris, auf der anderen Kante die des anderen Tris. Wenn das eine Tri backfacing ist, dann ist es auch die entsprechende Kante des Quads und wird mit ausgezogen. Wenn das zweite Tri an dieser Kante Frontfacing ist, dann ist es auch die zweite Kante des Quads und sie bleibt wo sie ist. Damit ist das Quad nun nicht mehr degeneriert, sondern verbindet die Front Cap mit der Back Cap
Shadow Maps habe ich selber noch nicht angefasst. Shadow Volumes haben in der Tat so ihre Probleme, beispielsweise wenn der Schatten eines Objektes durch den Boden einer Etage auf die darunterliegende durchbricht. Das lässt sich IMHO nicht wirklich einfach lösen.
Was Volumes über Shader angeht so finde ich, dass man sich mit den degenerierten Quads viel zu viel Geometrie ans Bein bindet. Für jede Kante eines Meshs braucht man vier neue Vertices die auch in jedem Frame durch die Pipeline gehen.
Aber im neuen ShaderX2 Buch soll es ja vielversprechende Optimierungsansätze dafür geben
Ciao,
Stefan
-
Stefan Zerbst schrieb:
nein nicht direkt ein Volume Fake. Bei dem herkömmlichen Verfahren für Volumes erzeugst Du ja in jedem Frame (bzw. wenn sich das Objekt oder die Lichtquelle bewegt) den Volume neu, und fügst neue Triangles ein die an der Silouhetten anliegen und die beiden Caps verbinden.
damit meinte ich ja auch das mit der kugel, bei der man ja nicht extra geometrie dranhängt sondern einfach nur die vorhandene, je nach vertexnormale, extrudiert (in die unendlichkeit), wobei ich trotzdem glaube dass es bei hochtesselierten boxen noch einigermassen richtig ausschauen würde... und weil die geometrie nicht wirklich das volume erzeugen kann: "volume fake"
Stefan Zerbst schrieb:
In dem oben beschriebenen fügt man einfach vorweg sämtliche Geometrie ein, die man eventuell dafür brauchen könnte für jede beliebige Lichtposition weil man das im Shader nicht machen kann. Der Rest ist analog zum CPU Shadow Volume.
das war ja schon die zweite methode oder durchblicke ich das immer noch net?
c++ und mathe ist einfach, aber die kommunikation zwischen menschen.. wann haben wir endlich ein "braininterfaces"
Stefan Zerbst schrieb:
Was Deine Frage angeht, die habe ich schon beantwortet
naja, die erklärung jetzt war besser für mich noob, nun hab ich's.. ich war zu sehr darauf fixiert wie ich es gemacht hatte...
Stefan Zerbst schrieb:
Shadow Maps habe ich selber noch nicht angefasst. Shadow Volumes haben in der Tat so ihre Probleme, beispielsweise wenn der Schatten eines Objektes durch den Boden einer Etage auf die darunterliegende durchbricht. Das lässt sich IMHO nicht wirklich einfach lösen.
eigentlich kann das garnicht passieren wenn man die shadowvolumes richtig nutzt, man muss ja vom fussboden dann auch ein volume werfen und somit wäre von der oberen lichtquelle garnichts mehr beleuchtet, wobei man dafür eigentlich culling hat dass die lichtquelle sowieso als "ohne einfluss" definieren sollte, jedenfalls bei indoor mittels portalculling.
Stefan Zerbst schrieb:
Was Volumes über Shader angeht so finde ich, dass man sich mit den degenerierten Quads viel zu viel Geometrie ans Bein bindet. Für jede Kante eines Meshs braucht man vier neue Vertices die auch in jedem Frame durch die Pipeline gehen.
eigentlich müßte doch die fillrate das sein, was suckt, oder? immerhin muss man die caps manchmal auf die nearplane projezieren für carmacks reverstrick
ne optimierung die mir einfallen würde, wäre: anstatt vertices einzufügen, lieber im vorhandenem vertexformat die normalen irgendwo z.B. als RGB color einfügen. dann könnte man nämlich genausoviele vertices nutzen wie vorher, man müßte nur mittels indices die quads generieren und den shader anpassen.
übrigens ist die definition von "degenerated vertices" die, dass sie als "nicht nutzbar" von der hardware deklassiert werden und deswegen nicht mitberechnet werden. wenn man einfach nur quads hat (bzw. triangles) die verschiedene vertices mit der selben position benutzen, dann sind sie für die hardware nicht degeneriert und würden bis zum ende in den rasterriser nachgeschoben werden. deswegen steht in dem gamedev artikel degenerated wohl immer in "-zeichen. zur zeit können die grakas nur anhand der indices degenerierte vertices erkennen und vorher rausschmeissen. wenn man nur mittels indices die volumes hinzufügen würde, könnte man das caching der Vertexpipline nutzen und würde vielleicht kaum performanceinbussen wegen ihnen erhalten.
ach ja, shadowmaps sind auch nicht das ware, erst kürzlich mußte ich vieles umstellen, weil die geforceFX keinen floatingpoint buffer hat und ich alles schon darauf auf meiner ATI am laufen hatte...
rapso->greets();
ps. danke für die aufklärung, schonwieder wat gelernt (das volumezeug meine ich, aber jetzt muss ich mir ja dein buch net mehr kaufen.. *seufz*
)
-
Wenn die Volumes undenlich lang sind, benötigt man doch überhaupt keine extra Vertices. Es reicht ja schon ein Vertex, der nach hinten verschoben wird, damit die Kanten des Volumes senkrecht zum Licht sind. Wenn man nicht alle Winkel >= 90 Grad hat, sollte dann immer mindestens ein vertex auf der Rückseite da sein.
Wenn die extra-Vertices also ein Sinn haben, dann weil in Ihnen Informationen gespeichert sind. Habe nur noch nicht rauslesen können, welche das sind.
-
TGGC schrieb:
Wenn die Volumes undenlich lang sind, benötigt man doch überhaupt keine extra Vertices.
wenn sie von dir wegzeigen sind sie unendlich lang, wenn sie zu dir zeigen, dann muss die die "cap" auf die nearplane projeziert werden.
TGGC schrieb:
Es reicht ja schon ein Vertex, der nach hinten verschoben wird, damit die Kanten des Volumes senkrecht zum Licht sind. Wenn man nicht alle Winkel >= 90 Grad hat, sollte dann immer mindestens ein vertex auf der Rückseite da sein.
Wenn die extra-Vertices also ein Sinn haben, dann weil in Ihnen Informationen gespeichert sind. Habe nur noch nicht rauslesen können, welche das sind.das ist die normale des faces zu dem das vertex gehört. den vorschlag ohne vertices einzufügen die volumes mittesl zusätzlicher indices zu erstellen hab ich aber auch gerade gemacht
rapso->greets();
-
Hi,
das war ja schon die zweite methode oder durchblicke ich das immer noch net?
Ich habe mich oben vielleicht etwas unklar ausgedrückt
Das ist immer noch dieselbe Methode.man muss ja vom fussboden dann auch ein volume werfen und somit wäre von der oberen lichtquelle garnichts mehr beleuchtet, wobei man dafür eigentlich culling hat dass die lichtquelle sowieso als "ohne einfluss" definieren sollte, jedenfalls bei indoor mittels portalculling.
Also wenn man für jeden Fussboden einen Shadow-Volume rendert dann kann man während jedes Frames erstmal einen Kaffe trinken gehen. Dann wird die Fillrate wirklich "sucken"
Aber auch bei Portalen gibt es Situationen, in denen man z.B. in einem Treppenaufgang steht und beide Stockwerke und deren Portale einsehen kann. Nun könnte man sicherlich jeden Sektor einzeln rendern und dann den Stencil-Buffer clearen um das "durchscheinen" des Schattens zu vermeiden. Dann limitiert man sich aber selbst darauf, dass Schatten direkt an den Portalen abreissen auch wenn sie physikalisch korrekt eigentlich dort weitergehen sollten. Wie gesagt, es gibt keinen ganz einfachen Weg um alle Probleme dort elegant zu beheben. Workarounds gibt es hingegen Dutzende würde ich meinen
Die Fillrate bei den Shadow Volumes ist wirklich nicht pralle, aber ich verwende die Volumes auf der CPU, daher ist es der Bus Transfer der auch noch drückt.
ne optimierung die mir einfallen würde, wäre: anstatt vertices einzufügen, lieber im vorhandenem vertexformat die normalen irgendwo z.B. als RGB color einfügen. dann könnte man nämlich genausoviele vertices nutzen wie vorher, man müßte nur mittels indices die quads generieren und den shader anpassen.
Das stimmt. Man müsste nicht mal die Normale irgendwo einfügen, denn man hat ja für das Quad vier Indices auf vier verschiedene Vertices, wenn man für jedes ebene Polygon unique Vertices verwendet. Und bei shared Vertices könnte man nach Deinem Vorschlag die zweite Normale irgendwo im Vertex verstecken. Man müsste halt nur entscheiden können, welche jeweils zu verwenden ist
Mehr als die Basics der SVs überShader habe ich auch nicht gemacht, denn ich habe mich für die CPU Variante entschieden weil man bei animierten Objekten eh seine Schwierigkeiten bekommt. Entweder macht man die Animation mit Shadern, und muss sie entsprechend für den Shadow Volume nochmals machen. Dann hat man aber im RAM auch kein Modell für die Kollisionsabfrage usw. Wenn man die Animation aber auf der CPU macht, dann müsste man mit dem Volume im Shader auch die Animation nochmals durchrechnen. In diesem Fall sind Shader glaube ich eher der langsamere Weg.
Ciao,
StefanEDIT: Wenn ich mal Shadow Maps mache dann frage ich Dich
-
Stefan Zerbst schrieb:
Hi,
man muss ja vom fussboden dann auch ein volume werfen und somit wäre von der oberen lichtquelle garnichts mehr beleuchtet, wobei man dafür eigentlich culling hat dass die lichtquelle sowieso als "ohne einfluss" definieren sollte, jedenfalls bei indoor mittels portalculling.
Also wenn man für jeden Fussboden einen Shadow-Volume rendert dann kann man während jedes Frames erstmal einen Kaffe trinken gehen. Dann wird die Fillrate wirklich "sucken"
also wenn man jeden raum als normales objekt betrachtet, dann muss man eigentlich nich für den fussboden selbst ein volume rendern sondern nur dort wo die silouhette entsteht, in einem raum würde das also eigentlich nur dort passieren, wo es kanten zwischen nach draussen gibt, also türen und fenster.. gut zu sehene in
http://doom3maps.ngz-network.de/images/news/reicht1.jpg
der fussboden würd wohl eher keine kante haben die schatten wirft (auch nicht auf die untere etage.Stefan Zerbst schrieb:
Aber auch bei Portalen gibt es Situationen, in denen man z.B. in einem Treppenaufgang steht und beide Stockwerke und deren Portale einsehen kann. Nun könnte man sicherlich jeden Sektor einzeln rendern und dann den Stencil-Buffer clearen um das "durchscheinen" des Schattens zu vermeiden. Dann limitiert man sich aber selbst darauf, dass Schatten direkt an den Portalen abreissen auch wenn sie physikalisch korrekt eigentlich dort weitergehen sollten. Wie gesagt, es gibt keinen ganz einfachen Weg um alle Probleme dort elegant zu beheben. Workarounds gibt es hingegen Dutzende würde ich meinen
so wie es unter anderem john carmack macht ist es eigentlich ein ganz einfacher weg und der ist auch klar definiert. wenn du in einem treppenhaus zwei portale sehen kannst, dann werden die silouhetten aus den räumen, durch die portale hindurch, extrudiert, alle anderen silouhetten, die die nicht die portale berühren/schneiden, werden nur innerhalb der boundingbox des raumes extrudet (natürlich kann man das nur grob testen). durch portale kann man für eine lichtquelle sehr gut bestimmen welches objekt voraussichtlich schatten nach außen werfen wird und welches objekt außerhalb beleuchtet werden wird, das nutzt wohl doom3 auch um zu clippen und zu rendern.
mit ein grund weshalb es auf einer geforce4 noch ruckelt und nur wenig lichtquellen (eine pro raum soweit ich weiß) schatten werfen lassen.Stefan Zerbst schrieb:
ne optimierung die mir einfallen würde, wäre: anstatt vertices einzufügen, lieber im vorhandenem vertexformat die normalen irgendwo z.B. als RGB color einfügen.
Das stimmt. Man müsste nicht mal die Normale irgendwo einfügen, denn man hat ja für das Quad vier Indices auf vier verschiedene Vertices, wenn man für jedes ebene Polygon unique Vertices verwendet. Und bei shared Vertices könnte man nach Deinem Vorschlag die zweite Normale irgendwo im Vertex verstecken. Man müsste halt nur entscheiden können, welche jeweils zu verwenden ist
fürs volume berechnen würde der vertexshader einfach auf die facenormal zugreifen (die man sich im vertex abspeicher muss), wäre ziemlich simpel.
Stefan Zerbst schrieb:
Mehr als die Basics der SVs überShader habe ich auch nicht gemacht, denn ich habe mich für die CPU Variante entschieden weil man bei animierten Objekten eh seine Schwierigkeiten bekommt. Entweder macht man die Animation mit Shadern, und muss sie entsprechend für den Shadow Volume nochmals machen. Dann hat man aber im RAM auch kein Modell für die Kollisionsabfrage usw. Wenn man die Animation aber auf der CPU macht, dann müsste man mit dem Volume im Shader auch die Animation nochmals durchrechnen. In diesem Fall sind Shader glaube ich eher der langsamere Weg.
aber für die collisionsabfrage nimmt man doch eigentlich kein mesh dass geskinnt ist, dafür reicht doch ein ridged-body aus ein paar boxen, bei spielen wie MD2 nutzt man ja sogar nur einen zylinder für den ganzen awater.
Stefan Zerbst schrieb:
EDIT: Wenn ich mal Shadow Maps mache dann frage ich Dich
ach, letztens ist mir der pc beim runterfahren einfach, bevor er fertig war, ausgegangen und beim starten und scandisk wurde mein favourites ordner von opera liquidiert... ich hatte soviele paper dazu verlinkt.. FrustumOptimisations, DualParabilid Maps mit vertex und pixelshadern als source... ich werde ich dann also nur zuquatschen mit eigenem zeug wenn du fragst
rapso->greets();
-
rapso schrieb:
wenn sie von dir wegzeigen sind sie unendlich lang, wenn sie zu dir zeigen, dann muss die die "cap" auf die nearplane projeziert werden.
Ach, da drehen wir einfach die ZFunc um.
rapso schrieb:
das ist die normale des faces zu dem das vertex gehört. den vorschlag ohne vertices einzufügen die volumes mittesl zusätzlicher indices zu erstellen hab ich aber auch gerade gemacht
Die Normalen sind doch aber da, ausser an Ecken, wo die Vertizen geshared werden. Und gerade dort, sagte Stefan, funktioniert es ohne "degenerierte" Quads.
-
TGGC schrieb:
rapso schrieb:
wenn sie von dir wegzeigen sind sie unendlich lang, wenn sie zu dir zeigen, dann muss die die "cap" auf die nearplane projeziert werden.
Ach, da drehen wir einfach die ZFunc um.
wegen dem smily weiß ich net ob das jetzt ernst gemeint war... aber Das geht natürlich nicht!
TGGC schrieb:
rapso schrieb:
das ist die normale des faces zu dem das vertex gehört. den vorschlag ohne vertices einzufügen die volumes mittesl zusätzlicher indices zu erstellen hab ich aber auch gerade gemacht
Die Normalen sind doch aber da, ausser an Ecken, wo die Vertizen geshared werden. Und gerade dort, sagte Stefan, funktioniert es ohne "degenerierte" Quads.
[/quote]
ich glaube das war nur auf kugeln und ä(h)nliche objekte bezogen, normalerweise braucht man dass dann doch, wie er dann selbst anhand des wuerfels meinte.rapso->greets();
-
Hi,
ja wenn ein Volume durch ein Portal geht dann kann man das einfach herausfinden. Den Schatten dann zu rendern und den Stencil Buffer dann zu clearen und danach den nächsten Sektor anzugehen wäre der beste Weg. Dann gibt es aber wieder Sonderfälle mit den Volumes die durch Portale reichen und wann man die rendert da man dann ja den Stencil Buffer erhalten muss
Wie gesagt, machbar ist alles.
Was den Rigid Body angeht. Wenn man exakte Trefferwirkungen haben möchte, dann sollte man die Kollisionen schon mit dem geskinnten Mesh machen. Wir reden hier ja nicht von Kollisionen mit den Wänden, sondern auch z.B. mit Projektilen die bei einem Bounding Box Modell falsche Kollisionen auslösen würden.
Ciao,
Stefan
-
@rapso:
Wieso denn nicht?Ein Würfel hat doch eben keine shared Vertices, weil dort alle Kanten "scharf" sind. Ok, ich bin kein Grafiker, aber ich würde es zumindest komisch finden, wenn es so wäre.
-
ich meine tests hatte ich wirklich nicht das problem mit volumes wie du da beschreibst, aber was mir auffält ist, dass du "shadows renders", vielleicht machst du das anders als ich (könnte ja der grund sein weshalb wir es so unteschiedlich sehen ob das schwer oder einfach ist)
ich render die schatten nicht, sondern beleuchte überall wo das volume nicht ist und da hab ich auch nichts das problem, dass ich etwas clearen muss oder nicht, ich clear überall den stencilbuffer auf 0 falls er es nicht war, ansonsten setzte ich den colorpixel.wie gesagt, das läuft richtig und ist echt extrem einfach, ich hatte noch nie probleme damit (außer performance, aber das hat doom3 ja auch und deswegen stör ich mich nicht dran, hab ja meine fixen maps
mit ridget bodys läuft es recht genau, ich wüste nicht was diese (ich würde schätzen) 5% mehr genauigkeit ausmacht, schliesslich trifft man dann mal, wenn man sonst nicht getroffen hätte und manchmal ist es andersrum, diese extreme genauigkeit ist eigentlich selten von nöten... bis ich las wie MDK2 gemacht wurde, fiel mir die ungenauigkeit eigentlich kaum auf und alle modernen shooter haben auch nur trefferzonen und keinen polygongenauen test.. naja, vielleicht weiß ich von einem das nicht richtig
rapso->greets();
-
TGGC schrieb:
@rapso:
Wieso denn nicht?Ein Würfel hat doch eben keine shared Vertices, weil dort alle Kanten "scharf" sind. Ok, ich bin kein Grafiker, aber ich würde es zumindest komisch finden, wenn es so wäre.
frag lieber SZ, ich hab es ja auch erst gerade erfahren.. *weiterleit*
ne kugel hat shared vertices, und da lief dat, bei nicht shared vertices passiert das prob... glaub ihc..
rapso->greets();
