[Terrain] Terrain-Texturierung mit mehr als 4 Texturen?

[DomiOh]

Hallo,

kennt jemand eine Möglichkeit, ein Terrain mit mehr als 4 Texturen (Texture Splatting) zu texturieren (abgesehen von Texturen in der Größe von 4096 x 4096 oder so...) ?

Für Ideen wäre ich dankbar.

Gruß,
DomiOh

[Jörg]

- Multipass-Rendering
- Mehr als eine Blend-Faktor-Textur
- Shader-Bitschieberei (4:4:4:4:4:4:4:4)

Was sind denn deine Randbedingungen?

[Tejio]

Ohne viel Ahnung zu haben, würde ich Texture Streaming erwähnen. Würde das in deine Richtung gehen? Einige Spiele nutzen dies, zb. Age of Conan oder Call Of Duty: Modern Warfare 2. Nach meinem Verständnis wird dabei immer nur der sichtbare Ausschnitt einer Textur verwendet, sodass man mehrere Texturen in extremer Auflösung nutzen kann, ohne große Performanceverlust (uU?^^°) Ich hatte mal einige PDFs darüber, aber ich finde sie nicht mehr wieder....

[waigie]

Naja da gibt es verschiedene Möglichkeiten sind ja hier schon erwähnt.

Sehr einfach lässt sich eine 5. Texture einbauen, dabei gehst du einfach davon aus, das die die 5 Werte für einen Texel immer 1 ergeben, so kannst du über 1-R-G-B-A eine weitere Textur nutzen.

Mit anderen Tricks könnte man auch weitaus mehr Texturen nutzen. Den Alpha Wert kann man nehmen um festzulegen welches Textureset für den Texel verwendet wird etc. pp. Da kommt man dann schon auf sehr viele Texturen. Probleme bekommt man bei älteren Shader Modellen jedoch irgendwann durch die Begrenzung der möglichen Texturen, besonders wenn man pro Bodentextur noch weiter Texturdaten benötigt wie etwas Normalmaps.

Ansonsten Multipass Rendering. Zuerst mir die ersten 4 Texturen, dann die nächsten 4 und immer weiter und am Ende alles zusammen blenden.

[Chromanoid]

Ein bisschen Diskussion dazu findest du auch hier: OpenGL: Texturen für Splatmapping im FS

[DomiOh]

- Multipass-Rendering
- Mehr als eine Blend-Faktor-Textur
- Shader-Bitschieberei (4:4:4:4:4:4:4:4)

Was sind denn deine Randbedingungen?

Was meinst du mit "Shader-Bitschieberei (4:4:4:4:4:4:4:4)" ?

[Chromanoid]

Schätzungsweise statt 8bit Gewichtung pro Textur 4bit o.Ä.

[DomiOh]

Ja ok, ist das denn in einem SM 3.0 schon möglich?

[waigie]

Naja was brauchst du dafür schon großartiges. Die Farb und der Alpha Wert sind jedes mal ein Byte. Da kommst du mit Typcasts zu int, ganzzahliger Division und Modulo ganz einfach an die höheren bzw. niedrigen Bits. Ein anderer Weg wären Bitshifts und AND/OR Operationen. Bin mir grade nicht sicher aber in den GLSL 1.2 Specs hab ich sie gefunden daher geh ich davon aus das auch SM 3.0 diese unterstützt.

[Chromanoid]

Ich glaube bitwise Kram geht erst ab sm4... Aber mit fmod und normalen rechenoperationen sollte das wie gesagt kein problem sein.

[DomiOh]

Mit fmod und normalen Rechenoperationen?
Ich kann mir da keinen Weg vorstellen...

[Chromanoid]

Beispiel:
a0=fmod(rgb.r*255,16)/15; //gewicht aus unteren vier bits vom rotkanal
a1=(rgb.r*255-a0)/16/15; // gewicht aus oberen vier bits vom rotkanal

oder hab ich mich gerade verrechnet?

[Krishty]

oder hab ich mich gerade verrechnet?

Ja, bei a1 müsste 15.0f * a0 subtrahiert werden. Aber a1 vereinfacht und parallelisiert sich auch dadurch, stattdessen floor() und einen anderen Skalierfaktor als 255 zu verwenden (glaube ich).

Also wir streben nach

a0 = x & 0xF;
a1 = x >> 4;

