Das ist ja die Projektion....nur das du homogene Koordinaten erhältst.....*rausred*..... ....aber du hast recht die eigentlich Projektion ist natürlich erst bei der Division. Ich meinte jedenfalls diese Matrixmultiplikationen teilweise dann doch in den Vertexshader zu verlagern.


Texturabfrage!!! Du solltest für jedes Objekt nur die Lampen aktivieren die diese Objekt auch treffen können. max_lights sollte ein Uniform sein damit du das steuern kannst, wenn mal für ein Objekt nur zwei oder drei Lampen aktiv sind. Große Objekte wie Boden/Decke/Wände solltest du ggf. unterteilen.

_________________
Yeah!

ich rendere nicht objektspezifisch. Ich render einfach die Scheinwerfer in Gruppen. Ich wollte mir noch eine Abfrage schreiben welche prüft ob eine projektion überhaupt sichtbar ist und den Scheinwerfer vorher schon aus dem Rennen schmeissen.. Doch ich weiß nich wie ich das feststellen kann .. Ich hab ja nur die Scheinwerferposition?

Dann ist das ein Problem. Die Fläche die von einem Scheinwerfer bestrahlt wird ist im Vergleich zur Gesamtfläche der Szene verdammt klein.

Hast du eigentlich mal die verschiedenen Textur-Wrapverfahren durch probiert? Sofern du das noch nicht machst solltest du mal GL_CLAMP_TO_BORDER statt GL_CLAMP_TO_EDGE bzw. GL_CLAMP versuchen. Dann wird nämlich die Farbe genutzt die du mit
GL_TEXTURE_BORDER_COLOR eingestellt hast....also schwarz per default. Das erfordert aber keinen Textur- bzw. Speicherzugriff und könnte daher schneller sein.

_________________
Yeah!

wenn du damit die projektionstextur meinst, is schon passiert.


ohne diese Einstellung sehe ich überall hässliche Ränder..

wie müsste die Berechnung den aussehen wenn ich mithilfe des Licht- und Kameravektors und dem Abstrahlwinkel der Lampe berechnen will ob ich die Projektion sehe?

Du hast doch die Texturmatrix....damit kannst du dir leicht die Eckpunkte des Licht-Frustums berechnen:

Aus den Punkten kannst du dir dann eine BoundingBox oder was auch immer berechnen und das auf Sichtbarkeit prüfen. Eine AxisAlignedBoundingBox (AABB) ist wahrscheinlich eher schlecht, aber eine OrientedBoundingBox (OBB) ist vielleicht ganz sinnvoll.

_________________
Yeah!

nun ich wollte die Lampen, dessen projektion ich garnicht sehe, garnicht erst in den Shader jagen.. Denn die Anzahl der Lampen entscheidet auch die Anzahl der Renderpässe..

Verwendest du sehr große Texturen (evtl. ohne MipMaps) oder sehr hohe Filtereinstellungen (16x Anisotroph)?

nun das Modell hat Texturen von max 1024x1024 und meine projektionstextur ist aktuell nur 32x32 soll aber später 100x100 werden.
Was meinst du für Filtereinstellungen?

Deswegen berechnest du das auch nicht im shader, sondern davor

Wird das mittlerweile von allen Graphikkarten unterstützt?

Du meinst Non-Power-Of-Two Texturen? Ist eine Voraussetzung für OpenGL 2.0, in sofern: ja

_________________
Yeah!

Mit Filtereinstellungen meine ich das was man in den Programmen der Grafikkartenhersteller konfigurieren kann. Ich könnte mir vorstellen das ein starker anisotrphischer Filter und riesige Texturen auf der ganzen Bildschirmfläche irgendwo Speicherbandbreite und Caching der Grafikkarte überfordern. Aber bei derart winzigen Texturen ... nein da kann es an so etwas nicht liegen.
Befindet sich deine Szene momentan im Nichts? Also sieht man viele Bereiche, die Hintergrundfarbe sind und auf die der Shader nicht angewendet wird wenn man weiter weg ist? Wenn da nichts ist, und die Szene langsamer wird wenn du näher herangehst war das natürlich zu erwarten. Wenn du aber den Shader praktisch immer auf alle Pixel des Bildschirms anwendest (weil du z.B. einen geschlossenenen Raum darstellst) scheint es schneller zu laufen, wenn das GL_CLAMP_TO_BORDER einspringt.
Welche Grafikkarte verwendest du eigentlich genau? Vielleicht gibt es bei dem Modell Besonderheiten zu beachten. Ich habe zum Beispiel bei meiner Grafikkarte unter Linux manchmal die Situation gehabt, dass sie nicht aus dem Enegiesparmodus herausgekommen ist. Manchmal sind auch bestimmte Texturformate langsam oder existieren Limitationen bei den Shadern.


