Hallo Leute!
Wie ich schon in vorherigen Posts erwähnte, arbeite ich momentan an einer Outdoor-3D-Engine. Weil das Licht eine wichtige Rolle in der Realitätsnähe der Darstellung spielt, habe ich mich entschlossen ebendies zu implementieren.
Das Terrain und die Objekte, die dort statisch herumstehen, sollen Licht als Textur-Layer bekommen, den ich vorher rendere. Dann hätte ich auch direkt schon statische Schatten. Kennt ihr dafür ein Tutorial, ich wüsste nicht, wie ich das auch nur halbwegs vernünftig in meinen Editor implementieren könnte?

Bei dynamischem Licht bin ich mir überhaupt nicht sicher. Diese würde z.B für dynamische Objekte und bewegten Lichtquellen gebraucht. Zuerst hatte ich mir überlegt, das OpenGL-Licht zu nehmen. Aber dann wäre ich doch gezwungen, alle Objekte sehr polygonreich zu gestalten, damit es gut aussieht, oder vertue ich mich? Die Normalen würden ja per Vertex übergeben.
Wären Shader für Licht besser geeignet? Wie siehts dann mit der Performance aus? Ich habe, was Shader angeht, nur absolute Grundkenntnisse.



Habt ihr vielleicht auch andere Ideen, wie ich die beiden Lichtarten einfügen kann?


Vielen Dank!

Ich schätze nun mal, du willst deine statische Lichtquelle als Sonne haben und dynamische Quellen für Lampe und Partikel, Feuer und ähnliches.
Es kommt bei Licht und Schatten völlig auf die Hardwarecaps an, es gibt soviele Techniken aber die brauchen unterschiedliche Hardware.
So kann man z.B. normale Lightmaps verwenden, die auf der älteren Hardware, wie GF2mx geht oder auch schon Vorberechnete AO-Maps mit reinpacken und ist dann bei einer GF7/8 oder x1000/hd2000 schon als minimum angekommen. Dynamisches Licht/Schatten ist noch viel schlimmer, da gibt es locker 20-30 Techniken. Von Shadowmaps, Schadowmaps durch Viewfrustum unterteilt(pssm),Shadowmaps mit Penumbra, mit Shadern ohne Shadern ... SSAO,dynamic AO.

Also entweder festlegen, wie hoch die Qualität sein soll oder welche Hardware es als Zielgruppe hat, dann kann man am besten empfehlungen machen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Jepp, genau so hab ich mir das gedacht.

Die Hardware-Anforderungen sind nicht so wichtig, die können ruhig relativ hoch sein - heutige moderne Standard-PCs. Wenn Shader verlangt sind, ist das okay. Was die Qualität angeht, nun ja, es sollte besser aussehen, als das OpenGL-Licht bei wenigen Polygonen ;) Aber ich kenn mich da halt nicht aus. Für das dynamische Licht würde ich nur ungern Lightmaps benutzen, lieber dynamisch berechnetes Licht.

Sind Shader für die Licht/Schattenberechnung denn halbwegs schnell auf heutiger Hardware?

Für heutige Spiele und eigentlich auch schon für ältere Games(1-2Jährchen) werden nur Shader verwendet, da diese schneller,grafisch besser und flexibler als fixed function alternativen sind.

Lightmaps haben sich hier meines Wissens schon 2-3 Leute intensiv mit beschäftigt, ausser Sascha fällt mir aber gerade kein anderer Name ein ^^.
Grob gesagt, wird bei Lightmaps ein Raster über eine Fläche gespannt und dann per raytracing die einzelnen Segmente aufgehellt.
Dabei ist dann ein Raster eine Textur und ein Segment ein Texel. Wenn man dies für alle Flächen gemacht hat, dann hat man die statische Belichtung der Szene.

