Terrain-texturierung (texture splating?)

Tachyon76

Hallo,

ich bin am überlegen, wie ich am besten meine Terrain-Klasse aufbaue.
Dabei komme ich an einer Stelle nicht so recht weiter:

Soweit ich das bei "Texture Splatting" verstanden habe, wird pro Bodentextur ein Renderpass und ein eigener VertexBuffer benötigt(?) .
Die meisten Beispiele gehen von max 4 Bodentexturen aus.
Was aber, wenn man von ca. 20+ Texturen ausgeht? (Matsch_1, Matsch_2, Sand_1, Sand_2, Gras_1, Gras_2, Gras_3, Kies, Strasse, Pflastersteine, .....)
Wird dann auch für jede Texture ein eigener Renderpass benötigt?

Oder wie realisiert man sowas ? (ich will vorerst OHNE shader arbeiten!! )

Gibt es sonst noch bessere Techniken zu darstellen von Terrains mit vielen texturen?

Danke

this-*gt*that

Du brauchst defintiv NICHT mehrere Vertexbuffer. Und ich rate dir dringend zu Shadern, denn dann kannst du so viele Layer blenden wie du willst in einem einzigen Pass (im Gegensatz zur FFP).

Tachyon76

Ok, danke dir.
Ich habe noch eine bessere Erklärung gefunden, als die ich zuerst gelesen habe.

Was ich aber noch nicht verstehe:
Wenn ich eine Alphamap und eine Textur für mit dem selben vertexBuffer nutze, habe diese doch die selben textur-koordinaten (tu / tv werden ja pro Vertex definiert). D.h. Wenn ich die Alphamap über den kompletten (terrain-)chunk legen muss, ist die Boden-Textur automatich auch über den kompletten chunk; ich kann die Boden-Textur also nicht "widerholend" zeichnen. Also für jedes "Quad" die komplette Textur.

this-*gt*that

Doch, kannst du, indem du einfach eine Vertexstruktur mit mehreren Texturkoordinaten angibst. Z.B. einmal für die Alphamap und einmal für alle Textur-Schichten oder sogar für jede Textur-Schicht eigene Texturkoordinaten. Damit kannst du jede Texturschicht unabhängig von den anderen über das Terrain kacheln.

