Diffuses Bumpmapping ist einfach: Lichvektor dot PerPixelNormale. Halt das gleiche was man sonst per Vertex macht pro Pixel. Dann muß man natürlich zusätzlich noch die Lichtentfernung berücksichtigen. Das wird ab der GeForce1 unterstützt. Lightmap entfällt und auch eine Detailtexture ist aufgrund der Bumpmap nicht mehr so nötig und auch schwerer unterzubringen.

Texture0: Bumpmap
Texture1: Cubemap
Texture2: Basis Texture
Texture3: 3D-Texture mit Lichintensität

Dieses Shadersystem muß man von deinem oben geannten, das dem von Quake 3 ähnelt unterscheiden, denn diese 4 Texturen werden für jedes Licht einmal rendert. Das heißt du speicherst für jeden Shader nicht beliebig viele Schritte sondern nur die diffuse Texture und die Bumpmap.

Zusätzlich kann man für jede Texture natürlich auch noch eine Texture definieren die die Grundhelligkeit enthält. Dies ist z.B. für Lampen nützlich, die ja immer hell sind.

Das Rendern geht also so:

Grundhelligkeit zeichnen

für jedes Licht
begin
Stencil Schatten zeichnen
glblendfunc(gl_one,gl_one)
Texture0: Bumpmap
Texture1: Cubemap
Texture2: Basis Texture
Texture3: 3D-Texture mit Lichintensität
end;

True Environement Bump Mapping ist ähnlich wie das normale Environment Mapping mit einer Cubemap, nur das hier die Normale nicht von dem Vertex genommen wird, sondern aus einer Normalmap gelesen wird.

Nachdem man die Lichter alle zeichnet hat kann man natürlich noch weitere Effekte danach definieren, z.B. dieses Environment Mapping oder so weitere Blend Effekte wie z.B. bei einem Monitor.

Ich würde nur ein paar Texturekoordinaten pro Vertex benutzen, denn alle weiteren kann man auch in einem Vertex Program erzeugen, wenn man jedem Shader Schritt noch eine Texture Matrix zuordnet.

Die 3D Texture mit Licht, ist doch einfach ne Lightmap oder ?
Und was ich noch nich gerafft habe, wie ich den Lichtvector einer Bumpmap entsprechend der Lightpositionen berechnen muss. Habe bis jetzt immer das Bumpmapping gemacht wies im Tutorial von DGL beschrieben ist und über glColor3f am anfang definiert wie es aussehen soll.
Hab einfach zum testen mal glColor3f(0.7,0.65,0.75); genommen und es sieht gut aus, aber es bewegt sich ja nichts.

Wegen dem Vertex Program, hmm... da ich das CG zeugs überhaupt nicht raffe... nich mal ansatzweise werd ich vorerst damit gar nix machen. Normales Bumpmapping über Register_Combiners, das bekomm ich grad so hin.

Und wegen dem Stencil Schatten, also ich habs schon hinbekommen... nen Raum (Würfel) zu zeichnen in dem sich zwei säulen befinden und ne Lichtquelle in dem Würfel rumfliegt.
Der Schatten wird dabei immer auf den Würfel Projeziert, aber wenn z.b. der Schatten eigentlich die andere säule überdecken sollte ist dies nicht der fall und wenn ich die zwei säulen in die Schattenmatrix adde, dann ist auf einmal alles schattiert.

Eigentlich nicht.Die 3D-Lichttextur ist quasi ne volumetrische Repräsentation der Lichtquelle im 3D-Raum, und ist weitaus flexibler als eine Lightmap.Ne Lightmap wird je für jedes Face in der Szene vorberechnet und ist somit nur sehr eingeschränkt dynamisch (z.B. Licht aus bzw. Licht an).Licht via 3D-Textur speichert aber die volumetrische Lichtrepräsentation und ist somit unabhängig von deiner Levelgeometrie und somit kann man die Lichtquelle dynamisch bewegen ohne die Lichttextur neu berechnen zu müssen.Auf <a href='http://www.delphi3d.net' target='_blank'>http://www.delphi3d.net</a> gibts dazu übrigens ein gutes Beispiel.
Nachteil dieser Methode ist allerdings die Tatsache, das 3D-Texturen erst ab der GF3 in Hardware unterstütz werden.Wenn du dir z.B. Tom Nuydens Demo mal auf ner GF2 ansiehst, wirds dir wie ne Diashow vorkommen.Also würde ich diese Funktionialität optional machen, den schliesslich soll deine Engine ja auch auf älteren Grafikkarten ansehnliche Beleuchtung darstellen können.Da bleibt dir nix anderes als Lightmapping übrig.