(x ist unsigned char) und das entspricht

a0 = x % 16;
a1 = x / 16;

Auf x als Gleitkommazahl übertragen also

a0 = fmod(255.0f * x, 16.0f) / 15.0f;
a1 = floor(255.0f * x / 16.0f) / 15.0f;

und vereinfacht (ohne Gewähr da lange her und übermüdet)

a0 = frac(255.0f / 16.0f * x);
a1 = floor(255.0f / 16.0f * x) / 15.0f;

Das für jeden Kanal, und man dürfte acht Skalierfaktoren r0, r1, g0, g1, b0, b1, a0, a1 und als Bonus das neunte t = 1.0f - r0 - r1 - g0 - g1 - b0 - b1 - a0 - a1 erhalten.

[Jörg]

Aber nicht vergessen: Fuer die Gewichte Pointsampling verwenden und nach dem Aufspalten interpolieren. Das treibt die ALU-Kosten natuerlich hoch. Wenn du allerdings 2 Texturen im 16bit-RGBA Format nimmst, dann sparst Du Dir ziemlich was bei gleichem Bandbreitenbedarf.

[DomiOh]

Wie soll ich das denn nach dem Aufspalten interpolieren???
An sowas hatte ich schon gedacht, habe aber keinen Plan wie ich das machen soll.

[Krishty]

Wie soll ich das denn nach dem Aufspalten interpolieren???

Deine Texturkoordinaten zu den je nächsten U- und V-Positionen auf- und abrunden und zwischen den vier gemäß des Nachkommateils deiner tatsächlichen Texturkoordinate interpolieren.

Wenn du allerdings 2 Texturen im 16bit-RGBA Format nimmst, dann sparst Du Dir ziemlich was bei gleichem Bandbreitenbedarf.

Dafür ist die TMU-Last dann doppelt so hoch … je anisotroper, desto teurer. Was aber außer Frage steht ist, dass es einfacher zu implementieren ist. DomiOh; falls du D3D >=10 mit SM 3 nutzt, kannst du Texture Arrays einsetzen (günstig, weil du dann „leere“ Kanäle komplett sparen kannst, da out-of-bounds-Zugriffe immer 0 zurückgeben). Oder auch 3D-Texturen mit einer Tiefe von 2, oder mehr (falls du mehr als acht Kanäle brauchst).

[DomiOh]

DomiOh; falls du D3D >=10 mit SM 3 nutzt, kannst du Texture Arrays einsetzen (günstig, weil du dann „leere“ Kanäle komplett sparen kannst, da out-of-bounds-Zugriffe immer 0 zurückgeben). Oder auch 3D-Texturen mit einer Tiefe von 2, oder mehr (falls du mehr als acht Kanäle brauchst).

Derzeit geht es um die implementierung eines D3D9-Renderers, D3D10 folgt später.

[DomiOh]

Wie soll ich das denn nach dem Aufspalten interpolieren???

Deine Texturkoordinaten zu den je nächsten U- und V-Positionen auf- und abrunden und zwischen den vier gemäß des Nachkommateils deiner tatsächlichen Texturkoordinate interpolieren.

Wie soll ich das verstehen?

Ich hole mir den Pixelwert an der Position meiner Texturkoordinaten (mit Point-Filtering) ...
und dann?
Wie komme ich dann an die umliegenden Pixel? Und vor allem welche 4? Links,Recht,Oben,Unten?

Wir haben mit solcher Interpolation die letzten 2 Tage rumgebastelt und haben keine vernünftigen Ergebnisse bekommen, weil irgendwie das Sampling nicht so passt wie es sein sollte.

[Krishty]

Wie soll ich das denn nach dem Aufspalten interpolieren???

Deine Texturkoordinaten zu den je nächsten U- und V-Positionen auf- und abrunden und zwischen den vier gemäß des Nachkommateils deiner tatsächlichen Texturkoordinate interpolieren.

Wie soll ich das verstehen?

Ich hole mir den Pixelwert an der Position meiner Texturkoordinaten (mit Point-Filtering) ...
und dann?
Wie komme ich dann an die umliegenden Pixel? Und vor allem welche 4? Links,Recht,Oben,Unten?

Wir haben mit solcher Interpolation die letzten 2 Tage rumgebastelt und haben keine vernünftigen Ergebnisse bekommen, weil irgendwie das Sampling nicht so passt wie es sein sollte.