Ich habe neulich eine Anwendung geschrieben, in dem ich auch ein Terrain gebraucht habe ( http://www.infoboard.org/screenshots/msc thesis/index.htm ). Die verwendete Vertexstruktur für die Terrain-Vertices sieht so aus:

struct TerrainVertex {
D3DXVECTOR3 Position; 
D3DXVECTOR3 Normal;	 
D3DXVECTOR2 TexLayer[5]; // Texture Layers TexCoords
D3DXVECTOR2 TexAlpha;    // Alpha Map TexCoords
};

Ich denke die Struktur ist selbsterklärend.

Tachyon76

ja das ist ja mal n klasse "trick".
wäre ich von mir aus gar nicht drauf gekommen.

danke dir

rapso

Tachyon76 schrieb:

Gibt es sonst noch bessere Techniken zu darstellen von Terrains mit vielen texturen?

pro quad eine Textur zu machen die man dann dynamisch zusammenstellt. dann kann man soviele layer + funky sachen wie z.b. strassen zusammenblenden und die ganze zeit nutzen
dabei ist das rendering dann immer gleich schnell, egal wieviel layer.
der nachteil dieser methode ist, dass du diese texturen updaten und managen musst.

Tachyon76

rapso schrieb:

pro quad eine Textur zu machen die man dann dynamisch zusammenstellt.

hm, verstehe ich nicht so ganz. speziell "...die man dann dynamisch zusammenstellt.".
Meinst du das so, dass Jedes Quad seine eigene Textur hat (inkl. Übergänge zu den Nachbar-Quads). Also Theoretisch wie eine riesige textur fürs ganze Chunk aber nochmal für jedes Quat unterteilt. Das Aber nicht alles in nem Malprogramm erstellt, sondern die Übergänge per Programm?

Aber du meinst bestimmt was anderes oder?

Edit: Mit Übergänge meine ich den Verlauf von einer Bodentextur zur anderen per "Farbwerten" und nicht mittels alpha.

rapso

Tachyon76 schrieb:

rapso schrieb:

pro quad eine Textur zu machen die man dann dynamisch zusammenstellt.

hm, verstehe ich nicht so ganz. speziell "...die man dann dynamisch zusammenstellt.".
Meinst du das so, dass Jedes Quad seine eigene Textur hat (inkl. Übergänge zu den Nachbar-Quads).

ja jedes quad hat eine eigene texture.

Also Theoretisch wie eine riesige textur fürs ganze Chunk aber nochmal für jedes Quat unterteilt.

je nach namensgebung, meine Quads sind 33*33 vertices bzw 32*32*2 triangles.

Das Aber nicht alles in nem Malprogramm erstellt, sondern die Übergänge per Programm?

so wie du pro frame alles auf dem screen zusammenblendest, so kannst du das (entweder mit render2texture oder per cpu) in eine texture einmal zusammenblenden.

Edit: Mit Übergänge meine ich den Verlauf von einer Bodentextur zur anderen per "Farbwerten" und nicht mittels alpha.

wie du die daten abspeicherst ist deine sache. eine extra alphamap hat den vorteil dass du sie unabhaengig von der aufloesung des meshes machen kannst. waehrend du bei vertices an die meshaufloesung gekoppelt bist, was manchmal ugly sein kann.

das schoene an der idee ist, dass es sehr GPU sparsam ist was rendergeschwindigkeit angeht. damit es speichermaessig wenig verbraucht, muss man je nach entfernung zu den quads, den quads verschiedene texturaufloesungen geben. entsprechend muss man alle zeitlang die quads updaten.

this-*gt*that

Irgendwie will mir der Sinn von diesem "Pro Quad eine Textur" nicht einleuchten. Da du das offenbar alles letztlich zu einer Textur zusammenblendest, kann man doch gleich eine große Textur nehmen? Und wie komme ich überhaupt zu der Quad-Textur? Die Oberflächentextur ist ja abhängig von der Steigung/Höhe etc. Benutzt man dann Texture Splatting pro Quad (aber dann könnte man ja gleich Texture Splatting fürs ganze Terrain benutzen)
Hat die Technik einen Namen und gibts da irgendwo Paper?

rapso

this->that schrieb:

Irgendwie will mir der Sinn von diesem "Pro Quad eine Textur" nicht einleuchten.

das schoene an der idee ist, dass es sehr GPU sparsam ist was rendergeschwindigkeit angeht.

Da du das offenbar alles letztlich zu einer Textur zusammenblendest, kann man doch gleich eine große Textur nehmen?

damit es speichermaessig wenig verbraucht, muss man je nach entfernung zu den quads, den quads verschiedene texturaufloesungen geben.

Und wie komme ich überhaupt zu der Quad-Textur? Die Oberflächentextur ist ja abhängig von der Steigung/Höhe etc.

wie die oberflaeche definiert ist, ist doch individuell. trotzdem ist das was du jedes frame auf dem screen zusammenrechnest das, was du auch einmal in eine textur pro quad rechnen kannst. wo siehst du da ein problem?

Benutzt man dann Texture Splatting pro Quad (aber dann könnte man ja gleich Texture Splatting fürs ganze Terrain benutzen)
Hat die Technik einen Namen und gibts da irgendwo Paper?

das ist so trivial, ich weiss nicht ob es dafuer einen paper gibt. ich glaube megatexturing waere sowas in der art, allerdings werden da beim levelbauen schon die quads vorberechnet und sonst macht man das zur laufzeit. ich hab sowas zum ersten mal gemacht als mmx rauskam, weil es sich anbot.

this-*gt*that

Ich kann mir das ohne Code weiterhin nicht richtig vorstellen. Wenn ich pro Quad eine Textur habe, muss ich auch pro Quad die Textur wechseln, was die Performance killt.

rapso

this->that schrieb:

Ich kann mir das ohne Code weiterhin nicht richtig vorstellen.

wenn man sich nur mit bild etwas vorstellen kann, ist es keine vorstellung mehr

Wenn ich pro Quad eine Textur habe, muss ich auch pro Quad die Textur wechseln, was die Performance killt.

wieso? zeichnest du das ganze terrain mit einem einzigen drawcall? ohne VB/IB etc. zu wechseln?

this-*gt*that

rapso schrieb:

wenn man sich nur mit bild etwas vorstellen kann, ist es keine vorstellung mehr

Seit wann malt man Code?

rapso schrieb:

wieso? zeichnest du das ganze terrain mit einem einzigen drawcall? ohne VB/IB etc. zu wechseln?

Ich habe bis jetzt nur ein einziges mal ein Terrain gerendert und ja, das war mit einem einzigen VB/IB. Heißt das, dass du pro Quad einen eigenen VB/IB hast und für jedes Quad einen neuen VB/IB und Texturen setzt?

rapso

this->that schrieb:

rapso schrieb:

wenn man sich nur mit bild etwas vorstellen kann, ist es keine vorstellung mehr

Seit wann malt man Code?

wieso heisst es wohl VISUALstudio

rapso schrieb:

wieso? zeichnest du das ganze terrain mit einem einzigen drawcall? ohne VB/IB etc. zu wechseln?

Ich habe bis jetzt nur ein einziges mal ein Terrain gerendert und ja, das war mit einem einzigen VB/IB. Heißt das, dass du pro Quad einen eigenen VB/IB hast und für jedes Quad einen neuen VB/IB und Texturen setzt?

[/quote]jup
aber da zittiere ich mich lieber wieder selbst

meine Quads sind 33*33 vertices bzw 32*32*2 triangles.

auf diese weise kann ich grob die quads cullen und dann recht performant zeichnen.

this-*gt*that

rapso schrieb:

jup
aber da zittiere ich mich lieber wieder selbst

meine Quads sind 33*33 vertices bzw 32*32*2 triangles.

Naja, nur weil du deine Vertices in Quads aufteilst, heißt das ja noch lange nicht, dass du mehrere VB benutzt.

Ok, verstehe. Du teilst das Terrain also in kleine Chunks auf, benutzt dann ein (optinales) Cullingsystem wie z.B. einen Quadtree um die sichtbaren Quads rauszupicken und gehst dann in einer Schleife über alle sichtbaren Quads, und renders jedes Quad mit den dazu gehörigen States (Texturen, VB etc.)

Würde es nicht auch gehen einen riesigen VB+IB zu nehmen und beim Rendern der indizierten Dreiecke immer nur die richtigen Index-Intervalle anzugeben?

rapso

this->that schrieb:

rapso schrieb:

jup
aber da zittiere ich mich lieber wieder selbst

meine Quads sind 33*33 vertices bzw 32*32*2 triangles.

Naja, nur weil du deine Vertices in Quads aufteilst, heißt das ja noch lange nicht, dass du mehrere VB benutzt.

Ok, verstehe. Du teilst das Terrain also in kleine Chunks auf, benutzt dann ein (optinales) Cullingsystem wie z.B. einen Quadtree um die sichtbaren Quads rauszupicken und gehst dann in einer Schleife über alle sichtbaren Quads, und renders jedes Quad mit den dazu gehörigen States (Texturen, VB etc.)

ja, manche nennen es quads, manche chunks, manche tiles, manche blocks
ist hoffentlich klar dass es immer das selbe ist was wir meinen
(ich nenne es nur quads, weil sie bei mir im quadtree sind :D)

Würde es nicht auch gehen einen riesigen VB+IB zu nehmen und beim Rendern der indizierten Dreiecke immer nur die richtigen Index-Intervalle anzugeben?

Riesig? so ca 2GB?
kommt immer drauf an was man zeichnet
kleinere VB haben den vorteil dass sie einfacher upzudaten sind, also auch treiberseitig gut handlebar. Es kann durchaus sein dass die graphikkarte noch aus dem buffer rendert, waehrend du ein quad/chunk/tile aenderst weil es ein anderes mesh-lod bekommen soll. wenn du den riesigen buffer lockst, stallt die cpu bis die gpu fertig ist, oder die gpu hat nen double/trible/x-buffer, also statt 2GB dann 8GB vram fuer den vertexbuffer ;).
alternativ koennte man auch subteile updaten, dann muesste aber der treiber nachverfolgen welchen teil des 2GB buffers du renderst und welcher eventuell updatebar ist.

bei kleinen buffern ist es einfacher, du kannst auch eine hybride loesung versuchen, immer 16 quads in einen VB oder so.

wenn du natuerlich nur einmal ein riesiges mesch anlegst, weil du z.b. eh fast immer die selbe perspektive hast, waere ein einziger statischer VB die bessere wahl.

es kommt also einfach auf den einzelnen fall an.