Terrain-texturierung (texture splating?)
-
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.
-
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.
-
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?
-
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.
-
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.
-
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?
-
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?
-
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 selbstmeine Quads sind 33*33 vertices bzw 32*32*2 triangles.
auf diese weise kann ich grob die quads cullen und dann recht performant zeichnen.
-
rapso schrieb:
jup
aber da zittiere ich mich lieber wieder selbstmeine 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?
-
this->that schrieb:
rapso schrieb:
jup
aber da zittiere ich mich lieber wieder selbstmeine 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.