Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Jul 18, 2025 19:23

Foren-Übersicht » Programmierung » Shader
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 25 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
BeitragVerfasst: Sa Jan 01, 2011 15:30 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
Ich versuch momentan so was ähnliches, wie das: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter02.html
zu machen, aber es will nicht so ganz.
Also, beim niedrigsten LOD sieht es ziemlich genau so aus, wies aussehen soll. Bei LOD 1 siehts auch noch so aus wies soll.
Bei LOD 2 bilden soch solche Muster:
Code:
1  1  1
1  0  1
0  1  1
, wobei 1 weiß repräsentiert und 0 schwarz, und dazwischen wird linear interpoliert. Also von 9 Vertices sind je zwei schwarz, der Rest ist weiß. Das bildet so ein hässliches sechseckmuster, das sich ständig wiederholt. Grund dafür dürfte die Berechnung der Normale sein, aber ich finde den Fehler nicht.

Bei LOD 3 bis 5 (und nachher wahrscheinlich auch noch, hab aber nicht mehr als 6 LOD Stufen) sieht es ähnlich aus, nur das das Muster (das sich nachwievor ständig wiederholt) etwas komplexer wird.

Dazu kommt, dass sich zumindest bei LOD 5 und 4 Treppen bilden. ("runter" gehts nach links) Aber die Texturen sind alle kachelbar.

Vertexshader:
Code:
#version 130

smooth out vec4 vColor;
smooth out vec3 vNormal;
uniform vec4 Transformations;
uniform mat3 Model;
uniform sampler2D heightmap;
uniform sampler2D NoiseTex;
uniform float BaseLOD;

const float reciprocal_size = 1.0 / 127.0;
const float scale_hmap_4 = 1.0 / 4096.0;
const float scale_noise_2 = 1.0 / 1024.0;

vec4 GetHeight(vec2 Coord, float LOD) {
  vec4 result = texture(heightmap, Coord * scale_hmap_4) * 256.0;
  for (float i = 0.0; i < LOD; ++i) {
    result += (texture(NoiseTex, Coord * scale_noise_2 * exp2(i)) - 0.5) * 8.0 / exp2(i) * min(LOD - i, 1.0);
  } 
  return result;
}

vec3 GetNormal(vec2 Coord, float LOD) {
  vec3 Normal;
  Normal.x = (texture(heightmap, (Coord + vec2(1.0, 0.0)) * scale_hmap_4).r - texture(heightmap, (Coord + vec2(-1.0, 0.0)) * scale_hmap_4).r) * 256.0;
  Normal.z = (texture(heightmap, (Coord + vec2(0.0, 1.0)) * scale_hmap_4).r - texture(heightmap, (Coord + vec2(0.0, -1.0)) * scale_hmap_4).r) * 256.0;
  for (float i = 0.0; i < LOD; ++i) {
    Normal.x += (texture(NoiseTex, (Coord + vec2(1.0, 0.0) * scale_noise_2 * exp2(i))).r - texture(NoiseTex, (Coord + vec2(-1.0, 0.0) * scale_noise_2 * exp2(i))).r)
      * 8.0 / exp2(i) * min(LOD - i, 1.0);
   Normal.z += (texture(NoiseTex, (Coord + vec2(0.0, 1.0) * scale_noise_2 * exp2(i))).r - texture(NoiseTex, (Coord + vec2(0.0, -1.0) * scale_noise_2 * exp2(i))).r)
     * 8.0 / exp2(i) * min(LOD - i, 1.0);
  }
  Normal.y = 1.0;
  return normalize(Normal);
}

void main() { 
  vec3 World = Model * gl_Vertex.xzw;
  vec2 TexCoord = World.xy * 0.5 + 0.5;
  World.xy -= Transformations.xy; 
  World.xy *= Transformations.zw; 
  float LodStep = clamp((1.0 - max(abs(World.x), abs(World.y)) * reciprocal_size) * 4.0, 0.0, 1.0);
  vColor = gl_Color * LodStep;
  vec4 Vert = gl_Vertex;
  float lod = BaseLOD + LodStep;
  Vert.y = GetHeight(TexCoord, lod).r;   
  vNormal = GetNormal(TexCoord, lod);
  gl_Position = gl_ModelViewProjectionMatrix * Vert;
}


Den Fehler vermute ich jeweils innerhalb der for - Schleifen, hab aber keine Ahnung, was falsch sein könnte. heightmap ist übrigens 1024x1024 groß, und NoiseTex ist 512x512 groß.


