DGL
https://delphigl.com/forum/

Bumpmapping über verschiedene Renderpfade
https://delphigl.com/forum/viewtopic.php?f=20&t=2469
Seite 1 von 3

Autor:  Sascha Willems [ Do Feb 05, 2004 22:01 ]
Betreff des Beitrags:  Bumpmapping über verschiedene Renderpfade

Da mich die Geschwindigkeit verschiedener Renderpfade schon recht lange interessiert hat, hab ich meine einfache Bumpmapping-Demo ein wenig erweitert, so dass man recht einfach feststellen kann wo die Renderpfade in Sachen Geschwindigkeit liegen. Den Download + Quellcode gibts hier.

Meine Beobachtung auf ner Radeon 9700 :
  • Feste Funktionspipeline (2 Pass, ohne Specular) ~ 440 FPS
  • ARB_VP/ARB_FP (1 Pass, Bump + Specular) ~ 350 FPS
  • glSlang (1 Pass, Bump + Specular) ~ 175 FPS


Wie zu sehen muss in Sachen glSlang-Implementation also noch einiges getan werden. Die Demo prüft übrigens nicht auf das Vorhandensein der verschiedenen Extensions, also wirds wohl Probleme auf Karten <> Radeon9500 (höher) geben.

Autor:  LarsMiddendorf [ Do Feb 05, 2004 22:33 ]
Betreff des Beitrags: 

Interessanter Vergleich. Auf der Radeon 9800 pro sind die Werte etwas besser aber das Verhältnis ähnlich zu sein.
ARB_fp/ARB_vp: 550 FPS
Feste Funktionspipeline : 610 FPS
glSlang: 235 FPS
Ich habe allerdings keine besonderen Einstellungen wie AntiAlias oder anisotrophische Filter eingeschaltet. Kannst du vielleicht mal den Quelltext, aus dem das ARB_fp Programms generiert wurde, hinzufügen, damit man die beiden Versionen besser vergleichen kann? Es würde mich mal interessieren wo genau der Unterschied liegt, der zu diesem Geschwindigkeitsverlust führt.

Autor:  Sascha Willems [ Fr Feb 06, 2004 01:37 ]
Betreff des Beitrags: 

Wie du sicherlich vermutet hast, hab ich den ARB_VP/FP-Quellcode über fxPascal generiert. Hab einfach den glSlang-Shader nach fxPascal konveritiert und dann den ARB-Output genommen. Deshalb bin ich auch ein wenig von der starken Differenz glSlang<->ARB "geschockt". Hier die beiden fxPascal-Shader :

Vertexshader :
Code:
  1. program NeuerShader_vs;
  2.  
  3. uses ARB_vertex_program;
  4.  
  5. param
  6.  lightPos : vec4;
  7.  camPos   : vec4;
  8.  
  9. varying
  10.  texcoord : vec4;
  11.  lightVec : vec4;
  12.  viewVec  : vec4;
  13.  
  14. var
  15.  lVec : vec4;
  16.  vVec : vec4;
  17.  
  18. begin
  19. result.position := MatrixMult4(state.matrix.mvp,vertex.position);
  20. texcoord        := vertex.texcoord[0];
  21.  
  22. lVec       := lightPos - vertex.position;
  23. lightVec.x := dot(vertex.texcoord[1], lVec);
  24. lightVec.y := dot(vertex.texcoord[2], lVec);
  25. lightVec.z := dot(vertex.texcoord[3], lVec);
  26.  
  27. vVec       := camPos - vertex.position;
  28. viewVec.x  := dot(vertex.texcoord[1], vVec);
  29. viewVec.y  := dot(vertex.texcoord[2], vVec);
  30. viewVec.z  := dot(vertex.texcoord[3], vVec);
  31. end;


Fragmentshader :
Code:
  1. program NeuerShader_fs;
  2.  
  3. uses ARB_fragment_program;
  4.  
  5. param
  6.  invRadius : single;
  7.  ambient   : single;
  8.  
  9. varying
  10.  texcoord : vec4;
  11.  lightVec : vec4;
  12.  viewVec  : vec4;
  13.  
  14. var
  15.  base     : vec4;
  16.  bump     : vec4;
  17.  distSqr  : single;
  18.  lVec     : vec4;
  19.  atten    : single;
  20.  diffuse  : single;
  21.  specular : single;
  22.  
  23. begin
  24. base := Texture2D(0, texcoord);
  25. bump := NormalMap(1, texcoord);
  26.  
  27. distSqr := dot(lightVec, lightVec);
  28. lVec    := lightVec * (1/sqrt(distSqr));
  29.  
  30. atten   := sat(1.0 - invRadius * sqrt(distSqr));
  31. diffuse := sat(dot(lVec, bump));
  32.  
  33. specular :=  power(sat(dot(reflect(normalize(-viewVec), bump), lVec)), 16);
  34.  
  35. result.color := ambient * base + (diffuse * base + 0.4 * specular);
  36. end;
  37.  


Im Endeffekt würde das also bedeuten, das dein fxPascal weit besser optimiert als dies ATIs glSlang-Implementation tut.