Bitte lass die Finger von cG und warte bis OpenGL2.0 mit seiner eigenen HLSL (glSlang) rauskommt, damit du weitgehend herstellerunabhängig bleiben kannst.Denn wenn du dich bei deiner Engine auf cG stützt um bestimmte Effekte darzustellen, bleiben Nutzer von non-nVidiakarten aussen vor!


Fürs Erste würde ich dir eh zu Shadowmaps raten, die du in einem direkt mit deinen Lightmaps berechnen kannst und auch dort abspeicherst.Die sind zum einen weicher als Stencilschatten und kosten v.a. bei statischen Schatten weitaus weniger Leistung.
Die Berechnung geht auch sehr einfach, wenn Lightmappingberechnungen bereits implementiert sind : Wenn du den Wert eines Lumels berechnest, hast du ja auch die Linie die zwischen der Lichtquelle und diesem Lumel läuft.Dann prüfst du einfach ob auf dieser Linie irgendwo eine Kollision mit deiner Levelgeometrie stattfindet.Ist dies der Fall, dann setzt du diesen Lumel auf Schwarz (oder besser den globalen Lichtfaktor).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Jo ich werd kein CG nehmen, raff das ja gar nich.
Wegen den Schatten, müssen die schatten dann extra ne Texture haben, oder kann man das irgendwie in die Light Texturen packen, wenn ja, muss ich zuerst die schatten machen und dann die lichter ? oder umgekehrt ?

Werd heute mal anfangen nen Gerüst zu bauen.

matane,
Final

Die Antwort auf diese Frage habe ich dir oben doch bereits schon gegeben.Du verbindest die Berechnung der Lightmaptextur mit deiner Schattenberechngung (wie oben gesagt ist das nur ne simple Kollisionsabfrage) und setzt dann den Farbwert eines jeden Lumels der im Schatten liegt (sprich : dessen Linie zur Lichtquelle hin mit deiner Geometrie kollidiert) auf den Wert deines globalen Lichtes bzw. komplett schwarz.

So hast du Schattenberechnung und Lightmapgeneration in einem Durchgang erledigt, und sparst natürlich auch Speicher da dein Schatten ja in deiner Lightmap gespeichert ist.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Sach mal, gibt's zu den Lighmaps eigentlich irgend wo gute Tutorials? Denn wenn ich das richtig sehe, benötigt man pro Triangle ein Textur. Sicher, die sind klein und werden allesamt auf einer Großen untergebracht, aber mit steigender Levelgröße explodiert der Texturen-Verbrauch an Speicher ziemlich Stark durch diese Lightmaps, oder? So Dinge wie ganz hell und ganz dunkel kann man ja teilen und braucht es nur einmal und dann gibt es noch S3TC aber das macht es nicht wirklich arg viel weniger...

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Wenn du jede Texture Pixelgenau überprüft nachdem erstellen (Mit den vorhanden prüfen), dann kannst du ja ganz leicht doppelte, dreifache texturen vermeiden. Ich hab das schon gemacht funzt ganz gut, und anstatt 8 Texturen für ein halben würfel hab ich nur 2 texturen kommt aber auch immer auf die Licht Positionen an.

Leider hab ich mir aber irgendwie was verhunzt, weil meine lightmaps werden zwar richtig berechnet, kommen aber irgendwie invertiert auf mein Face.

Wegen Lightmapping Tut, schau mal in den Thread "Radiosity Lighting".
Da gibts das PDF Doku als link und von mir den kompletten source um radiosity lighting zu berechnen.
Wobei auch noch mein problem mit den invertierten faces erläutert ist.

Hier das testapp aus meiner engine die ich vor 2 wochen angefangen habe, aber wieder aufgegeben habe.
<a href='http://encorex.no-ip.com/shared/Final/radical3d_radiosity.zip' target='_blank'>http://encorex.no-ip.com/shared/Final/radi...d_radiosity.zip</a>
User mit Nvidia Karten >= GeForce 3 können sich auch das Bumpmapping anschauen.
In der version wird aber das mit den überprüfen noch nicht gemacht, da werden texturen doppelt und dreifach erstellt

matane,
Final

Die 3D Texture mit der Lichtintensität kann auch durch 2 2D Texturen ersetzt werden. Das ganze Doom3 mäßige Bumpmappnig geht ab einer GF1. Ob das aufgrund der Geschwindigkeit Sinn macht ist aber fraglich mehr als ein 2-3 gebumptmapter dynamischer Lichter wird damit auf einer GF1 wohl nicht möglich sein.