Der mix von dynamischen und statischen Lichtern ist nicht schwer(mit ausnahme von deferred Shading xD ) aber das mischen von dynamischen und statischen Schatten ist eine Gradwanderung.
In Spielen wie Stalker oder Crysis gibt es keine statischen Schatten, im eigentlichen Sinne(es gibt vorberechnete Belichtungswerte Werte).
Für eine komplett dynamische Szene wäre aufjedenfall PSSM(parallel split shadow maps) oder eine ähnliche Technik zu empfehlen.
Dabei werden mehere Texturbuffer angelegt, wobei jeder Buffer für ein Bereich des Sichtfeldes zuständig ist.
Man nimmt die Frustumview der Camera und unterteilt diese nach der Entfernung und kann dadurch sehr hoch aufgelöste Schatten realisieren.
Dies kann man auch ohne Shader realisieren http://www.gamedev.net/community/forums/topic.asp?topic_id=399014.
Es gibt noch mehere ähnliche Ansätze und auch ganz andere Varianten, wie Parabolide Shadow Maps(für Sonnenlicht ungeeignet).

Für die dynamischen Lichter kannst du jeweils eine einzelne Shadowmap nehmen, in der Regel haben diese Lichter nur sehr kleine bereiche, wo Sie einfluss haben. Crysis hat z.B. in eine Textur RGBA 4 Shadowmaps gepackt und kann dann auch die 4 Lichter gleichzeitig verarbeiten(benötigt auch weniger texturbindings).
Hier kommen dann die Shader ins Spiel, die die einzelnen Kanäle auslesen und schreiben können.
Von Vorteil ist auch das erfassen der Boundingboxen, der Lichtquellen. So weiss man, welche Lichter überhaupt beachtet werden müssen.
Die Sonne muss immer beachtet werden, aufgrund ihrer großen Leistung aber dynamische Lichter, wie Taschenlampen, Laternen, Feuer und Co haben nicht soviel Kraft und reichen oft nur wenige Meter weit. Man legt also die Lichtstärke fest und daran kann man dann auch eine Boundingbox errechnen, wie weit das Licht effektiv schatten wirft/licht strahlt. Liegt eine Boundingbox ausserhalb der Szene, dann kann man das Licht einfach weg lassen.

Also im großen und ganzen, würde ich als einstieg erstmal einfache Shadowmaps empfehlen, dann PSSM oder ein ähnliches System für die Sonne implementieren und dann erst weiter über den Tellerrand gucken(deferred shading,shader gestützte systeme).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Das problem an dynamisch berechnetem licht mit schatten ist nicht zu unterschätzen. Kaum hat man eine teillösung gefunden kommen zwei bius 3 neue probleme auf einen zu...

Besonders gerichtetes Licht wie von der Sonne is besonders problematisch. Erst shader Model 4.0 karten sind in der lage algorithmen wie cascade shadowmaps mit ausreichend vielen shadowmaps ohne eine endlose multipass schlacht zu verarbeiten.

Ein anderer fall wären pointlights mit shadows: Für dese darf man auf einer Shadermodel 3.0 karte ganze 7x den scene graphen abklappern. 6 um die deph cubemap zu rendern und eine zum beleuchten. Dazu kommt, das depth cubes erst mit SM4.0 / DX10 karten unterstützt werden...

Hat man dann es endlich geschafft Schatten zu implmentieren stellt man fest, dass das der ambiente teil in den Schatten unnaturlich und flach aussieht. Die alternative is ein viel zu dunkles bild. Damit der der ambiente teil wieder halbwegs interresant aussieht wurde ScreenSpace Ambient Occlusion entwickelt, welches aber auf keinerlei physikalischer grundlagen basiert und eigendlich eher eine art Kantenerkennungsalgoritmus ist.
Um das indirekte lich doch noch zu berechnen zu können müsste man es schaffen etwas radiosity ähnliches in realzeit umzusetzten (man kann radiosity immerhin zum erzeugen von lightmaps einsetzten) jedoch stößt man spätestends hier an die grenzen....