Sogar angeblich mit MipMapping. Irgendwas habe ich da wohl immer falsch gemacht ^^.

Als Beispiel für 'Besonderheiten': Hier zum Beispiel hat jemand Texturen mit MipMapping in if-Blöcken in DirectX-HLSL ausgelesen und musste feststellen, dass die Texturen immer vor dem if-Block gelesen wurden: http://www.ureader.com/msg/1465171.aspx
Wenn das in deinem Fall auch eine Rolle spielt würde das unglaubliche 1+8*8 = 47 Texture Fetches bedeuten.
Zu testen wäre also, ob ein Texturfilter von GL_NEAREST etwas ändert oder alle 8 Texturzugriffe schon vor der Schleife in ein Array zu legen und in der Schleife aus diesem statt den Texturen zu lesen.

Für die GeForce 6800 Ultra habe ich noch ein PDF gefunden, das Taktzyklen angibt.
Während für die Ultra-Variante gesagt wird:
"16 four-wide fp32 vector MADs per clock cycle in the pixel shader, plus 16 four-wide fp32 multiplies per clock cycle"
steht dort für if-else-endif und co. unspezifisch:
"If/endif: 4 clock cycles"
"If/else/endif: 6 clock cycles"
"Call: 2 clock cycles"
"Ret: 2 clock cycles"
"Loop/endloop: 4 clock cycles"
Also auch komplexere Rechenoperationen können in einem Takt durchgeführt werden, während in der 8-Mal-Schleife wenn sie unrolled wird 1*6+2*6+3*6+4*6+5*6+6*6+7*6+7*6+4 = 214 Taktzyklen für die Ablaufkontrolle benötigt werden.

Grafikkarte hab ich eine Geforce 9600M GT. Also ich gucke mir quasi immer einen ganzen raum an.. Kann aber auch so hereinsoomen als wenn ich im Raum stehe. Wenn ich nun den ganzen Raum sehe mit allen projektionen scheint der Fragmentshader nicht so beschäftigt zu sein, als wenn ich ganz nah in den Raum reingehe.. Aktuell rendere ich auch noch direkt in den Framebuffer. Ich will aber das ganze noch in FBOs packen und die Auflösung noch runterregeln. Denn wenn ich z.B. mit Fullscreen (1920pixel) rendere dann hab ich nur noch 2-6fps.. Als Szene hab ich zum Test logischerweise ein rel. komplexe mit vielen Polygonen gewählt..

Ich bin jedoch immernoch nicht ganz dahinter gekommen wie ich das mit der Boundingbox berechnen soll..

Tut mir Leid, aber ich habe überhaupt nichts verstanden. Also wann die Szene schneller läuft und wann langsamer ist mir noch immer nicht klar.
Wenn du die if-Anweisungen in der Schleife entfernst wird das Berechnen der Pixelfarben jedoch vermutlich ein Vielfaches schneller laufen ohne das die Qualität sich verschlechtert. Das haben ja auch andere schon gesagt.
Es gibt auch noch eine Technik, die in deinem Fall anwendbar sein könnte. Du hast ja sehr 'teure' Pixel. Jedes Pixel das gespart werden kann ist ein gutes Pixel. Rendere die Szene zwei mal und deaktiviere beim ersten mal das Schreiben in den Color-Buffer. (Mit dem Resultat, das beim zweiten Durchgang der Z-Puffer schon steht und kein Pixel im Hintergrund von einem Pixel im Vordergrund übermalt wird.)
Vielleicht kannst du noch Screenshots posten, die zeigen wo die Performance einbricht?

Unbedingt Lesen: GeForce 8/9 Programming Guide
nVidia bietet außerdem Tools wie ShaderPerf an, die dir genau sagen können wie viele Taktzyklen dein Pixel-Shader braucht. Das ist vielleicht besser als wenn wir hier Vermutungen anstellen.