Autor:  Finalspace [ Fr Feb 06, 2004 10:30 ]
Betreff des Beitrags: 

So hab mir die demo auch mal angeguckt und find die ziemlich kuul ;)
Das einzigste was mich gestört hat waren erstmal die vielen fehlermeldungen am anfang und beim durchschalten der renderpfade.

Hab also mal schnell bissel überprüfungen reingehauen und ne pause eingebaut so ich das licht anhalten kann ;)

Hier waynes interessiert: http://www.xenorate.com/final/simplebump_v2.01.zip


Auf folgendem system bisher:
AMD XP 2000+, 512 DDR 333
GeForce 256 DDR 32 MB (GeForce1)

Fps: 136 FPS (Fixed Function)
Fps: 0-1 FPS (ARB Shader) mit NV30 Emu Treiber

Aussehen tut die arb variante natürlich besser als die fixed, aber ist durch die fragment emulation ultra standbild haft ;)
Ich will ne radeon 9800 :D

Werd das ganze aba mal au zuhause testn:
P4 HT 3 Ghz, 1024 DDR 400
GeForce 4 Ti 4200 64 MB

Ich werd auch noch versuchen ne GeForce3/4 Renderpath zu machen mit nv_combiners.

matane,
Final

Autor:  Sascha Willems [ Fr Feb 06, 2004 11:29 ]
Betreff des Beitrags: 

Danke für die Addition. Die Tests wollt ich zwar auch schon einbauen, war dazu aber irgendwie zu faul ;)

Ein zusätzlicher Renderpfad für die Registercombiner von NVidia wäre natürlich sehr interessant, und wie schnell der dann ist würde mich auch interessieren.

Autor:  Mars [ Fr Feb 06, 2004 12:43 ]
Betreff des Beitrags: 

Interessante Sache, mit den Änderungen von FinalSpace (das ursprüngliche Programm stürzt ab - aber das war ja auch dokumentiert) erhalte ich auf der
Fx5600:
ARB_VP/FP: 101 FpS
Fixed Function: 272 FpS

wobei die ARB-Variante schon plastischer aussieht

Wäre interessant, was die Fx5900 so liefert, das kann ich eventuell in ein paar Tagen bei meinem Brüderlein testen.

Autor:  LarsMiddendorf [ Fr Feb 06, 2004 12:50 ]
Betreff des Beitrags: 

Die Register Combiner dürfen ähnlich der festen Pipeline sein. Irgendwo stand mal das die glTextureEnv's in Register Combiner Einstellungen konvertiert werden.
Interessant wäre mal ein Vergleich mit Diffuse+Specular über Register Combiner im Gegensatz zu ARB_fp.
Im ARB_fp ist das sat also clamp(x,0.0,1.0) keine eigene Anweisung sondern wird an den zugehörigen Befehl angehängt. Vielleicht erkennt der glSlang Compiler dies nicht.
Ein größerer Unterschied könnte das Normalisieren der Bumpmap sein. NormalMap führt in fxPascal keine Normalisierung durch, weil die Qualität bei detaillierten Bumpmaps nicht stark davon abhängt und man das daher nicht immer automatisch benötigt.
Ein Unterschied bleibt trotzdem bestehen und ich würde mir gerne mal, wie das bei dem NVidia Treiber möglich ist, die glSlang Ausgabe ansehen.

Autor:  LarsMiddendorf [ Fr Feb 06, 2004 13:04 ]
Betreff des Beitrags: 

Ich habe in dem Fragment Shader mal Offset Bumpmapping ergänzt, weil es ja jetzt dazugehört:
Der Effekt kommt allerding bei einem festen Torus nicht so schön raus.


Code:
  1.  
  2. uniform sampler2D Base;
  3. uniform sampler2D Bump;
  4.  
  5. uniform float invRadius;
  6. uniform float ambient;
  7.  
  8. varying vec2 texCoord;
  9. varying vec3 lightVec;
  10. varying vec3 viewVec;
  11.  
  12. void main()
  13.  {
  14.  vec4 base = texture2D(Base, texCoord);
  15.  vec3 nviewvec=normalize(viewVec);
  16.  
  17.  float height=dot(base.xyz,vec3(0.3,0.3,0.4))*2.0-1.0;
  18.  vec2 newtexcoord = height *0.02*nviewvec.xy+texCoord;
  19.  
  20.  base = texture2D(Base, newtexcoord);
  21.  
  22.  vec3 bump = normalize(vec3(texture2D(Bump, newtexcoord)* 2.0 - 1.0));
  23.  
  24.  float distSqr = dot(lightVec, lightVec);
  25.  vec3 lVec     = lightVec * inversesqrt(distSqr);
  26.  
  27.  float atten   = clamp(1.0 - invRadius * sqrt(distSqr), 0.0, 1.0);
  28.  float diffuse = clamp(dot(lVec, bump), 0.0, 1.0);
  29.  
  30.  float specular = pow(clamp(dot(reflect(-nviewvec, bump), lVec), 0.0, 1.0), 8.0);
  31.  
  32.  gl_FragColor = ambient * base + (diffuse * base + 0.4 * specular) * atten;
  33.  
  34. }
  35.  

