OpenGL: Texturen für Splatmapping im FS

[Top-OR]

Moin liebe Leute.

ich möchte mal eure Meinungen einholen.

Ich spiele gerade ein wenig mit Terrain-Rendering unter OpenGL/GLSL herum; momentan habe ich das Splatmapping-Verfahren am Wickel.

Es läuft auch schon recht gut; aber ich habe beim Zuordnen von Texturen etwas Bauchschmerzen:

Momentan benutze ich zwei bilinear gefilterte Splatmaps (max. 8 Kanäle) und eine Colormap sampler2DArray, welche die eigentlichen Motive (8 Stück untereinander) ein einer Textur enthält.
Sampler2DArray dröselt die ja nochmal intern auf, so dass ich die ganzen Motive/logischen Texturen auf einem Textursampler unter verschiedenen Indizes im Shader ansprechen kann: Super!
Ich habe ein bissel hin und hergelesen und habe Bauchschmerzen, was die Unterstützung von sampler2DArray angeht, da ich (auch eher) ältere Systeme ansprechen möchte, welche scheinbar sampler2DArray nicht unterstützen.

Ein Richtwert für mich ist da mein Notebook mit seiner angestaubten Radeon X2300 Mobility (welche scheinbar sampler2DArray nicht mag; u.A. siehe http://feedback.wildfiregames.com/report/opengl/):
Auf Sowas wie diesem solls kaufen!

Nun habe ich gesehen (bzw. getestet), dass sampler3D (bzw. auch Cubemaps) ja von jeder Grafikkarte diesseits des Mississippi seit gefühlten 200 Jahren unterstützt wird.
Ich überlege jetzt, ob ich die sampler2DArray -Geschichte in eine 3D-Textur bzw. meinetwegen auch Cubemap umbaue: Das, was ich suche, ist ja nur die Möglichkeit, meine Multi-Motiv-Textur auf einer Textur-Unit in den Pixelshader zu bekommen.

Wie macht Ihr das? Übersehe ich da noch eine Möglichkeit, das geschickter zu machen? Einzeln will ich die Texturen NICHT auf die Textur-Units (habe meist nur 4 davon) verteilen.

[Sternmull]

Hast du nachgelesen wie sich die Filterung bei 3D-Texturen verhält? Im Gegensatz zu Array-Texturen wird dort ja auch zwischen den "Ebenen" gefiltert. Außerdem sind die Mimpaps ja auch 3D. D.h. der "Textur-Stapel" wird dort als 3D-Block behandelt in dem in allen drei Dimensionen gefiltert wird. Wenn Array-Texturen nicht unterstützt werden, scheinen mir einzelne 2D-Texturen der einzige taugliche Ersatz. Mit der (möglicherweise geringen Anzahl) von Texture-Units muss man dann halt vernünftig umgehen können.

[Schrompf]

Probier mal, ob Du den Texturfilter für die dritte Dimension manuell einstellen kannst. Unter Direct3D geht das, aber die Karten machen nicht alle Filter mit. Die hochqualitativen Filter wie Anisotropische sind für 3D-Texturen nicht immer verfügbar, soweit ich weiß. Ansonsten spricht eigentlich nichts gegen 3D-Texturen - die gibt's schon etwas länger, die dürften also von den meisten Grafikkarten unterstützt werden. Und den Array-Index kann man ja einfach in eine dritte Texturkoordinate uminterpretieren, die halt nur diskrete Werte annimmt.

Laut des Capability Tables von hier können quasi alle Graks bis runter zur Geforce4 oder Radeon 9000-Serie 3D-Texturen. Sinnvoll filtern können weniger - bilinearer Filter ist fast immer da, trilinearer etwas seltener, anisotropische Filter nur in seltenen Ausnahmefällen. Damit kannst Du also arbeiten, wenn Dir die Filterqualität nicht so viel bedeutet. Für ein RTS oder ein RPG, wo man von oben draufschaut, ist das akzeptabel. Für einen Egoshooter oder Artverwandte, bei dem man das Terrain meist unter sehr flachem Winkel sieht, ist das evtl. ein Ausschlusskriterium.

[Top-OR]

Hallo Leute,

ich bedanke mich erstmal für die Meinungen und wünsche allen einen schönen Wochenbeginn.

Momentan mache ich sowas: (2DArray)
texture2DArray(Materials, vec3(_UV.x,_UV.y,_LayerIndex))
wobei _LayerIndex eine ganze Zahl (Integer im Float-Format) ist und den Layer adressiert.

Wenn Array-Texturen nicht unterstützt werden, scheinen mir einzelne 2D-Texturen der einzige taugliche Ersatz. Mit der (möglicherweise geringen Anzahl) von Texture-Units muss man dann halt vernünftig umgehen können.

Wie ich schon geschrieben habe, ist „einzeln Verteilen“ keine Option: Die Sache mit den 3D-Texturen ist ja auch eher als Fallback für ältere Karten gedacht, und da ist man sowieso schon etwas „low on texture units“: Ich brauche z.Z. 2 Units für die Splatmaps (könnte ich mit Arrays, etc. auch auf eine runterbekommen), eine für die Color und eine für die Detail-Map. Von anderen Maps mal ganz zu schweigen… Zack, sind vier Units weg. Außerdem bin ich gierig: Ich möchte mind 6., besser 8. Materialien fürs Gelände haben und nicht für jedes Material will ich ne Texture-Unit opfern.
Bisher hatte ich ein perfides Tiling-System in Betrieb, welches auch auf alten Karten bis zu 16 Materialien erlaubt hat. Das Problem war nur, dass ich eben für alle Ecken und Kanten entsprechendes Tiles brauchte, das ganze relativ "low-res" und das Tiles-Anordnen recht aufwendig, da manuell, war:




BTW: Auf meiner GTX 460 meldet OpenGL/Win7 übrigens auch nur 4 Units. Die sollte theoretisch deutlich mehr haben, aber ich habe noch nicht weiter geforscht, warum das so ist. Auslesefehler?
Naja, ich forsche nun (auch, aber nicht nur deswegen) eben mal, wie ich „Verbrauch an Textureinheiten“ reduzieren kann.

Hast du nachgelesen wie sich die Filterung bei 3D-Texturen verhält? Im Gegensatz zu Array-Texturen wird dort ja auch zwischen den "Ebenen" gefiltert. Außerdem sind die Mimpaps ja auch 3D. D.h. der "Textur-Stapel" wird dort als 3D-Block behandelt in dem in allen drei Dimensionen gefiltert wird.

Das bei 3D-Texturen zwischen den Layern gefiltert wird, ist mir bewusst. Ich müsste daher „genau die Texturlayer treffen“, so dass nicht (sichtbar) interpoliert wird.
Daher seh ich das auch so, wie Schrompf es sagt:

...Und den Array-Index kann man ja einfach in eine dritte Texturkoordinate uminterpretieren, die halt nur diskrete Werte annimmt.

Wie du sagst: Ich müsste dann dem Shader noch sagen, wie viele Layer wir haben, so dass der den korrekten Wert berechnen kann. Mit 3D Texturen müsste ich sowas machen:
texture3D(Materials, vec3(_UV.x,_UV.y,(1.0/_LayerCount)*_LayerIndex))

Wenn ich das lineare Interpolieren in der 3ten Dimension ausbekomme (NEAREST), was eigentlich gehen sollte, dann würden auch kleinere Rundungsfehler nicht stören.

Laut des Capability Tables von hier können quasi alle Graks bis runter zur Geforce4 oder Radeon 9000-Serie 3D-Texturen. Sinnvoll filtern können weniger - bilinearer Filter ist fast immer da, trilinearer etwas seltener, anisotropische Filter nur in seltenen Ausnahmefällen. Damit kannst Du also arbeiten, wenn Dir die Filterqualität nicht so viel bedeutet. Für ein RTS oder ein RPG, wo man von oben draufschaut, ist das akzeptabel. Für einen Egoshooter oder Artverwandte, bei dem man das Terrain meist unter sehr flachem Winkel sieht, ist das evtl. ein Ausschlusskriterium.

Das muss ich noch testen. Aber da es soweiso eine Fallback Lösung wird, müssten Besitzer älterer Grakas u.U. mit leichten optischen Einschränkungen leben:

Bin gern für weitere Vorschläge und geniale Einfälle offen, werde in den kommenden Tagen zumindest erstmal den Ansatz mit den 3D-Texturen usmetzen...

[Top-OR]

Sohohoooooooo: gesägt, tun getan!

Ich habe mir mal die Freude gemacht und heute meinTerrain-Splatmapping-System auf die Benutzung von 3D-Texturen anstatt 2D-Texture-Arrays umgestellt.
Der Aufwand war nicht wirklich groß, lediglich beim Erzeugen der Textur muss man entsprechend umstellen und der Shader muss angepasst werden.

Alter Texture-Lookup (texture2DArray) im FS:

Code: Alles auswählen

#extension GL_EXT_texture_array: enable
uniform sampler2DArray iTileSet;
...
void main()
	{
...
	if (_Cannels.r > 0.0) _Color.rgb = _Color.rgb + texture2DArray(iTileSet, vec3(_TileUV.x,_TileUV.y,0.0)).rgb * _Cannels.r;
	if (_Cannels.g > 0.0) _Color.rgb = _Color.rgb + texture2DArray(iTileSet, vec3(_TileUV.x,_TileUV.y,1.0)).rgb * _Cannels.g;
	if (_Cannels.b > 0.0) _Color.rgb = _Color.rgb + texture2DArray(iTileSet, vec3(_TileUV.x,_TileUV.y,2.0)).rgb * _Cannels.b;
	if (_Cannels.a > 0.0) _Color.rgb = _Color.rgb + texture2DArray(iTileSet, vec3(_TileUV.x,_TileUV.y,3.0)).rgb * _Cannels.a;
...

Die Anzahl der Layer wird dem Shader als Parameter mitgegeben:

Neuer Texture-Lookup (texture3D) im FS:

Code: Alles auswählen

uniform sampler3D iTileSet;
uniform float iTileCount;
...
void main()
	{	
...
	float _TileStep = 1.0 / iTileCount;
	float _TileOffs = 0.5 * _TileStep;
	...
	if (_Cannels.r > 0.0) _Color.rgb = _Color.rgb + texture3D(iTileSet, vec3(_TileUV.x,_TileUV.y,_TileOffs+(_TileStep*0.0))).rgb * _Cannels.r;
	if (_Cannels.g > 0.0) _Color.rgb = _Color.rgb + texture3D(iTileSet, vec3(_TileUV.x,_TileUV.y,_TileOffs+(_TileStep*1.0))).rgb * _Cannels.g;
	if (_Cannels.b > 0.0) _Color.rgb = _Color.rgb + texture3D(iTileSet, vec3(_TileUV.x,_TileUV.y,_TileOffs+(_TileStep*2.0))).rgb * _Cannels.b;
	if (_Cannels.a > 0.0) _Color.rgb = _Color.rgb + texture3D(iTileSet, vec3(_TileUV.x,_TileUV.y,_TileOffs+(_TileStep*3.0))).rgb * _Cannels.a;
...

Bei der Auswahl der Bodentexturen habe ich mir keinen Vorteil verschafft, da sie in etwas Entfernung (wie in den Screenshots) sehr unruhig rüberkommen – sowohl bewegt als auch statisch. Aber darum geht’s ja nicht primär.
Auch den bilineraren Filter musste ich im 3D-Bereich nicht ausknipsen, man muss im Schader nur immer die richtige „Höhenkoordinate“ voll treffen, dann ist alles gut und es gibt keine sichtbaren Vermischungen. Man sieht hier leider nicht die Filterqualität aus der Nähe, aber ich habe keine sichtbaren Veränderungen festgestellt:

Obs deutlich langsamer oder schneller ist, kann ich nicht sagen, da bei mir der Flaschenhals woanders liegt (Danke, Deferred Rendering, grrrrr). Die Framerate hat sich auf jedenfall nicht verringert. Schneller ist es aber auch nicht geworden, sollte jedoch auch auf recht alter Hardware gut laufen (im Gegensatz zu texture2DArray).

[Schrompf]

Lass die if's > 0 weg, die Texturzugriffe werden nach meinem Wissen eh ausgeführt.

[Top-OR]

Hmmmmmm. Echt? Okay!

Ich muss gestehen, für mich sieht es "logischer" aus [Das Wort "logischer" habe ich letztens in einer Folge Star Trek Enterprise von T'Pol gehört. Man hab ich gelacht!],
dies ifs da zu haben, aber ich muss gestehen, ich weiß nicht viel über das Laufzeitverhalten von Texturelookups.

Hast du da mal Material, wo ich über das Thema nachlesen kann?


Ich nehm sie mal raus und werde auf nem älteren System mal schauen, wie es mit der Geschwindigkeit aussieht. Danke soweit für den Hinweis.

[Krishty]

Conditional Branches sind auf GPUs komplett anders als auf CPUs, weil du ja Wavefronts bzw. Warps hast, in denen 32 oder mehr Pixel parallel durchgerechnet werden.

Zu Direct3D-9-Zeiten wurden von jedem Pixel einfach beide Pfade durchgerechnet und das Ergebnis durch eine Conditional Move Instruction ausgewählt; damals durften Shader kein „richtiges“ if enthalten sondern alle Zweige liefen letztendlich auf ein condition ? valueIfTrue : valueIfFalse hinaus.

Seit Direct3D 10 ist es so, dass alle Shader einer Wavefront, bei denen der Zweig nicht ausgeführt wird, leerlaufen, während die anderen den Zweig durchrechnen. Ist also unter allen Pixeln, die augenblicklich durch deine Wavefront sickern, nur ein einziger, bei dem die Bedingung true ergibt, läuft der Shader einfach leer bzw. macht dasselbe wie die anderen, nur werden seine Wirkungen verworfen. Zusätzlich hast du Unkosten für die Kontrolle der Bedingung, die zwar in der Auswertung kaum was kosten (die Sprungvorhersage läuft getrennt von der Berechnung ab), aber den Maschinentext unnötig in die Länge ziehen und verkomplizieren, was u.U. bedeuten kann, dass die Shader-Compiler weniger gut optimieren können.

Die Optimierung hingegen, dass eine Multiplikation mit Null wieder Null ergibt, behandeln ATI-GPUs transparent seit der Radeon 9600 und wurde mittlerweile vielleicht wieder abgeschafft, weil sie so bei moderater Implementierungskomplexität wenig ins Gewicht fällt.

Nachlesen kannst du sowas in den Optimierungsunterlagen der einzelnen Hersteller, z.B. in AMDs OpenCL Programming Guide:

If work-items within a wavefront diverge, all paths are executed serially. For example, if a work-item contains a branch with two paths, the wavefront first executes one path, then the second path. The total time to execute the branch is the sum of each path time. An important point is that even if only one work-item in a wavefront diverges, the rest of the work-items in the wavefront execute the branch.

(Wobei dieses Zitat aber unvollständigerweise suggeriert, Wirkungen einzelner Pfade würden immer inkrafttreten.) Ist aber im vollen Umfang alles andere als leicht verdaulich; selbst, wenn man im Thema drinsteckt.

Kurz: Keine Sprünge (oder Schleifen variabler Länge) in Shadern, wenn sie sich vermeiden lassen.

[Top-OR]

Ich denke, ich verstehe ... so halbwegs.

Ich habe mal im Zusammenhang mit "discard" gelesen, dass es eben nur das Ergebnis beeinflusst,
nicht jedoch das Laufzeitverhalten, da der Shader trotzdem komplett "durchgerechnet" wird.

Ich denke, das geht auch zumindest in diese Richtung (Auch wenns ne etwas andere Baustelle ist).

Sehr gut, dankeschön: Ich danke euch soweit für die Infos. Ich werds mir merken...

[Top-OR]

Ich habe den Shader mal modifiziert, indem ich die "if (x>0)"s mal rausgenommen habe. Das Programm an sich habe ich nicht verändert; lediglich die ifs in dem Shader.

Auf meinem Notebook (2GHz Core2Duo, ATi Radeon x2300 Mobility, Windows Vista) gehen die Frames pro Sekunde von 73 auf ca. 32 runter.

Und nu?

[Krishty]

… bin ich baff.

Musste erstmal nachlesen: Die GPU hat nicht etwa 256 Pixel-Shader, oder 64, sondern … vier. Einzelne. Wahrscheinlich rechnet sie auch die Pixel einzeln durch. Und selbst, wenn nicht – bei einer Wavefront von 2×2 Pixel hat man eh fast wieder CPU-Charakteristik.

Ich mache also nie wieder den Mund auf, wenn Mobil-GPUs im Spiel sind. Für Desktop-Karten gilt aber weiterhin: Weg mit den ifs.

[Top-OR]

… bin ich baff.

Das ich das noch erleben darf... Ne, im Ernst: ich auch. Ich hätte auch gedacht, dass sich da viel parallel abspielt. Die Ausführungen von oben klingen plausibel.

Musste erstmal nachlesen: Die GPU hat nicht etwa 256 Pixel-Shader, oder 64, sondern … vier. Einzelne. Wahrscheinlich rechnet sie auch die Pixel einzeln durch.

Jaja, das ist ein wahres Leistungsmonster... ;-)

Und selbst, wenn nicht – bei einer Wavefront von 2×2 Pixel hat man eh fast wieder CPU-Charakteristik.

Naja, wie gesagt, ich würde den "low end" Bereich gern mitbedienen. Evtl. ist es sinnvoll, alternative Verarbeitungspfade in das Hauptptogramm/Engine einzubauen und dann verschiene Shader/Techniken einzusetzen-

Ich mache also nie wieder den Mund auf, wenn Mobil-GPUs im Spiel sind.

Bitte keine Zurückhaltung. Ich lege Wert auf die Einschätzung kompetenter Forenmitglieder!

Für Desktop-Karten gilt aber weiterhin: Weg mit den ifs.

Wie oben gesagt: Denke ich auch --> alternative Renderpath'.

[Lynxeye]

Nein, für Hardware des DX10 Featurelevels gilt weg mit den IFs. Die NVidia G70 GPU als eine der stärksten der DX9 Generation hat auch gerade einmal 24 Pixelshader mit 2x2 Wavefronts.

[Top-OR]

Nein, für Hardware des DX10 Featurelevels gilt weg mit den IFs. Die NVidia G70 GPU als eine der stärksten der DX9 Generation hat auch gerade einmal 24 Pixelshader mit 2x2 Wavefronts.

Aha, wir kommen der Sache näher.

Das bestärkt mich immer mehr, alternative Renderpath'/Presets zu benutzen. Hoffentlich bekomm ich das sauber strukturiert. Das wird ein schönes Gefriemel...

[Top-OR]

Ich habe gerade noch "rausgefunden", dass bei der Erstellung der 3D-Textur darauf zu achten ist, dass manche Karten (wie z.B. meine Radeon x2300 Mobility) nur "power of 2"-Texturen unterstützen.

Das bezieht sich AUCH auf die dritte Dimension aka. Anzahl der Textur-Layer/Tiles. Ich hatte bisher eine Textur mit 6 Layern im Einsatz (siehe Screenshot).

Die hat die Radeon dann scheinbar intern auf 2x2=4 Layer runtergekürzt/abgeschnitten und dann kamen sehr seltsame Filterergebnisse zum Vorschein.

Als ich dann explizit eine Textur mit 16 Layern angelegt hatte (wobei ich bisher nur die ersten 6 benutze), lief alles wieder perfekt.

Das ist zwar momentan eine feine Speicherplatzverschwendung, aber man könnte die restlichen 10 Tiles/Layer ja immernoch nutzen,
wenn man genügend Splatmap-Informationen in den Shader bekommt (3D-Textur mit 4 Tiles/Layern * RGBA = 16 Splatmapkanäle --> hehehehe *HändeReib*)

Die Performance ist auf meiner berühmt berüchtigten Radeon x2300 sogar noch etwas angestiegen.
Nun sinds 82 FPS. Wahrscheinlich, weil ihm das pow2 in der 3ten Dimension besser schmeckt.

[Top-OR]

Nein, für Hardware des DX10 Featurelevels gilt weg mit den IFs. Die NVidia G70 GPU als eine der stärksten der DX9 Generation hat auch gerade einmal 24 Pixelshader mit 2x2 Wavefronts.

So, ich nochmal.

Nicht, dass ihr mich jetzt hasst und vielleicht noch Schimpfworte für mich erfindet, aber so siehts aus:

3GHz Core2Quad, nVidia GTX 460 GLH, Win7 64, und die Shader-Version mit texture2DArray:
Mit "ifs": 680 FPS
Ohne "ifs": 240 FPS

Wie gesagt, das ganze ist OGL, nicht D3D.

Und nu?

[Krishty]

Daran gewöhnen, dass GPUs sich immer kontra jeder Dokumentation verhalten. -.- Nein echt, kein Plan. Werden die 2D-Texturkoordinaten bereits als Input an das Fragment übergeben oder erst darin ausgerechnet? Das könnte entscheiden, wie früh die Hardware fetcht.

[Top-OR]

DIESE Texturkoordinaten (_TileUV) für die Colormaps errechne ich IM Shader aus anderen Koordinaten, die ich von außen bekomme (vDetailUV).
vDetailUV wird irgendwo von Teilen der Vertexposition (im Worldspace) abgegriffen, glaube ich ...

Ich möchte im FS noch die Größe/Zoomfactor beeinflussen können.

Code: Alles auswählen

uniform float TileCount;
uniform sampler2D Splatmap;
uniform sampler3D TileSet;
...
varying vec2 vTilemapUV;
varying vec2 vDetailUV;

void main()
	{		
	float _TileStep = 1.0/(TileCount);
	float _TileOffs = 0.5 * _TileStep;	
...
	vec4 _Cannels = texture2D(Splatmap, vTilemapUV);
	vec2 _TileUV = fract(vDetailUV / 600.0);
	vec3 _Color = vec3(0.0,0.0,0.0);
	if (_Cannels.r > 0.0) _Color.rgb = _Color.rgb + texture3D(TileSet, vec3(_TileUV.x,_TileUV.y,_TileOffs+(_TileStep*0.0))).rgb * _Cannels.r;
	if (_Cannels.g > 0.0) _Color.rgb = _Color.rgb + texture3D(TileSet, vec3(_TileUV.x,_TileUV.y,_TileOffs+(_TileStep*1.0))).rgb * _Cannels.g;
	if (_Cannels.b > 0.0) _Color.rgb = _Color.rgb + texture3D(TileSet, vec3(_TileUV.x,_TileUV.y,_TileOffs+(_TileStep*2.0))).rgb * _Cannels.b;
	if (_Cannels.a > 0.0) _Color.rgb = _Color.rgb + texture3D(TileSet, vec3(_TileUV.x,_TileUV.y,_TileOffs+(_TileStep*3.0))).rgb * _Cannels.a;
	...
	gl_FragData[0] = vec4(_Color.rgb, 0.0);
}

Die letztendlichen Koordinaten für die 3D-Textur muss ich sowieso im FS errechnen, da ich erst DA weiß, welche Layer der 3D-Textur ich treffen will: vec3(_TileUV.x,_TileUV.y,_TileOffs+(_TileStep*X))
Wenn ich _TileOffs und _TileStep als fertige Parameter übergeben würde, wäre es noch was anderes...