Dann kommt noch die berümte frage, deferred renderer oder gewöhnlicher vorwärts renderer. wenn man nur eine tageslichtscene hat ist der vorwärts renderer schneller. Gibt es dort dann jedoch viele verschiedene Lichquellen fangt es damit an, das die anzahl der Schader der modelle/objekte mit der anzahl der verschiedenen lichtquellen multipliziert wird. Zum schluss endet es meist in einer unkontrolliert wachsender menge von schadern die immer langsamer werden.
Besser sieht es beim deferred renderer aus, aber aus API gründen ist es nicht möglich MSAA zu verwenden, immerhin kann man objekte und beöleuchtung sauber trennen. Leider braucht man etwa 60 instructions (SM3.0 karte, eine SM4.0 karte kann es schneller) zum beleuchten eines fragmentes, so das man sich ausrechnen kann das spielbare frameraten nur auf highend system möglich sind.

Grundsätzlich gild, je kompatibler man so einen renderer gestaltet, desto langsamer wird er. Gerade dies ist extrem problematisch, da man es z.B. schaffen könnte die mid/highendkarten der GF6/7 serier zum laufen zu bringen, mit dem Preis, dass die Lowendkarten der GF8 serie unspielbar langsam werden.

Das allerschlimmste zur zeit ist jedoch, das AMD keinerlei SM4.0 relavante unterstützung bietet und OpenGL so quasi auf den stand von 2005 eingefroren wird. Fakt ist, das wenn man sich nicht mit wirklich mit shadern auskennt mit lightmaps sehr gut beraten ist, da so mit relativ einfachen mitteln etwas gut ausehendes realisieren lässt. Der Rechenaufwand den man braucht um eine halbwegs qualitativ ähnliche graphik zu schaffen liegt ungefär 3 (wenn nicht 4) größendordnungen darüber.... (vergleichbar mit der diskusion graphisch guten 2d vs schlechten 3d games) in den 90gern.
(für light mapping benötigt man gerade mal eine multiplikation pro farbkanal und fragment. Um mehrer lichtquellen in einem single pass renderer zu berechnen verbraucht man schnellmal 100 instructions (2größenodnungen), Mit indirektem licht wird man midestends wieder den faktor 10 brauchen....)

_________________
Lumina plattform unabhängige GLSL IDE

Es ist doch auch mit VP/FP möglich, Depth-Cube-Maps auf älteren Grafikkarten zu erstellen. Ich erinner nur mal an die Portal-Engine von Delphi3d.net (
http://www.delphi3d.net/listfiles.php?category=4 - dort hat Tom Nuydens die Schatten auch per Depth-Cube-Maps erstellt - und das bereits anfang 2004, lange vor SM4.0.

Der hat einfach die 4-Byte der RGBA-Werte für ein 4-Byte-Float "missbraucht" und anhand der Demo kann man ja erkennen, dass es funktioniert

Weiß jetzt nicht, ob SM4.0-Karte das auch ohne VP/FP bzw. Shader können, wenn du das sagst, glaub ich dir das erstmal. Aber es ist auch, wenn auch mit Umwegen, möglich, DCM auf älteren Karten zu erstellen.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Danke für eure ausführlichen Antworten! Ich muss sagen, ich hab einiges nicht verstanden :) Gut, ich würde mich gerne mal in Shader-Licht hineinarbeiten. Ich guck mir mal die Tutorials im Wiki an.

Ich würde noch gerne was fragen: Könnte ich die gesamte Beleuchtung mit Shadern machen, oder wäre das hardware-technisch auf heutigen PCs nicht machbar?

Ich habe überlegt ob ich sinnvoll etwas zu Thema beitragen kann oder nicht. Aber ich denke es kann auch nicht schaden, wenn sich ein extremer Technologieabstinenzler zu Wort meldet. Aber bitte den Beitrag nicht als Technologieverweigerung verstehen sondern als Gedankenanregung. Wenn man weiß was man machen will und es das ist was man machen will dann ist das alles okay. Man sollte sich nur nicht von schönen Effekten blenden/verleiten lassen.