edit: eigenartig. Beide probleme treten auch auf, wenn ich LOD abschalte (also immer = 0)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Jan 02, 2011 11:12 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
ok, das ganze wird irgendwie immer eigenartiger. Die Treppen konnte ich entfernen, indem ich mir meine Daten mit texelFetch hole, und die Interpolation dann selber mache (texture scheint nicht so ganz zu funktionieren). Die merkwürdigen Normalen dürften dieselbe Ursache haben, nur entfernen lassen sie sich nicht. Wenn ich nämlich irgendetwas am Code zur Berechnung der Normalen ändere, wird auch die Höhe falsch berechnet :?: Wenn ich die Berechnung der Normale auskommentiere, wird auch die Höhe nicht mehr berechnet. Dabei werden Höhe und Normale doch eigentlich unabhängig voneinander berechnet. Im Anhang der aktuelle shadercode.


Dateianhänge:
Terra_vert.txt [4.55 KiB]
423-mal heruntergeladen
Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Jan 02, 2011 11:30 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Also bei deiner Normale-Berechnung ist irgendwie der Wurm drin. Wie schaffst du es ohne Kreuz-Produkt eine Normale zu berechnen. Und Normal.y = 1.0, wo doch x und z in der Größenordnung von 0-256 sind. Hä ?! :shock:
Y ist doch die Höhe in deinem Koordinatensystem? Ggf. schaust du dir an wie mein Terrainshader (Shadersammlung) die Normale berechnet.

Hab mich jetzt aber nicht lange damit beschäftigt, vielleicht blicke ich auf die schnelle auch nur nicht durch.

_________________
Yeah! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Jan 02, 2011 16:14 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
Dass meine Normalenberechnung nicht die richtige Normale ausspuckt, ist klar. Die Überlegung dahinter war einfach, dass mit dy/dx auch die x - koordinate der Normale größer/kleiner wird (und bei 0 ist sie 0) da das ganze nicht linear ist sind meine Normalen wohl falsch. (ich muss zugeben, ans Kreuzprodukt hab ich zuerst gar nicht gedacht)
Nur das eigentliche Problem ist ja momentan nicht, dass die Normale falsch ist (das, was da notwendigerweise falsch sein muss, wäre sogar noch ziemlich egal), sondern, dass ich die Normalenberechnung nicht ändern kann, ohne dass die Höhenberechnung falsch wird, obwohl beides unabhängig voneinander implementiert ist.

ps: die x und z koordinaten gehen übrigens nicht von 0 bis 256 sondern von -256 bis 256. und das stimmt schon so, weil ja normalize(Normal) ;)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Jan 02, 2011 16:47 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Zitat:
ps: die x und z koordinaten gehen übrigens nicht von 0 bis 256 sondern von -256 bis 256. und das stimmt schon so, weil ja normalize(Normal) ;)

Nein....bei einem Terrain zeigen die meisten Normalen in etwa nach oben. D.h. y ist die dominierende Achse. Wenn x und z aber in der Gegend von 256 sind, kannst du ein y=1 bald vernachlässigen. Die Normalen zeigen also alle irgendwie zur Seite.

Bist du den sicher, dass die Höhenberechnung überhaupt stattfindet und du nicht nur irgendeinen Effekt siehst der durch die Beleuchtung erzeugt wird?

_________________
Yeah! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Jan 02, 2011 17:34 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
Coolcat hat geschrieben:
Nein....bei einem Terrain zeigen die meisten Normalen in etwa nach oben.
Bei meinem Terrain auch. -256 und 256 sind maximal bzw minimalwerte. Praktisch wird man das aber nirgends finden. Aber es stimmt natürlich, dass meine Normalen zu flach sind. (und wenn ichs mir recht überleg, sollten die 256 eher 64 sein, weil ich die Heightmap ja auch in xz skaliere)

Coolcat hat geschrieben:
Bist du den sicher, dass die Höhenberechnung überhaupt stattfindet und du nicht nur irgendeinen Effekt siehst der durch die Beleuchtung erzeugt wird?
Durch Beleuchtung entstehen keine Hügel, also ja, ich bin mir sicher.

ok, wollte das Programm anhängen (als zip), darf ich aber nicht (zu groß). Und das liegt nicht nur an den Texturen, sondern auch an der exe


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 14:01 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
Anscheinend funktioniert texelFetch nur manchmal. Also es war möglich, mit texelFetch und dann selber interpolieren die Treppen zu entfernen, wenn ich aber die Normalenberechnung weglasse, scheint texelFetch immer 0.0 auszuspucken. Scheint irgendwie mit den Texturzugriffen über texture zusammenzuhängen. :?:

also testweise hab ich die Höhe mal so berechnet (Normale wird nicht berechnet):
Code:
Vert.y = texelFetch(heightmap, ivec2(floor(TexCoord)), 0).r * 256.0;
ist überall 0.0

Code:
Vert.y = texture(heightmap, TexCoord / 4096.0).r * 256.0; 
hingegen gibt mir die erwarteten Werte. Ohne, dass ich sonst irgendwas am Code änder.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Jan 04, 2011 14:49 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
keiner ne Idee? na gut, so ähnlich ist bislang alles gescheitert, was ich programmieren wollte, warum ausgerechnet dieses mal nicht?


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Jan 04, 2011 14:54 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Also das ist echt ein merkwürdiges Problem. Hast du mal einen anderen Rechner probiert? Ich vermute da fast einen Treiber-Bug oder Hardware-Fehler...

_________________
Yeah! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 05, 2011 13:09 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
Coolcat hat geschrieben:
Hast du mal einen anderen Rechner probiert?
Momentan nicht möglich, ich sitz gerade am "anderen" Rechner, weil meiner gerade repariert wird. Also theorethisch wäre noch ein weiterer PC und ein weiterer Laptop erreichbar, aber die sind beide schon ca 10 Jahre alt. Gut, anderen Treiber ausprobieren wäre noch möglich, allerdings weiß ich nicht, ob da die Hardware noch unterstützt wird (Radeon HD 5***M, glaub ich, wobei ich nicht weiß, was *** ist, aber irgendwas niedriges glaub ich. Wo ich da nachschaun kann, weiß ich auch nicht) Für den Fall, dass das noch unterstützt werden könnte, wo gibts den Treiber?


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 05, 2011 15:36 
Offline
DGL Member

Registriert: Di Okt 13, 2009 17:25
Beiträge: 365
Programmiersprache: C++
Also die Radeon HD 5*** Reihe ist eigentlich die aktuellste von AMD, die es gibt (die 6000er sehe ich (noch) nicht als eigene Reihe an...). Treiber gibt es auf der AMD-Seite:

http://www.amd.com/de/Pages/AMDHomePage.aspx
Rechts bei "Treiber Download" Notebook-Grafiklösungen (wegen HD 5*** _M_) -> Mobility Radeon Series -> Mobility Radeon HD 5xxx Series -> Dein Betriebssystem.

Alllerdings kann ich dir nicht sagen, wie gut inzwischen die offiziellen AMD-Treiber für Notebooks sind. Früher hat nämlich jeder Laptophersteller seine eigenen Treiber gebastelt. Dass es Standard-Treiber von AMD gibt, ist erst geschätzt ein Jahr her.


Zuletzt geändert von mrtrain am Mi Aug 31, 2011 21:18, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 05, 2011 17:56 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
mrtrain hat geschrieben:
Alllerdings kann ich dir nicht sagen, wie gut inzwischen die offiziellen AMD-Treiber für Notebooks sind.
Ähm, falls die nicht gut sind kriegt man das doch wieder runter oder? Nicht, dass ich noch das nächste System zerschieße (noch dazu auf einem Rechner, der nicht mir gehört. Auf meinem wärs ja eher egal. müsst ich nur zum ähm... dritten mal das Betriebssystemystem neu aufsetzen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 05, 2011 18:36 
Offline
DGL Member

Registriert: Di Okt 13, 2009 17:25
Beiträge: 365
Programmiersprache: C++
Naja, dann mach vorher lieber ein Backup. :wink:


Zuletzt geändert von mrtrain am Mi Aug 31, 2011 21:19, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 05, 2011 22:39 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Dez 03, 2008 12:01
Beiträge: 167
Wohnort: /country/germany
Programmiersprache: C++ / FreeBASIC
@sharkman: Eigentlich kriegt man die problemlos wieder runter. Wenn nicht, gibt es da noch die Kombination Cat-Uninstaller + DriverCleaner. Ersteren findest du hier hier. Ich hatte das mal gebraucht als mein OpenGL aufgrund eines Treiberproblems nicht funktionierte. Einfach drüberlaufen lassen, neue Treiber drauf und tadaa - es ging ^^
Mit den Notebook-Treibern von ATi/AMD hatte ich aber noch keine (ernsthaften) Probleme, da gibt es eher Probleme mit den von den Herstellern zusammengebastelten Treibern.

_________________
Traue keinem Computer, den du nicht aus dem Fenster werfen kannst -- Steve Wozniak


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Jan 06, 2011 10:40 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
ok, treiber installiert sowieso nicht. inkompatible Hardware/software


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 25 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » Shader


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.015s | 15 Queries | GZIP : On ]