Hey Jungs wie ihr gesehen habt(Distance Attenuation Thread) hab ich mal mit glSlang rumgespielt und ich bin begeistert...
Naja bisher habe ich immer nur mit einer Lichtquelle rumgespielt, nun sollen es mehr werden. Da stellt sich mir nur die Frage, geh ich mit mehr berechnungen(mehrere Lichter) in den Shader oder rendere ich die für mein Projekt zugegeben einfache Geometrie pro Lichtquelle in einem Pass und addiere die Lichtwerte dabei!

Also wollte ich mal fragen ob da jemand schon erfahrung hat und mir sagen kann was mehr Sinn macht oder einfach mal andere Ideen zum besten Geben kann![/url]

_________________
www.extrawurst.org

Also Erfahrung habe ich noch nicht gesammelt, aber schon einige Artikel zu dem Thema gelesen.
Du musst halt einfach im Pixelshader für jeden Punkt die Beleuchtung jeder einzelnen Lichtquelle berechnen und die Werte addieren. Leider gibt es noch nicht die Möglichkeit, per for-Schleife rekursiv durch alle Lichtquellen zu gehen, du musst also für jede Lichtquelle coden.

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Hmm as far as i know gehen For-Schleifen im Shader schon!

Ist ja auch nicht das Problem, ich hab ja eben dargestellt, das ich mich eher frage ob es Sinn macht den Code im Shader wirklich so aufzublasen, der ist bei einer Lichtquelle schon heftig. Deshalb hab ich ja genau gefragt ob es wie "damals" (wurden mehrere Lichtquellen Grundsätzlich im Frag/Vert-Prog eine pro Pass gerendert und addiert) noch mehr Sinn macht eine Lichtquelle pro Pass zu rendern.

_________________
www.extrawurst.org

Man kann die Lichtpositionen und Farben in einer Texture speichern und dann faktisch beliebig viele Lichter im Fragment Shader verwenden. Dynamische Indices bei Array funktionieren nur im Vertex Shader. Aber wenn du auch Schatten haben willst, wird das ganze natürlich je nach Schattentype mehr oder weniger eingeschränkt.

strukturierte abläufe (if, for, while etc. etc.) unterstützen nicht alle karten. auch kann es sein dass sowas auf nVidia anstandslos läuft und auf ATI keinen Mucks macht. Also am besten testen

(Das war jetzt die Standardantwort zu Shaderprogrammierung)

_________________


"User Error. Replace User and hit Continue."

Also würdest du sagen dass man die gesammte berechnung in einen pass packen sollte, ja ? functioniert bei aktueller hardware auch in akzeptablem tempo ?
guuuuut...
ja schatten, schatten wollte ich eigentlich mit stencil-volumes realisieren, dass lässt sich doch damit kombinieren, oder ?

_________________
www.extrawurst.org

solange der instruction count nicht das maximum für die jeweilige karte übersteigt (bei nvidia karten nicht so das problem, bei radeons eher), wird es vermutlich eher langsamer, wenn das in mehr passes gemacht wird aufgrund der zusätzlichen berechnungen (vertex transform, tiefentests, ...).

Zu den schatten:
ich weiß jetz nich wie du das mit dem kombinieren meinst, zusammen benutzen klappt schon, aber alles in einem renderpass unterzubringen dürfte wohl eher unmöglich sein. Auch die Erzeugung der stencil-volumes ist sone sache, auf der gpu isses zwar afaik möglich, erzeugt jedoch wirklich viele Dreiecke, während bei erzeugung auf der cpu diese doch relativ begrenzend wirkt.
Ich kenne mich allerdings jetzt auch nicht so mit stencil-volumes aus, da ich persöhnlich shadow buffering beforzuge

btw: du weißt aber schon, dass Beleuchtung und schatten direkt wenig miteinander zutun hat?

schon klar, das hat nur in sofern was mit einander zu tun als das die schattiertenbereiche nach dem rendern der shadowvolumes in den stencilbuffer bei der beleuchtung durch die shader irgendwie berücksichtigt werden sollen.
an sich sind es zwei verschiedene paar schuhe schon klar...

und auf gpu wollte ich die volumes eh nich berechnen, lieber klassisch per cpu...
frag mich nur grad ob man den stencil buffer da auch gut befragen kann im shader... kann ich den per shader auslesen ? ich glaub nicht oder ?

_________________
www.extrawurst.org

Okay Lars könntest du mir das mal genauer erklären ? Also ich hätte nun alle angaben zu den verschiedenen lichtquellen per uniformvariablen in den shader geschoben, aber ich denke so meinst du das nicht, oder ?
Kannst du es mir ein wenig genauer erklären ?

_________________
www.extrawurst.org

Im NVidia SDK ist ein Beispiel dazu(Simple NV_fragment_program2). Die Parameter werden einfach in Texturen abgespeichert. Z.B. Position in rgb und Größe in a und in der zweiten Texture dann die Farbe der Lichtquelle abgelegt.

Auszug aus dem Programm:


Das ist allerdings ein NV_fragment_program2 und kein glsl. Mit glsl bekommt man keine solche Schleife hin. Der Compiler fügt unverständlicherweise immer einen dynmischen Sprung hinzu. So eine Schleife ohne dynamische Sprünge ist viel schneller und daher kann man das mit glsl noch nicht so richtig gut machen.

naja super... wollte das eigentlich alles schön mit glsl machen! ;-(
naja werd mal schauen .... müsste das mit den schleifen nich auch bald mal vernünftig von den treibern nterstützt werden ?

_________________
www.extrawurst.org

Hängt das mit der unterstützung nicht auch am Shadermodell( Version )?!?!

In dem Fall muss man sich halt eine X1800 kaufen( Ein Traum einer Graka )!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Nein das hängt bloß am GLSL Compiler. Der HLSL Compiler von D3D erkennt das die Anzahl der Schleifendurchläufe nur von einer uniformen Variablen abhängt und erzeugt den besseren Code.

Hier hatte ich mal ein Thema im OpenGL Forum dazu eröffnet (leider ohne Ergebnis):
http://www.opengl.org/discussion_boards ... 1;t=000698

Aber hängt das nicht vom OpenGL treiber der Grafikkartenhersteller ab wie gut der GLSL-Compiler funktioniert ?

_________________
www.extrawurst.org

Ja, der Compiler ist natürlich im Treiber, aber NV_fragment_program2/PS3.0 unterstützen beide branching basierend auf uniform Variablen und das ist sehr schnell. Daher ist es keine Sache des Shadermodells sondern leider nur ein Softwareproblem, dass hoffentlich irgendwann mal gelöst wird und bereits jetzt funktionieren könnte. Ob man Rücksicht darauf nehmen sollte, muß jeder selber entscheiden. Das Problem ist ja dass man NV_fragment_program2 nur bei GF6600/6800 verwenden kann. Da muß man dann auf jeden Fall noch für die ATI Karten GLSL und für die alten GFFX auch noch eine Lösung finden. Wenn man dagegen für jede Lichtanzahl einen eigenen Shader generiert, ein einfaches #define am Anfang reicht ja, ist das eine weniger schöne Lösung, aber das funktioniert auf mehr Karten besser. Aufpassen muß man allerdings auch dort. Der NVidia Compiler fügt bei der GF6600/6800 selbst in so einem Fall manchmal noch dynamisches Branching ein, wenn die Schleife beim ausrollen zu lang wird. Den Grenzwert kann man bei Cg über Compileroptionen setzen. Bei GLSL gibt's da leider keine Möglichkeit.