Shadow Volumes mit beliebiger Geometrie
-
ja das ist langsam, dabei ist das langsammste, dass man den vertexbuffer immer neu zur grafikkarten schicken muss und da die am besten laufen, wenn sie asynchron laufen dürfen und man durch den lock des buffers das verhindert, ist das wohl das langsammste dabei ... die menge der vertexdaten könnte aber auch zuviel für den bus sein.
volumeshadows haben eben viele nachteile auch wenn deren theorie um so einfacher ist.
wenn ich dir nun jede frage beantworte, wäre das ein tutorial für sich
und davon gibt es schon genug.schau bei www.nvidia.com in der developer sektion nach papern, da bekommste auch nen source für z.B. shadowvolumes an quake models.
rapso->greetS();
-
okay, danke!!!
-
TGGC schrieb:
Selfshadowing für eine Kugel ist doch unsinnig, das sie konvex ist?
Ja schon, aber es ist ja nicht immer eine Kugel. Aber auch die Kugel sollte sich beschatten, weil ich habe reflektierende Flächen, und in ungünstigen Winkeln reflektieren die auch auf der Schattenseite. Das wäre aber ausgeschlossen, wenn diese Bereiche auch im StencilSchatten wären.
rapso schrieb:
du kannst für jede "kante" (also die zwei dreiecke) die du generierst noch die zwei normalen abspeichern von den dreiecken die sich die kante teilen, im vertexshader könntest du mittels der normalen und der richtung der zur lichtquelle (von dem vertex aus) prüfen ob beide normalen abgewand oder zu lichtquelle zugewand sind. falls sie verschieden sind, dann extrudierst du die kante, falls nicht, dann ist das keine siluetten-kante von der lichtquelle aus gesehen.
das würde aber nur bei objekten wie z.B. der kugel funktionieren, weil du ja nicht weißt ob eine kante front oder backfaced ist.
ansonsten muss das alles per cpu gemacht werden (ist dementsprechend langsam), es gibt gute paper auf der nvidia seite.
rapso->greets();Hm ich will das aber lieber nicht mit der CPU machen. Der Vertexshader ist so schön schnell. Und außerdem schreckt mich das 'Kantenfinden' ab. Ich dachte mir, dass man die Modelle einfach in die Länge ziehen kann und gut ist.
Beim Beispiel der Kugel würde sich die eine Hälfte der Kugel dann vom Licht entfernen, und die andere bliebe da, wo sie ist. Die Polygone, die in der nähe der Kante liegen, weüden dann lang gezogen.
Gut, so funktioniert das auch, aber eben nicht bei offenen Körpern.... ich könnte die Räume so modellieren, dass die Wände immer eine Rückseite und Seiten haben. So wie man sie in echt auch kennt
. Die zusätlichen Polygone würden dann beim Farbenrendern durchs Backface-Culling durchfallen oder wären nur sehr schmal.Ja ich glaube, das wird das beste sein. Ich kann nicht so gut programmieren dass ich die notwendigen Polygone automatisch erzeugen könnte. Manuell kann ich optimieren, aber automatisch könnte ich es nur so machen, wie ich oben schonmal geschrieben habe (also jedes Polygon in einen extra Körper verwandeln). Und da kämen deutlich mehr Polygone bei raus.
Schon ärgerlich wenn man als Programmierer an so einem Problem scheitert, aber das Info-Studium hab ich noch vor mir. Hoffentlich bin ich danach schlauer als jetzt
Danke, rapso und die anderen, für Eure Hilfe.
P.S: Immer mehr wird mir bei meinem lächerlichen Versuch hier klar, dass Carmack wirklich der Gott sein muss
Nicht nur, dass er es implementieren kann ;), nein, er kann es sogar noch bis in die Perfektion optimieren.
-
so ganz kann ich dir net folgen.
du hast zwar manchmal backfaces und manchmal frontfaces, aber die vertices können von einem front und einem backface gleichzeitig benutzt werden. ich würde mich also fragen wie du das extrudieren möchtest?
carmack bekommt es deswegen so gut hin, weil er nichts anderes macht (und zu tun hat) als coden. was ihn ausmacht ist nicht genialität, sondern sehr viel fleiss und die daraus resultierende erfahrung, ich finde, dass das sehr viel mehr anerkennung verdient.
da die cpu-graka-auslastung bei seiner doom3-alpha sehr hoch in richtung cpu ging, wird es wohl auch mit der cpu seine volumes generieren. als optimierung setzt er eine ebene höcher an. z.B. prüft er erst ob ein objet von einer lichtquelle aus überhaupt zu sehen ist, dazu nutzt er portale.
bei den doom3 videos kann man sehen dass die meißte zeit nur eine lichtquelle einen schatten wirft, der rest beleuchtet, aber diese lichtquellen scheinen keine schatten werfen zu lassen.
für statische lichtquellen kann man die volumes vorberechnen.
optimieren kann man indem man z.B. mit der cpu die front und backfaces eines objektes bestimmt und sich das innerhalb eines bitfields speichert und mit dem bitfield für das objekt vom vorframe vergleicht, falls sich nix geändert hat, muss man das volume nicht neu generieren, weil die kanten gleich sind, man muss lediglich die transformation mittels vertexshader neu durchrechnen.das generieren der volumes kann man in zwei durchläufen generieren (also zwei durchgänge des meshes), die zeit ist also linear bei steigender polygonmenge.
rapso->greets();
-
[qote]du hast zwar manchmal backfaces und manchmal frontfaces, aber die vertices können von einem front und einem backface gleichzeitig benutzt werden. ich würde mich also fragen wie du das extrudieren möchtest?"[/quote]
Ja das stimmt, deßhalb werde ich wahrscheinlich alles aus Blöcken bauen müssen. Eine glatte Wand ist dann zB eine einfache Box. Man kann die Rückseite der Box dann zwar nie sehen, sie ist aber wichtig für die Shadow-Volumes. Außerdem kann ich immernoch normale, einseitige Wände bauen, wenn ich genau weiß dass die sowieso nie einen Schatten auf andere Sachen werfen kann.
Bei den statischen Lichtquellen: Wäre es da besser, die Volumes dann am Anfang vorzuberechnen und in einen extra Vertexbuffer zu schreiben oder doch alles im VertexShader machen? Der Nachteil an ersterem wäre halt höherer Speicherverbrauch und man müsste die Vertexbuffer wechseln. Zweiteres käme meiner Faulheit sehr willkommen
KA, ob der Shader sooo viel langsamer ist als die Standardvertexpipeline. Und da ich schon Dot3Bumpmapping eingebaut habe, werde ich wohl auch nicht so viele Polygone brauchen (ähnlich Doom3)Dass immer nur ein Licht in Doom3 Schatten wirft stimmt nicht ganz:
http://doom3maps.ngz-network.de/images/news/reicht1.jpg
Wie das mit den 'richtigen' Wänden funktioniert würde ich gern ausprobieren, muss jetzt aber erstmal formatieren
Ich meld mich dann nochmal, falls Windows mitmacht.
-
rapso schrieb:
was ihn ausmacht ist nicht genialität, sondern sehr viel fleiss und die daraus resultierende erfahrung
...und Genialität!
-
Was er einprogrammiert gibt es schon lange, hat nur niemand in Spieleengines eingebaut und das auch noch in der Kombination.
-
Sicher. "Akalabeth" hatte ja quasi auch schon 'ne 3D-Engine, vor Wolfenstein 3D etc.
Aber er bringt es in ph477er Quali in akzeptabler Geschwindigkeit auf HomeUser-Möhren zum Laufen. Das ist die Kunst!
Und wenn man bald 3DMax-Renderbildchen oder PovRay-likes, an denen eure Möhren z.Z. noch Stunden rechnen, in ähnlicher Quali und in Echtzeit auf handelsüblichen Systemen bewundern kann...
Er wird der Erste sein!
-
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...
rapso->greets();
-
Hi,
Hm ich will das aber lieber nicht mit der CPU machen. Der Vertexshader ist so schön schnell. Und außerdem schreckt mich das 'Kantenfinden' ab. Ich dachte mir, dass man die Modelle einfach in die Länge ziehen kann und gut ist.
man sollte beachten, dass Shader==schnell nicht automatisch true ergibt. Es kommt darauf an, was Deine GPU und CPU sonst noch zu tun haben.
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.
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.
Bei ATI gibt es ein Sample mit Code zum Download wo das so gemacht ist.
Ciao,
Stefan
-
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*
)
