Bump-/ Parallax-/ Occlusion Mapping
-
this->that schrieb:
Wie du an die modifizierte Normale kommst hängt vorm Verfahren ab (Heightmap beim Parallaxmapping, Normalmap beim Normalmapping usw.)
heightmap der parallaxmap? ich glaube auch in diesem fall nimmt man immer nur die normalmap.
-
LukasBanana schrieb:
Ich hab noch nie mit BumpMapping gearbeitet, daher ist die Wahrscheinlichkeit sehr hoch, das ich as nicht verstehe ^^
Aber was mich immer etwas skeptisch von Tutorials macht, wenn bei Effekten Berechnungen für jeden Vertex gemacht werden müssen. Das Problem habe ich z.B. beim StencilShadow - der vermutlich auch nicht mehr häufig Verwendung findet in heutigen VideoSpielen.da hast du wohl recht, stencil shadows werden eher weniger benutzt heutzutage, jedoch beduerfen wohl fast alle stencilshadowverfahren dass du ein neues mesh aufbaust, beim bumpmapping machst du nur ein paar berechnungen pro vertex.
Aber was genau soll man bei BumpMapping mit nur einer Koordinate??
gegenfrage, was soll man mit mehr als einer texturkoordinate fuer eine bumpmap?
PS:
@rapso: du scheinst dich in ziehmlich vielen Gebieten der Grafikprogrammierung auszukennen. Hast du schon mal ein Buch geschrieben und veröffentlicht oder ein größeres video Spiel entwickelt? Wenn ja, würde mich das mal brennend interessieren, welches das ist
um buecher zu schreiben hab ich leider keine zeit ;), aber ja, ich hab ein paar groessere videospiele (mit)entwickelt, jedoch liegt mein hauptgebiet auf technologie entwicklung. direkt mit den spielen habe ich weniger zu tun, nur falls es bugs gibt oder optimiert werden muss ;).
jedoch vermische ich privat und berufsleben ungern (faende ich unprofessionell), deswegen behalte ich es fuer mich, tut ja hier nicht viel zur sache ;). Es gibt hier im forum viele die bei sehr bekannten weltfirmen arbeiten, von denen man kaum was erfaehrt
-
So jetzt habe ich zwar bestätigt bekommen, dass ich BumpMapping nicht wirklich verstehe, aber wie es genau funktioniert und vor allem, ob man in jedem Frame des Programms alle Vertices-Texture-Koordinate(n) der Modelle modifizieren muss, die eine BumpMap haben, oder nicht, weiß ich immer noch nicht
Wenn man nur eine Textur-Koordinate braucht, welche Information steht dann da drin? Wie sieht die Berechnung dafür aus? Wie speichert man dann die anderen Informationen: u und v?
Ich habe in ein paar Beispielen, die nicht selbst kompilieren konnte weil der Entwickler derselben vielleicht mit einem viel älteren Compiler arbeitet oder irgend welche Compiler-Einstellungen vorgenommmen hat, die ich nicht kenne, gesehen, dass man BumpMapping mit Combinern und mit Texture Environment Einstellungen vornehmen kann (mit glTexEnv z.B.).
Das Beispiel mit Combiner nutzt eine NormalMap das mit Texture Environement eine Heightmap und das mit Heightmap sieht schöner aus.
Was genau bewirken denn die Einstellungen mit den Texture Environment? Kann mir das vielleicht mal jemand erklären, bitte?
-
ich glaube du schaust bei emboss bumpmapping. das ist veraltet und bringt wird vermutlich erstmal 0 wissen
such nach normalmapping, da gibt es genug tutorials.
-
LukasBanana schrieb:
So jetzt habe ich zwar bestätigt bekommen, dass ich BumpMapping nicht wirklich verstehe, aber wie es genau funktioniert und vor allem, ob man in jedem Frame des Programms alle Vertices-Texture-Koordinate(n) der Modelle modifizieren muss, die eine BumpMap haben, oder nicht, weiß ich immer noch nicht
Kurze Uebersicht zum Verstaendnis:
1. Herkoemmlich berechnet man die Beleuchtung pro Vertex aus gegebener Vertex-Normale und Richtung des auftreffendes Lichts. Es resultiert an jedem Eckpunkt eine Farbe die ueber das Polygon interpoliert werden (alternativ kann aus der gegebenen Richtung die Farbe des auftreffenden Lichts aus einer Environment-Map entnommen werden). Die "Qualitaet" dieser Vorgehensweise haengt stark von der Homogenitaet der Triangulierung ab (ggf zu grobes Sampling um kleine Highlights aufzufangen).
2. "Per-Pixel Lighting" interpoliert/renormalisiert die gegebenen Vertex-Normalen und wendet die Beleuchtung aus 1. pro Pixel an. Die Oberflaeche wirkt dadurch durchgehend "rund".
3. "Normal-Mapping" verzichtet (weistestgehend) auf die Interpolation der Normalen und liesst pro Pixel eine Normale (basierend auf einer geeigneten UV-Unwrap) aus einer 2D-Textur (x,y,z kodiert als r,g,b). Die Normalen koennen dabei in unterschiedlichen Koordinatensystemen (zb. Welt-, Objekt- oder Textur-Raum) definiert sein und erfordern entsprechend eine Umrechnung der Lichtquellenposition(en) bzw der Environmentmap. Insbesondere fuer animierte Geometrie werden Koordinatensysteme pro Vertex definiert (dreht sich ein Polygon zeigen dessen Normalen auch woanders hin). Da die Normalmap "flach" am Objekt anliegt leidet die Wahrnehmung der darzustellenden Hoehenunterschiede unter Winkeln erheblich.
4. "Parallax-Mapping" interpretiert eine Heightmap. Der Strahl von der Kamera zu einem Punkt auf der Objektoberflaeche schneidet die Heightmap tatsaechlich an einem anderen Punkt (beispielsweise wenn man in einer Vertiefung schaut) fuer den dementsprechend andere Textur-Koordinaten gelten die relevant fuer den perspektivischen Eindruck sind.
-
rapso schrieb:
this->that schrieb:
Wie du an die modifizierte Normale kommst hängt vorm Verfahren ab (Heightmap beim Parallaxmapping, Normalmap beim Normalmapping usw.)
heightmap der parallaxmap? ich glaube auch in diesem fall nimmt man immer nur die normalmap.
Beim Standard Parallaxmapping verschiebt man einfach die Texturkoordinate entlang des Viewvektors, basierend auf einem Höhenwert (der aus der Heightmap gelesen wird). Natürlich kann man das auch theoretisch mit ner Normalmap machen.
-
this->that schrieb:
rapso schrieb:
this->that schrieb:
Wie du an die modifizierte Normale kommst hängt vorm Verfahren ab (Heightmap beim Parallaxmapping, Normalmap beim Normalmapping usw.)
heightmap der parallaxmap? ich glaube auch in diesem fall nimmt man immer nur die normalmap.
Beim Standard Parallaxmapping verschiebt man einfach die Texturkoordinate entlang des Viewvektors, basierend auf einem Höhenwert (der aus der Heightmap gelesen wird).
um dann aus der normalmap zu lesen
Natürlich kann man das auch theoretisch mit ner Normalmap machen.
nein, kann man leider nicht, eine normalmap gibt dir leider keine information mehr ueber die hoehe und entsprechend kannst du damit keinen parallaxeffekt errechnen.
-
rapso schrieb:
um dann aus der normalmap zu lesen
Das hat nichts mit dem Parallaxmapping an sich zu tun. Beim Parallexmapping gehts im Grunde nur um die Modifizierung der Texturkoordinaten (eben basierend auf ner Heightmap). Man wird danach meistens zusätzlich nochmal eine Normalmap samplen, um eine realistischere (falls man das bei diesen Verfahren überhaupt sagen kann
) Beleuchtung zu bekommen. Zwingend notwendig is das jedoch nicht.nein, kann man leider nicht, eine normalmap gibt dir leider keine information mehr ueber die hoehe und entsprechend kannst du damit keinen parallaxeffekt errechnen.
Ich kann doch einfach die Länge der Normalen zur Verschiebung benutzen.
-
this->that schrieb:
rapso schrieb:
um dann aus der normalmap zu lesen
Das hat nichts mit dem Parallaxmapping an sich zu tun. Beim Parallexmapping gehts im Grunde nur um die Modifizierung der Texturkoordinaten (eben basierend auf ner Heightmap). Man wird danach meistens zusätzlich nochmal eine Normalmap samplen, um eine realistischere (falls man das bei diesen Verfahren überhaupt sagen kann
) Beleuchtung zu bekommen. Zwingend notwendig is das jedoch nicht.damit widersprichst du dir:
Wie du an die modifizierte Normale kommst hängt vorm Verfahren ab (Heightmap beim Parallaxmapping
also stimmst du nun zu dass man ueber die heightmap keine normale bekommt?
nein, kann man leider nicht, eine normalmap gibt dir leider keine information mehr ueber die hoehe und entsprechend kannst du damit keinen parallaxeffekt errechnen.
Ich kann doch einfach die Länge der Normalen zur Verschiebung benutzen.
die laenge der normalen ist 1. es wird auch vermutlich niemand die qualitaet der normale verschlechtern indem er deren laenge kuerzt, du wuerdest ansonsten in tiefen bereichen extrem schlechte beleuchtung haben.
-
rapso schrieb:
also stimmst du nun zu dass man ueber die heightmap keine normale bekommt?
Ok dann haben wir wohl aneinander vorbeigeredet. Ich dachte du wolltest sagen, dass man den Texture Offset per Normalmap berechnet.
die laenge der normalen ist 1. es wird auch vermutlich niemand die qualitaet der normale verschlechtern indem er deren laenge kuerzt, du wuerdest ansonsten in tiefen bereichen extrem schlechte beleuchtung haben.
Die Länge kann jeden beliebigen Wert annehmen und für die Beleuchtung kann ich sie ja renormalisieren. Wird nur niemand machen und der Ablauf läuft immer hinaus auf ein: heightmap samplen mit (u,v) => (u',v') berechnen => Normale N berechnen durch Samplen der Normalmap bei (u', v') => Diffuse Texture Color C per (u',v') samplen => Finale Farbe aus C, N+Beleuchtungsmodell berechnen.
-
this->that schrieb:
rapso schrieb:
also stimmst du nun zu dass man ueber die heightmap keine normale bekommt?
Ok dann haben wir wohl aneinander vorbeigeredet. Ich dachte du wolltest sagen, dass man den Texture Offset per Normalmap berechnet.
die laenge der normalen ist 1. es wird auch vermutlich niemand die qualitaet der normale verschlechtern indem er deren laenge kuerzt, du wuerdest ansonsten in tiefen bereichen extrem schlechte beleuchtung haben.
Die Länge kann jeden beliebigen Wert annehmen und für die Beleuchtung kann ich sie ja renormalisieren.
das wird die quantitisierung nicht aufheben, es wird sehr schlecht aussehen wo die normale kurz ist.
Wird nur niemand machen und der Ablauf läuft immer hinaus auf ein: heightmap samplen mit (u,v) => (u',v') berechnen => Normale N berechnen durch Samplen der Normalmap bei (u', v') => Diffuse Texture Color C per (u',v') samplen => Finale Farbe aus C, N+Beleuchtungsmodell berechnen.
jap, normale aus normalmap, egal ob parallax oder nicht.
-
Ich habe die letze Zeit noch etwas anderes gemacht, aber jetzt will ich mich noch mal stärker mit BumpMapping auseinander setzen.
Ich habe in zwischen in Erfahrung gebracht, dass es im groben Überblick 3 Arten von BumpMapping gibt (ohne ParallaxMapping mit zu zählen natürlich):
- Emboss Bump Mapping (hässlich, langsam, kompliziert)
- DOT3 Bump Mapping (schön, schnell, teilweise kompliziert)
- Environmental Bump Mapping (sehr schön - wird in den meisten Shootern verwendet, relativ schnell, kompliziert)Mit den Angaben in den Klammern dürft ihr mir gerne widersprechen, wenn ihr es besser wisst
Ich interessiere mich für DOT3 Bump Mapping weil ich gelesen habe, dass das sehr schön ist und vor allem schnell, da es komplett von der Grafikkarte berechnet wird.
So weit ich bisher weiß, muss man das über die Texture Umgebung und einige Combiner einstellen. In OpenGL mit "glTexEnv" aber ich habe keine Ahnung was man mit dem glTexEnv Parametern alles einstellt.
Ich habe zwar schon einbischen damit herumgespielt aber so wirklich verstehen tue ich das noch nicht.Wäre vielleicht jemand von euch so freundlich und erklärt mir mal die Grundsätze dieser unzähligen Paremtern oder gibt mir einen Link, zu einem guten Tutorial was das angeht??
Danke schon mal
-
LukasBanana schrieb:
So weit ich bisher weiß, muss man das über die Texture Umgebung und einige Combiner einstellen.
Zwischenzeitlich hat man aber GLSL erfunden.
-
Du würdest doch nicht ernsthaft die gesammte Welt mit Shader zuhaufen um alles mit BumpMapping darzustellen?? Ich glaube nicht, dass in dem Shooter HL2 alles mit Shadern gelöst ist, oder?!
-
Du würdest doch nicht ernsthaft die gesammte Welt mit Shader zuhaufen um alles mit BumpMapping darzustellen??
Welchen Zusammenhang hat denn diese Frage mit meinem Verweis auf Shader?
"Shader" sind nichts weiter als eine Verallgemeinerung der Register-Combiner.
Generell kann man davon ausgehen, dass der Treiber einer aktuellen Grafikkarte einen gegebenen Shader-Source erheblich besser optimieren kann als ein vergleichbares Combiner-Konstrukt weil es kaum noch Zusammenhang zwischen Hardware und Texture-Stages gibt.
Im Falle von HL2 gibt es jeweils ein "fallback" Material dass zum Einsatz kommt wenn die Hardware keine Shader unterstuetzt. Darueber hinaus macht man wohl umfangreichen Gebrauch von Shadern.
-
LukasBanana schrieb:
Du würdest doch nicht ernsthaft die gesammte Welt mit Shader zuhaufen um alles mit BumpMapping darzustellen??
wieso sollte man das anders machen?
Ich glaube nicht, dass in dem Shooter HL2 alles mit Shadern gelöst ist, oder?!
doch, ist es wie du hier lesen kannst. warum sollte es anders sein?
-
Nun wenn das so ist, muss man aber auch das Multitexturing, Beleuchtung usw. im Shader alles selbst programmieren, oder?!
Macht es dann eigentlich einen Performance Unterschied, ob man HighLevel Shading Languages benutzt (HLSL, GLSL) oder einfache Vertex Programme (bin nicht sicher ob die so heißen, Assembler Shader so zu sagen)??
-
LukasBanana schrieb:
Nun wenn das so ist, muss man aber auch das Multitexturing, Beleuchtung usw. im Shader alles selbst programmieren, oder?!
ja, das muss man ueblicherweise, aber soviele unterschiedliche sind es meistens nicht.
Macht es dann eigentlich einen Performance Unterschied, ob man HighLevel Shading Languages benutzt (HLSL, GLSL) oder einfache Vertex Programme (bin nicht sicher ob die so heißen, Assembler Shader so zu sagen)??
wenn man sich super auskennt, kann man in assembler die besten resultate erziellen, aber das kostet sehr viel zeit und kaum einer hat in der oeffentlichkeit zugang zu den ganzen details der hardware um das zu koennen, somit sollte man sich auf den compiler und treiber verlassen.
da du wohl d3d und ogl benutzt, empfehle ich dir nvidia's CG als shadersystem. das ist HLSL compatibel (weitesgehend) und laeuft auf beiden APIs.
-
Cg ist aber von nVidia, läuft das auch auf ATI Karten?
-
läuft das auch auf ATI Karten?
Cg kann sowohl GLSL als auch HLSL erzeugen.
Wenn man aber ohnehin nur eine API nutzt ist es Umweg.wenn man sich super auskennt, kann man in assembler die besten resultate erzielen
Was dann darauf hinaus laeuft, dass man fuer jede GPU-Architektur einen anders optimierten Assembler-Shader hat. Der Vorteil gegenueber "Hochsprachen"-Shadern ist gering.