Neuste Techniken der Techniken hin oder her. Die Frage ist doch viel mehr was davon in das Konzept der Outdoor Engine past und was nicht? Denn für meine Begriffe ist "Outdoorengine" noch etwas sehr weitreichend. Das kann von einer Natursimulation über einem Strategiespiel (Anno 1701) bis hin zu einem Ballerspiel (UT3, Crysis) führen. Und in allen Fällen muss man den Schwerpunkt etwas anders setzen. Bei Simulationen ist ein großes Maß an Genauigkeit wichtig. Bei Ballerspielen ist es wichtig, dass es nach etwas aussieht. Aus Erfahrung weiß, dass man beim Spielen nicht darauf achtet ob der Schatten physikalen korrekt ist. Und das obwohl mir sonst jedes schiefe Pixel auffällt. Und in einer Draufansicht (Anno) sind die Schatten mehr oder weniger nur noch zur grafischen Untermalung wichtig.

Bei Spielen sollte man aber auch nie außer acht lassen, dass die Stimmung und das Spielgefühl stimmen müssen. Wenn das nicht stimmt, dann sind die besten Schatten, direkt gesagt, fürn popo. Außerdem nicht zu vergessen. Es gibt noch so viele andere Dinge die gemacht werden müssen bevor man überhaupt einen einzigen Schatten sehen kann.

Manche Demos die man auf der ein oder anderen Webseite finden kann sollte man evtl auch mit Vorsicht genießen. Ein konkretes Beispiel ist das "horizon mapping" von Tom Nuydens. Das sieht wirklich klasse aus. Aber die Technik die dort zum Einsatz kommt ist so Speicherintensiv, dass man sie in der Praxis nicht einsetzen kann.


Nichts desto trotz. In aktuellen Spielen wird immer mehr auf die Grafikkarte ausgelagert. Denn die ist viel spezialisierter als die CPU. Und entsprechend auch um ein vielfaches schneller. Allerdings wird in Spielen auch sehr sehr gerne getrickst. Viele Dinge die auf dem Bildschirm wirklich großartig aussehen sind technisch mit einfachen mitteln umgesetzt. Einfach um Zeit einzusparen die man an anderen Stellen wieder einsetzen kann.

Sicher kann man die ganze beleuchtung per shader machen, jedoch stößt man fürher oder später an grenzen, an denen einfach nicht mehr möglich ist. Die OpenGL beleuchtung wird übrigends auch auch intern mit (vertex)shadern realisiert. Eine fixed function pipline gibt es nur noch softwaremäßig.

_________________
Lumina plattform unabhängige GLSL IDE

Die Engine, an der ich herumschreibe, soll für eine Art Adventure dienen. "Outdoor" bedeutet für mich hier auf einem großen frei zugänglichem Gebiet spielend. Es soll halt auf der Erde spielen und somit irgendwie glaubhaft rüberbringen, dass die Umgebung Natur sein soll.
Ich dachte mir, dass Licht in diesem Fall sehr wichtig ist, weil es doch sehr zur Atmosphäre beiträgt. Dynamisches Licht, wie Taschenlampen, Fackeln o.Ä. ist hierbei für mich nicht so wichtig, wie das Tageslicht. Und irgendwie würde ich das gerne implementieren. Die einzige Technik, die mir dafür einfällt, ist Lightmapping - also alles vorrendern und als zweiten Texturlayer setzen. Oder natürlich einfach nur das Ambientlicht und den Himmel anpassen - da weiß ich aber überhaupt nicht, ob das auch einigermaßen aussehen würde. Tatsächlich habe ich heute festgestellt, dass ich das Licht lieber ohne Shader realisieren möchte Ich hab davon nämlich weniger Ahnung, als ich gedacht hatte

Lossy, du hast geschrieben:


Könntest du ein paar dieser Dinge nennen, oder mich wohin verweisen?

Adventure: Hast du mal ein Referenzspiel oder gutes Beispiel. Denn wenn ich an Adventure denke dann fällt mir so was wie Monkey Island ein. Dann wissen die Anderen auch besser worauf du aus bist.

Beispiel: Na ja. Bei großen Outdoor Engines ist das Terrain entsprechend groß. Feststellen der Sichtbarkeiten. Dynamisches Nachladen von Landschaftsteilen. KI, Physik. Und all so etwas. Es geht zwar auch viel Zeit fürs Zeichnen drauf aber wenn man nicht aufpasst, dann kann der Rest auch mal eben zu einem entsprechend großen Häufchen werden.