Also: Du möchtest die Textur an Stelle U = 0,123; V = 0,234 samplen.

Zuerst einmal multiplizierst du dazu die beiden mit den Texturausmaßen um an die Pixelkoordinaten zu kommen. Das geht per Texture2D.GetDimensions() (wobei ich nicht weiß, ob SM 3 diese Anweisung schon hat – sonst halt als Shader-Konstante übergeben oder in den Vertices vorberechnen) (wir gehen von 256×256 aus):

U' = 31,488
V' = 59,904

Jetzt berechnest du die Positionen der vier umliegenden Texel:

U'0 = floor(U') = 31
V'0 = 59

U'1 = 31
V'1 = ceil(V') = 60

U'2 = 32
V'2 = 59

U'3 = 32
V'3 = 60

Da ich gerade nicht weiß, ob D3D9 die Pixelzentren auch so handhabt, kann es durchaus sein, dass auf alles noch 0,5 ÷ 256 aufaddiert werden muss. Ein Grund mehr, D3D >=10 zu nutzen. Jedenfalls holst du dir nun die vier Samples:

S0 = sampleLOD0(U'0, V'0)
S1 = sampleLOD0(U'1, V'1)
S2 = sampleLOD0(U'2, V'2)
S3 = sampleLOD0(U'3, V'3)

Und dazwischen interpolierst du jetzt gemäß den Nachkommastellen von U' und V' (das muss für alle acht extrahierten Werte einzeln geschehen):

color'0 = lerp(S0, S2, frac(U'));
color'1 = lerp(S1, S3, frac(U'));
color = lerp(color'0, color'1, frac(V'));

Damit habt ihr dann keine anisotrope Filterung und kein Mip-Mapping mehr, aber irgendwo muss man halt Abstriche machen, wenn man sparen will ;) Wieder was, was für mehrere Texturen statt einer Gepackten spricht.

[Top-OR]

Moin liebe Leute,

ich hab den Thread nur fix quer gelesen - also verzeiht, falls ich etwas daneben liege und Brei erzähle bei meiner Einschätzung, aber:

Bei dem ganzen Kram mit dem bitweisen Aufschlüssel der Farbkanäle haben wir doch ein Problem:

Man nutzt ja beim Splatmapping schön die Filterung der Grafikkarte bei Samplen aus der Splatmap.
Beispiel:
Ich sample einen Pixel genau zwischen 100% Erde (Rotkanal) und 100% Gras (Blaukanal) aus der Splatmap.
Ich bekomme automatisch nen Pixel mit r=0.5 und b=0.5: Super, so wollen wirs - halb Gras, halb Erde.

Da kann ich doch DANACH nicht einfach mal aus dem Farbkanal - besonders bei nem interpolieren Wert - ein paar Bits "in der Mitte" herausschneiden und lösgelöst interpretieren.
Oder hab ich nen starken Denkfehler?
Da stimmen doch die Zuordnungen der Materialien doch - besonders "zwischen den Splat-Pixeln" - vorn und hinten nicht mehr, oder seh ich das ganz falsch?

Mein Ansatz is folgender:
Ich lade EINE Material-Texture 512x8192 ( == 512x(16*512) == 16 Materialien) mit den einzelnen Materialien in eine Texture Unit - wie hier besprochen als 3D-Textur.
Das wird auch von hornalter Hardware unterstützt.


Als "Splatmap" nutze ich zur Zeit noch mehrere Einzeltexturen, ich halte es jedoch für sinnvoll, diese auch in EINE textur zu packen mit 2048x(4*2048) = 16 Splatkanäle.

@DomiOh: Wenn dir die Texturen zu groß werden, musste eben die Auflösung verkleinern (512>256 und 2048->1024 etc.)

Will ich einen höheren Kanal nutzen, friemle ich nicht die Bits auf, sondern gehe einfach auf der Textur ein gewisses Offset weiter runter (v*2048)..

Will ich dann z.B. den 10. Splatkanal bei Pixel 0x0 samplen, gehe ich im Shader auf Pixel 0x4096 auf der Splatmap, sample den Pixel dort und verwerte den G-Wert.

So kann man gut auf EINMAL 16 Texturen auf dem Terrain darstellen mit ZWEI Texture Units.

Gerade beim Terrain macht Streaming nicht immer Sinn, z.B. wenn du noch in mittlerer Entfernung (z.B. Draufsicht im RTS) mehrere Untergründe darstellen willst.
Mit zusätzlichen (Gesamt-Color)maps kannste das kaschieren, aber "toll" isses nicht (immer).

Mein Ansatz ist zwar so ein bissel von hinten schräg durchs Auge geschossen, aber für mich ist das ne gute Lösung, welche auch von älterer Hardware gut weggesteckt wird. Zumindest das Texturen-in-den-Shader-Bringen.
Das Einzige, was man im Auge behalten sollte, sind dann die vielen Texturelookups. Die könnten noch Probleme machen...

[Krishty]

Nönö, ist ja durchaus richtig. Ich hatte nur nicht im Kopf, dass 3D-Texturen so breit von alten Karten unterstützt werden – darum hatte ich das nur am Rand erwähnt :)