Zu Vertex Programmen. Man muß weder CD noch glslang nehmen, sondern es gibt doch auch ARB_VERTEX_PROGRAM. Diese Erweiterung ist übrigends wesentlicher einfacher als Register Combiner, da man einen Text String als Programm übergibt. Register Combiner sind natürlich Pixel-Shader aber das Prinzip die HW zu programmieren ist das gleiche.

Der cG Compiler compiliert auch zu ARB_VERTEX_PROGRAM und ARB_FRAGMENT_PROGRAM und nicht nur zu NVidia Extensions.

So ich hab mir jetzt mal nen gerüst erstellt und würde gerne mal wissen, was ihr davon haltet...
Ich hab mich voll und ganz auf MultiTexturing beschränkt... und lass das mit den 2, 3 passes einfach weg.
Jetzt kommen natürlich viele fragen wieder von mir:

Also erstens... ich hab wieder ne Radiosity berechnung drin. Funzt ganz gut, bis auf eine kleine fehlberechnung. Meine Texture Koordinaten, sind irgendwie verdreht... kurzes beispiel, damit man es versteht:

Also die 2 Faces sind auf XY Plane.
Quader 4x4, 2 Polygone, mit Normale (0,0,1);
Der Z Wert ist 0.

LichtPosition (0,0,2): (Ist korrekt)

Zugehörige Lightmap:

LichtPosition (0,2,2): (nicht korrekt)

Zugehörige Lightmap:

LichtPosition (2,0,2): (nicht korrekt)

Zugehörige Lightmap:

LichtPosition (2,2,2): (korrekt)

Zugehörige Lightmap:

Irgendjemand eine Idee, wie ich jetzt die Texture Koordinaten anpassen muss, damit das ganze passt ?

Wie ich an der Lightmap sehe, ist diese in der Y Achse Invertiert, also müsste man das Einfach nur Vertikal spiegeln, oder ? Oder wärs sinnvoller die Texture Koordinaten anzupassen ?

Die Texture Koordinaten, werden übrigens über Planarmapping was mir SonOfSatan erklärt hat, berechnet. Ganz easy

Komisch ist aber das 4 Beispiel, funzt ... hmm..

Ich kann auch wenns so nicht verständlich ist, den source posten (Als ZIP versteht sich).
Ich hab die Binary des Templates mal hochgeladen, somit könnt ihr das mal Dynamisch in Aktion sehen.

<a href='http://encorex.no-ip.com/shared/Final/radical3d_0.04alpha_bin_template.zip' target='_blank'>Radical3D 0.04 Alpha Template</a>

matane,
Final

Ich kann mir nicht helfen. Aber irgendwie werde ich das Gefühl nicht los, dass du X und Y (S und T) vertauscht hast!
Sobald dein Licht recht ist, ist die Textur oben.
Sobald dein Licht oben ist, ist die Textur recht.

Thx lossy, this works

So simpel her, heute kann ich irgendwie nich klar denken.
Es gibt Tage, da sollte man das coden lieber lassen.

Jetzt muss ich nur noch gucken... ob Plane YZ und XZ auch falsch sind.

Wenn das dann funzt, dann kommts an die Statische Schattenberechnung, was laut SOS easy sein soll.

Ich mach einfach nen würfel, dann kann ichs am besten testen

matane,
Final

So endlich mal ein erfolgserlebnis:

- Lichtberechnung funzt jetzt endlich
- Hab mir nen einfaches Shadersystem gebastelt

Hier mal screenshot + Binary:


<a href='http://encorex.no-ip.com/hosted_sites/radical3d/shared/files/radical3d_0.06alpha_game_template_bin.zip' target='_blank'>radical3d 0.06 alpha game template</a>

Zur Info:
Die Lichter sind in dem Würfel drin ;D

Als nächsten schritt, wäre es die welten aus einem Dateiformat zu lesen, vorerst nur ascii... später dann binär. Danach müsste ich mich mal ranwagen, ans Terrain Rendering

matane,
Final

@Snape ich habe CreativeMindMap von DataBecker benutzt. Das ist allerdings nicht wirklich gut für solche Diagramme sondern eher für MindMaps gedacht. Man kann damit hauptsächlich Felder und Pfeile dazwischen zeichnen.

Weiß jemand anderes vielleicht ein Programm, das Diagramme direkt aus dem Quelltext erzeugt?

Ich hab auf Sourceforge eines gefunden: <a href='http://sourceforge.net/projects/essmodel/' target='_blank'>Eldean Ess-Model</a>.
Allerdings erstellt das wirklich nur Diagramme aus dem Sourcecode.
Würde aber gerne einen UML-Designer haben. Damit kreeiert man zuerst das Diagramm und anhand von dem erzeugt er dann den Quellcode. Funktionen proggen und basta.

_________________
Ever stop to think and forget to start again?