Ich plane eine Mischung zwischen Adventure und Rollenspiel. Die Wahrnehmung der Umgebung soll Gothic I ähneln, falls ihr das kennt. Also eine rel. große Welt, in der es Tag/Nacht-Zyklen gibt. Ob Third-, oder First-Person weiß ich noch nicht. Das Spiel soll sich größtenteils an Rätseln und zu erledigenden Aufgaben orientieren, jedoch auch Attributsteigerung ermöglichen, und zwei "Fraktionen" haben - als Rollenspielelemente.

Ich denke, ich habe bereits eine solide Grundlage für die Grafik und die Organisation der Welt. Um Skripte, KI und die anderen Sachen, die das Spiel zu einem Spiel machen, möchte ich mich "später" kümmern.

Was ich bereits stehen hab:

- Patchbasiertes Nachladen der Umgebung, also Nachladen in Blöcken. Umgebung ist hier Terrain, welches durch eine Heightmap vorher im Editor kreiert wird. Das funktioniert auch ganz gut - die nachgeladenen und entladenen Patche werden mit Transparenz geblendet.

- Einfaches eigenes Modelformat für statische Modelle. Im Editor können 3ds-Modelle importiert werden. Die Modelle werden wie das Terrain organisiert. Es sind immer nur die nötigsten Modelle geladen.

- Virtuelles Dateisystem, in dem die Dateien komprimiert sind.

- Eine einfache Konsole und eine simples GUI-System, das im Moment noch kein User-Interface ist, sondern nur ein paar Dinge darstellen kann.

- Kollisionskontrolle für das Terrain. Sieht aber im Moment leider nur beim Fallen gut aus Irgendwo hochlaufen ist noch zu ruckelig. Ich werde sicherlich noch einmal einen eigenen Thread hierfür eröffnen

Was ich in den nächsten Monaten machen möchte(Abgesehen von der Verbesserung der obenstehenden Fähigkeiten):

- Dynamische Models

- Effektsystem (Wettereffekte, Partikelquellen(?), ...)

- Vegetation

- Und eben Licht. Und hier bin ich mir immer noch nicht sicher, wie Ich hab mir überlegt, dass man das jeweilige Tageslicht durch Ambient-Licht in OpenGL(oder einfach einer Einfärbung aller Flächen) realisieren könnte. Schwierig fänd ich dann aber unterschiedliche Lichtverhältnisse in Häusern oder Höhlen. Oder brauch ich das nicht, um es gut aussehen zu lassen?


Seit bitte nicht zu streng mit meiner Kreation

Wenn du möchtest könntest du hier doch nen Thread im Projekte forum aufmachen. Natürlich nur, wenn du das Projekt ernsthaft weiterverfolgen willst.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Weiterverfolgen werde ich das auf jeden Fall, dafür steckt bereits zuviel Arbeit drin. Ich wollte es aber erst dort reinsetzen, wenn man auf Screenshots irgendwas vernünftiges sieht ;) Ich kümmer mich mal drum...

Ich denke, wenn du Lightmaps verwendest und dort nicht aus einer Position sondern den ganzen Himmel als leuchtmittel nimmst, dann reicht das zum anfang(siehe Ambien Occlusion). Die Schattierung ist dann erstmal statisch aber du hast ne schattierung und man sieht unterschiede, ob man in einem Raum ist oder draussen, Ecken und Gassen werden auch dunkler schattiert. Mit korrektheit hat das 0 zu tun aber es sieht schick aus und ist wohl die einfachst zu realisierende Lösung.
Über 9millionen WOW Spieler beschweren sich über die Lösung nicht ^^. Gorthic1 und 2 sind die gleiche Engine und haben das auch so geregelt.
Dann kannst du dich mehr auf das beleuchten konzentrieren, welches mit Fragmentshadern und ner Skydome Textur wirklich einfach zu realisieren ist(zum Thema Day/Night Cycle gabs im Forum mehere Posts).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004