[Jörg]

Nein, Du siehst das nicht falsch, sondern hast nur den Teil mit der shader-basierten Interpolation ignoriert, nachdem die Bits auseindergepfriemelt wurden.

[Top-OR]

Aaaaaaaaah, der Groschen fällt Pfennigweise. Also sowas wie:

• das Ganze eben für alle "Nachbarpixel" machen:
  • Filterung (vorher) bei den Splattexturen ausstellen bzw. die Splatpixel immer in der "Mitte" samplen
  • Splat-/Farbwerte auslesen
  • Splatwerte durch durch Masking und Shifting restaurieren
• anhand der Splatmap-UV-Position selbst zwischen den Nachbar-Splatpixeln den genauen splatwert berechnen
• danach wie gewohnt die Colortexturen samplen und mit den Splatwerten mixen

Hmmm, tja: so gehts auch!
Klingt mir zwar um einiges friemeliger als einfach ne "komplette map" nach "unten zu rutschen", aber dafür schön platz- und bandbreitesparend, stimmt schon.

Und "komische Texturen" backen/zusammenpacken muss man vorher so oder so.

Na denn, weitermachen! Dumdidum. Shake shake shake and ... disconnect!

[Krishty]

Ich sehe 3D-Texturen bzw. Arrays von 2D-Texturen auch als klar überlegen an; schon allein wegen der anisotropen Filterung, die ich nicht missen wollen würde. Aber wenn man unbedingt acht Kanäle in eine Textur packen will, weiß man jetzt, wie es geht.

[dot]

Mit 3D Texturen gibts ein Problem: Mip-Mapping. Texture-Arrays wären wohl die Ideallösung, aber die gibts leider erst ab d3d10.

[DomiOh]

Vielen Dank für die ganzen Antworten. Eure Ansätze haben uns zu einem Lösungsansatz verholfen. Vielen Dank.

[Halan]

Hey,

bin auch an Terrain Splatting interessiert. Ist leider irgendwie schwerer dazu gute Tutorials zu finden als ich dachte. Kann mir jemand vielleicht mit einem Link weiterhelfen? Und ja, ich bin zu blöd zum googeln :P

Für wen es interessiert:
Ich habe ein mehr oder weniger Tile-basiertes Terrain also immer pro m^2 eine Höheninformation und ein Terrain-Typ. Würd das gerne wenn möglich ist als Form einer Matrix an den Pixelshader übergeben und dann je nachdem welcher Pixel gerade gerendert wird anhand der 4 umliegenden Punkte/Terraintypen die Texture blenden.
Das heisst, ich will also keine Splatmap verwenden. Ich könnte zwar aus den oben genannten Daten theoretisch eine generieren aber kann mir nicht vorstellen dass dies sonderlich schnell wäre. Vor allem weil beim jetzigen Design auch eine Änderung der Tiles wärend der Laufzeit möglich sein soll, dann jedes mal eine neue Splatmap zu generieren scheint nicht sinnvoll.
Mir ist aber nicht ganz klar ob der Fragementshader "weiss" wo im Objectspace er sich gerade befindet und ob ich so einfach eine Matrix an ihn übergeben kann. Ja ihr merkt, ich habe nur trivalie Kenntnisse von GLSL. Deswegen fragte ich hier auch nach einem Tutorial...

gruß,
Halan

[Top-OR]

Hi Halan,

hier gibts ja immernoch keine Antwort. Ich bin mir nicht sicher, ob ich 100% vertanden habe, was du GENAU machen willst.