Autor:  Finalspace [ Fr Feb 06, 2004 13:04 ]
Betreff des Beitrags: 

Kannst du mir nen gefallen tun, kannst du noch reinbauen das man mehr als 1 licht machen kann ? Nen array auf TLight wäre nice ;)

TLight = record
pos,
color : Tglvertex3f;
end;

Ich würd das ja gern selber machen, nur hab ich keine ahnung wie das mit den ARB Shadern bzw glSlang is, ob man da was beachten muss, wenn man mehrere lichter adden will.

thx,
Final

Autor:  LarsMiddendorf [ Fr Feb 06, 2004 13:09 ]
Betreff des Beitrags: 

Mehrere Lichter funktionieren genau so wie vorher. Der einzige Vorteil ist, daß man eventuell mehrere Lichter zusammenfassen kann, weil längere Shader möglich sind. Bei Stencil Schatten schließt sich das aber aus.

Autor:  Sascha Willems [ Fr Feb 06, 2004 13:24 ]
Betreff des Beitrags: 

@Lars :
Erstmal thx für den Offset-Shader. Werd ihn dann mal einbauen, auch wenn es wie du erwähnt hast bei der verwendeten Geometrie nicht viel bringt. Und die Sache mit dem glSlang->ARB-Output auf ATI-Karten würde mich auch wirklich interessieren, denn im Endeffekt wundert es mich warum ATIs glSlang-Implementation schlechter optimiert als dein fxPascal.

@Finalspace :
Mehrere Lichter sind eigentlich kein Problem, allerdings kann ich da nicht einfach ein Array of TLight machen, da ich sonst für jedes Licht nen eigenen Pass machen müsste, auch beim Shader. Alternativ dazu könnte man wie Lars gesagt hat mehrere Lichter in einem Shader unterbringen, aber besonders bei glSlang schätze ich das schon nach 2-3 Lichtern die maximale Shaderlänge überschritten wird und dann müsste man wieder Multipass machen, was aber dann den Benchmarkstatus der Demo zu nichte machen würde.

P.S. : Hab die Demo aktualisiert und sie prüft jetzt anhand der Extensions welcher Renderpfad nutzbar ist. Auf meinem Zweitrechner mit GF4-Ti4400 (Athlon 1,3GHz) sinds knapp 400 FPS in der FF.

Autor:  Sascha Willems [ Fr Feb 06, 2004 15:39 ]
Betreff des Beitrags: 

Irgendwie ist die Thematik doch recht interessant, hab deshalb die Demo nochmal ein wenig aufgebohrt. Wenn man sich im glSlang-Renderpfad befindet, kann man mit o zwischen dem normalen Bumpshader und dem Offset-Shader von Lars wechseln. Ausserdem kann man nun mit "Bild rauf" bzw. "Bild runter" die Neigung des Torus variieren. Mittels "p" kann man übrigens die Lichtbewegung anhalten.

Die optische Unterscheidung zwischen dem normalen Bumpmapping und der Offsetvariante fällt allerdings wie von Lars erwähnt auf dem Torus recht schwierig. Für alle Interessierten (oder alle ohne glSlang) hab ich deshalb mal nen paar Screenshots (alle 1280x960) hochgeladen :
Normaler glSlang-Bump
glSlang-Offset-Bump
Differenz zwischen beiden Varianten
Den Differenzscreenshot hab ich in einem Bildbearbeitungsprogramm erstellt, und ihn dann noch invertiert, denn so lässt sich die Differenz besser erkennen. Mit aktivem Offset geht bei mir die Performance übrigens auf ~140 FPS runter.

Autor:  LarsMiddendorf [ Fr Feb 06, 2004 17:13 ]
Betreff des Beitrags: 

Vermutlich wegen der Krümmung ist die Unterscheidung schwierig. Bei einer Ebene, zu der man sich parallel bewegen kann ist der Eindruck mehr als offensichtlich, weil man da sieht wie die Bumps zu allen Seiten hin verschoben werden. Vielleicht kannst du da noch eine Ebene einbauen.
Es ist jedenfalls erstaunlich wie viel so ein paar Zeilen ausmachen können und kein Vergleich zu normalen Bumpmapping. Offset+Diffuse sehen meiner Meinung nach teilweise besser aus als Diffuse+Specular.

Autor:  SchodMC [ Sa Feb 07, 2004 10:43 ]
Betreff des Beitrags: 

Ich hab hier ein lustiges Erebnis (Radeon 9600 XT):

gsLang: 180 FPS
ARB : 410FPS
Fixed : 365 FPS

Warum ist die ARB-Variante schneller als die Fixed-Funktion? Hab' den aktuellen Catalyst!

Autor:  SchodMC [ Sa Feb 07, 2004 10:48 ]
Betreff des Beitrags: 

Ok, fehler gefunden. Die Karte war noch übertaktet. Die Ergebnisse mit der Standard-Taktung:


gsLang: 165 FPS
ARB : 345 FPS
Fixed : 490 FPS

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