DGL :: Thema anzeigen - Multiple Lightsources

DGL https://delphigl.com/forum/

Multiple Lightsources https://delphigl.com/forum/viewtopic.php?f=20&t=4804	Seite 1 von 2

Autor:	Extrawurst [ Fr Nov 04, 2005 12:26 ]
Betreff des Beitrags:	Multiple Lightsources
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]

Autor:	La Boda [ Fr Nov 04, 2005 12:31 ]
Betreff des Beitrags:
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.

Autor:	Extrawurst [ Fr Nov 04, 2005 12:39 ]
Betreff des Beitrags:
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.

Autor:	LarsMiddendorf [ Fr Nov 04, 2005 14:51 ]
Betreff des Beitrags:
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.

Autor:	luketheduke [ Fr Nov 04, 2005 15:11 ]
Betreff des Beitrags:
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)

Autor:	Extrawurst [ Fr Nov 04, 2005 15:11 ]
Betreff des Beitrags:
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 ?

Autor:	Grizzly [ Fr Nov 04, 2005 15:23 ]
Betreff des Beitrags:
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?

Autor:	Extrawurst [ Fr Nov 04, 2005 16:02 ]
Betreff des Beitrags:
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 ?

Autor:	Extrawurst [ Sa Nov 05, 2005 01:41 ]
Betreff des Beitrags:
LarsMiddendorf hat geschrieben: Man kann die Lichtpositionen und Farben in einer Texture speichern und dann faktisch beliebig viele Lichter im Fragment Shader verwenden. 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 ?

Autor:	LarsMiddendorf [ Sa Nov 05, 2005 09:17 ]
Betreff des Beitrags:
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: Code: # loop over lights MOV color, ambientColor; MOV lightIndex.x, 0.0; REP nlights; # get light position and color from texture TEXC lightPos, lightIndex, texture[0], RECT; # write condition code TEX lightColor, lightIndex, texture[1], RECT; # call correct lighting function based on w component of position IF EQ.w; # lightPos.w == 0.0 CAL dirlight; ELSE; CAL pointlight; ENDIF; ADD lightIndex, lightIndex, 1.0; # increment loop counter ENDREP; MOV result.color, color; RET; 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.

Autor:	Extrawurst [ Sa Nov 05, 2005 13:54 ]
Betreff des Beitrags:
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 ?

Autor:	Speedmaster [ Sa Nov 05, 2005 14:26 ]
Betreff des Beitrags:
Extrawurst hat geschrieben: 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 ? 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 )!

Autor:	LarsMiddendorf [ Sa Nov 05, 2005 20:50 ]
Betreff des Beitrags:
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

Autor:	Extrawurst [ Sa Nov 05, 2005 21:20 ]
Betreff des Beitrags:
Aber hängt das nicht vom OpenGL treiber der Grafikkartenhersteller ab wie gut der GLSL-Compiler funktioniert ?

Autor:	LarsMiddendorf [ Sa Nov 05, 2005 21:30 ]
Betreff des Beitrags:
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.

Seite 1 von 2	Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/