Gute Tutorials in der Richtung habe ich nicht gefunden, du wirst also was basteln bzw. kreativ sein müssen.

Aber was das Tiling angeht, so möchte ich zumindest fragen: "Willst du das wirklich?"

Ich habe auch einige Zeit mit Tiling auf Terrain experimentiert und muss sagen: Gerade der Aufwand, die Tiles korrekt zu Positionieren, ist größer, als beim normalen Splatting.
Du musst ja für diverse "Materialübergänge" alle möglichen Übergangstiles mehrerer Kombinationen von Materialien vorhalten und korrekt Positionieren.
Das schöne am Verfahren ist, dass es ja relativ straight foreward ist, aber leider auch hohen Verwaltungsaufwand (für Grafiker und Programmlogik) mit sich bringt.
Wenn du on-the-fly da noch rumändern willst (was ja technisch gut geht), wirds noch schlimmer, denke ich ...

Ich habe mich jetzt dann doch für Splatmapping entschieden und bereue es NICHT.

Was willste denn genau damit machen? (Schön schlau, das NACH meiner Rede zu fragen, was?)

Beste Grüße, Top-OR

[Halan]

Was willste denn genau damit machen? (Schön schlau, das NACH meiner Rede zu fragen, was?)

Hey,

erstmal danke für deinen Post. Wie man aus den anderen Threads von mir vlt schon mitbekommen hat Arbeite ich an einem Client-Server Modell. Der Client bekommt Terrain-Daten immer dynamisch gestreamt als 10x10-Chunks. Deswegen bieten sich bei mir Splatmaps auch nicht an. Ich könnte natürlich jedes einzelne 1x1 Tile mit einer selbsterstellten Übergangtextur rendern aber das scheint mir extrem langsam und extrem unflexibel.
Würde gerne immer jedes Cunk als ein Objekt rendern...

Naja, meine Frage war ja eigentlich eher nach einem guten Terrain-Splatting Tutorial. Programmiere schon seit Jahrne mit C++ aber Shader habe ich bis jetzt immer nur sehr triviale geschrieben. Es wäre denke ich ganz gut für mich erstmal allgemein zu erfahren wie so etwas umzusetzen ist und wo genau die Probleme liegen.

Für meinen, im vorherigen Post beschriebenen, Ansatz müsste der Fragment/Pixel-shader eben wissen wo im Objectspace er sich gerade befindet. Weiss nicht ob das so einfach möglich ist.

mfg,
Halan

[Top-OR]

Wie man aus den anderen Threads von mir vlt schon mitbekommen hat Arbeite ich an einem Client-Server Modell. Der Client bekommt Terrain-Daten immer dynamisch gestreamt als 10x10-Chunks.

Aso...

Deswegen bieten sich bei mir Splatmaps auch nicht an.

Ich bin mir nicht sicher, ob diese Schlußfolgerung korrekt ist. Du könntest ja auch nur die entsprechenden Teilausschnitte der Splatmap mitstreamen. (Naja, hab ich wahrscheinlich noch nicht zuende gedacht...)

Naja, meine Frage war ja eigentlich eher nach einem guten Terrain-Splatting Tutorial.

Hmmm, hier gabs mal ganz gute Denkanstöße: http://zfx.info/viewtopic.php?f=5&t=1421

Programmiere schon seit Jahrne mit C++ aber Shader habe ich bis jetzt immer nur sehr triviale geschrieben. Es wäre denke ich ganz gut für mich erstmal allgemein zu erfahren wie so etwas umzusetzen ist und wo genau die Probleme liegen.

Den Ansatz kenn ich, weiß aber keine bessere Lösung als "machen". Sicher helfen gute Ideen, Papers und Tips, aber sicher weiß ich immer erst, wo der Teufel im Detail, nachdem ichs umgesetzt habe...

Für meinen, im vorherigen Post beschriebenen, Ansatz müsste der Fragment/Pixel-shader eben wissen wo im Objectspace er sich gerade befindet. Weiss nicht ob das so einfach möglich ist.

Wenn du außen schon deine Vertices rotated/translated hast, gib dem Shader doch die inversen Operationen (translation (offset) und rotation; meinetwegen als Einzelkomponenten (Vector) oder besser gleich als Matrix) mit und rechne im Shader zurück. Quasi Worldspace-Objectoffset=Objectspace