soo, also ich hab das jetzt hinbekommen. Warum ich aber für die Schattenberechnung solche spielerei da machen muss verstehe ich auch nicht... hier mal mein Shader:
uniform mat4 InvViewMat; uniform mat4 TexGenMat; //Texturprojektionsmatrix uniform vec4 lampColor; //Lichtfarbe und intensität uniform int GlobalLight; //gibt an ob globales Punktlicht verwendet werden soll uniform vec3 lightPos; //Lampenpositionen für evtl. weitere Berechnungen uniform float GlobalLightFactor; //Gibt an wie stark alle Lichter sind
if (projCoord.q < 0.0) { vec4 SK = projCoord; SK.xy = (SK.xy + 1.0) * 0.5; SK.z += 2.5; // <<< sobald z auch auf 0..1 skaliert wird funktionierts auch nich mehr.. SK.w = (SK.w +1.0) *0.5;
wie würdet ihr das einschätzen.. aktuell render ich jetzt für jeden Scheinwerfer einmach ein Fullscreenquad mit dem Shader.. So wird bei 100 Scheinwerfern auch 100x die Fragmentposition errechnet.. Würde es was bringen wenn ich wieder z.b. 2 Scheinwerfer auf einmal im Shader rendere? Oder macht dann die Schleife, doppelte Uniform Anzahl etc.. das wieder wett?
wie würdet ihr das einschätzen.. aktuell render ich jetzt für jeden Scheinwerfer einmach ein Fullscreenquad mit dem Shader.. So wird bei 100 Scheinwerfern auch 100x die Fragmentposition errechnet.. Würde es was bringen wenn ich wieder z.b. 2 Scheinwerfer auf einmal im Shader rendere? Oder macht dann die Schleife, doppelte Uniform Anzahl etc.. das wieder wett?
Nach meinen Erfahrungen bringt das leider nichts. Abgesehen davon das die Shader-Komplexität steigt, kann man auch keine Scissor-Boxen mehr verwenden. Diese Funktion dann in den Shader einzubauen, macht es auch nicht besser.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Mittels des Scissors kann man z.B. den Bereich einschränken in dem Fragmente berechnet werden (also den Bereich in dem was gerendert wird). Da deine Shader sehr aufwendig sind, deine Lichtquellen aber wohl nie alle den kompletten sichtbaren Bereich beeinflussen kann man mittels Scissorboxen viel Performance rausholen. Sprich du berechnest vor dem Rendern der Beleuchtung für eine Lichtquelle deren Beleuchtungsbereich in 2D-Koordinaten (z.b. via gluProject) über die Extrema des Leuchtkegels und setzt dann den Scissor so das nur innerhalb dieses Bereiches Fragmente gerendert werden. Dadurch sparst du Füllrate und v.a. wird der Shader nur für die auch wirklich nötigen Fragmente aufgerufen.
Nun bei meiner Szene sehe ich meistens alle Lichter.. Ich dachte nur, da ich ja jetzt für jede Lampe die Position berechne, ich auch 3 Texturzugriffe (Color,Normal & Depth) habe.. diese hätt ich dann ja nur jede 2. oder wenn möglich 4. Lampe.
Ich hab nur angst das mir irgendwann die Texturunits ausgehen, denn so ganz hab ich das mit den TMUs noch nich verstanden. Meine Graka hat 4 TMUs. Ich kann aber via glActiveTexture auch GL_TEXTURE8 setzten und im Shader verwenden.. wo liegt das das maximum?
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Bei Scissor gehts auch nicht darum wie viele Lichter du siehst. Es geht darum wie viele Fragmente im Lichtkegel liegen und berechnet werden müssen, und mittels Scissor kann man dann genau diesen Bereich setzen (rechteckig) und dann wird der Shader auch nur für diesen Bereich aufgerufen.
Und zu den Textureinheiten : Bei NVidia ists so dass man in der festen Funktionspipeline nur 4 TMUs nutzen kann, im Shader dann aber je nach Karte z.B. 16. Ermitteln kann man das mit glGet und dem Token GL_MAX_TEXTURE_IMAGE_UNITS.
das hört sich theoretisch sehr gut an.. allerdings weiß ich nicht wo ich da jetzt ansetzten soll.. Ich berechne bereits für jede Lampe ein Frustum um die Schattenberechnung zu beschleunigen.. Könnt ich das irgendwie dazu verwenden?
mir würde aber noch was einfallen.. was wenn ich einen weiteren Pass folgend vorschalte.. Dort rendere ich einfach (mit den Tiefen der Szene) einfache weisse Volumenkegel auf schwarzem Hintergrund.. Diese textur übergebe ich dann meinem Shader und verwerfe das Fragment wenn die "maske" nicht weiß ist..
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Joa, das Video zeigts ja. Genauso solltest du das auch machen, besonders wenn du ja bereits das Frustum für jede Lichtquelle hast kannst du damit ja direkt die 2D-Extrema errechnen und für glScissor nutzen. Das mit der Textur und dann im Shader verwerfen ist natürlich auch möglich, wobei der Shader dann aber trotzdem für jedes Fragement aufgerufen wird und du dann ja trotzdem pro Fragment immer mindestens ein Texturlookup und einen Vergleich mit den RGB-Werten hast. Scissorbox ist also performanter und sehr einfach zu implementieren.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Dein Frustum ist besitzt ja 8 Punkte, die rechnest du mittels gluProject in Bildschirmkoordinaten um und gehst die durch um die Extrema zu ermitteln, die bilden dann den 2D-Ausschnitt für deine Scissorbox, die du dann vorm Rendern der Lichtquelle setzen tust.
Was bringt es eigentlich, aus dem Frustum eine Scissor Box zu machen? Wäre es nicht schneller, anstelle eines Fullscreen Quads mit Scissor Box einfach das Frustum zu zeichnen (mit aktiviertem front face culling, damit nicht alles doppelt gezeichnet wird). Weil dann ist man nicht auf rechteckig beschränkt, außerdem wird dann nicht auch dort gezeichnet, wo der Lichtkegel komplett hinter dem Betrachter vorbeigeht.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Klar, rein theoretisch könnte man das Frustum auch in den Stencil schreiben und dann die entsprechende Vergleichsfunktion setzen, so dass nur die Fragmente innerhalb des Frustums dargestellt werden. Wäre dann ne Alternative zu der Sache mit der Scissorbox.
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.