hallo erstmal,
ich programmiere seit geraumer zeit eine kleine terrainengine und bin nun beim texturing anglangt.
nun will ich übergänge zwischen den texturen schaffen und dachte mir dass ich dass am besten mit multitexturing und blending hinbekomme allerdings weiß ich nicht genau wie ich das anstellen soll.
am liebsten würde ich ja das ganze terrain mit allen texturen überziehen und entsprechend der höhe blenden allerdings dürfte das von den technischen gegebenheiten her etwas schwierig werden und max 4 texturen bei anehmbarer performance sind nun nicht das wahre
also werde ich mir was anderes einfallen lassen müssen wie zum beispiel die texturen nur dort einsetzten wo sie gebraucht werden, nur weiß ich noch nicht genau wie ich das anstellen soll..
leider finden man zu dem thema nur sehr wenig informationen deshalb wollte ich fragen ob evtl. jemand gute tutorien kennt.
ich würde mir auch alternative techniken anschaun
wie macht ihr das?

Leider bist Du etwas zu sehr mit der Tür ins haus gefallen und deine Anfrage war etwas zu wenig ausführlich.... Recht viel mehr als mehrere Texturen auf ein Terrain, das könnte vieles sein - beim nächsten mal bitte so schreiben, daß jemand, der nicht weis was Du vorhast, versteht, was Du machen möchtest Jedenfalls, wenn ich Dich richtig verstanden hab, dann ist das das richtige für Dich:
http://www.delphi3d.net/articles/viewar ... aintex.htm

prinzipiell suche ich nur nach einem weg texturübergänge im terrain(zb von sand auf gras oder was weiß ich) darzustellen und hab anschleißend dazu mein lösungsansatz vorgestellt.
außerdem würde mich halt interessieren wie ihr das macht.
dachte eigendlich es ist verständlich
und ja der link sieht interessant aus werds mir nacher mal genauer anschaun
danke dir

Die in dem Artikel beschriebene Methode funzt wunderbar, allerdings würde ich die Coverage-Faktoren in ne Textur packen. Macht dann weniger Probleme.
Wenn du mehr als 3 Texturen Blenden willst, musst du mehrere Passes machen. Ohne irgendwelche Fragment-Programs zu benutzen kannst du so mit jedem weiteren Pass 2 weitere Texturen blenden. Is natürlich dann auch langsamer.
Darum würde ich vorschlagen, dass Terrain in kleinere Stücke zu unterteilen, und für jedes Stück nachzugucken, welche Texturen da überhaupt benötigt werden. Es dürfte eher selten sein, dass in einem Terrain-Stück alle Texturen aufeinander treffen. (Sand und Schnee dürften eigentlich nie zusammen auftreten). Mit etwas Glück kommst du dann mit 1-2 Passes hin.

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Hi ...

Auf gamedev.net hab ich auch mal nen Artikel zu dem Thema gesehen ... solltest dir evtl auch noch mal anschauen ...

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

weiß jetzt nich genau wie das tutorial gemacht wird aber ich würds, wenns n relativ statisches terrain is, einfach vorher berechnen, also das terrain in handliche "patches" unterteilen und dann die textur die du darüber klatschen willst per hand berechnen(abhängig von der höhe [ganz oben schnee, ganz unten wasser oder so]), denn alles was du vorher berechnest musste nicht mehr zur laufzeit machen *g* logisch wa... naja also wenn du dir viele passes/shader und multitexturing sparen willst (zu mindest an dieser stelle) machs so...

_________________
www.extrawurst.org

Das kann dann aber ne Menge VRAM kosten...

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Bei QuakeWorld soll diese Megatexture ja auch nur einmal über die Landschaft gelegt werden aber dafür eine Größe von 32.000 x 32.000 Pixeln haben.

Die wird nie im Leben als ganzes ins VRAM geladen. Maximal ein 2048x2048 Ausschnitt und selbst das würde noch ne Menge kosten (96MB ohne Kompression).

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Ich glaube nicht, dass jemand allen Enstes vor hat solche gigantische Texturen auf einmal in den VRAM zu laden. Das sind knapp 2,9 GB. Allerdings wundere ich mich gerade wie du auf 96 MB kommst? Also 2048 x 2048 sind bei in RGBA (wobei Alpha sogar unnützt ist) "nur" 16 MB.

Natürlich nicht als ganzes. Aber von der riesen Texture sind doch maximal pro Bild 800x600 Punkte (oder wie die Auflösung) auch ist zu sehen. Von den entfernte Bereichen muss ja ähnlich wie bei den Mipmaps nicht die volle Detailtiefe geladen werden. Im Speichern sollen immer nur 8MB dieser Texture sein, der Rest soll dann im Hintergrund geladen werden.

Hallo Krabbels,

ich hatte vor geraumer Zeit die selbe "Herausforderung" und habe mittlerweile mit dem Thema Texturieren abgeschlossen. In diesem Thread findest du 2 screenshots meiner Implementierung:

viewtopic.php?t=5188

Mittlerweile ist UTF-8 Textdarstellung noch mit drin, und ich komme auf durchschnittlich 90 FPS auf Nvidia 5700.

Ich will hier grob zusammenfassen, wie ich es gemacht habe. Die eigentliche Implementation ist in C++, aber das ist ja ziemlich egal.

Erstmal die Anforderungen, die ich hatte:

- es soll möglich sein, beliebig viele Texturen zu verwenden
- keine Shader/Fragmentprogramme

Die Lösung lag also in Mehrpass-Rendering mit Blending. Nur irgendwie performant muss es trotzdem noch sein.

Also, mein Heightfield ist ein Float-Array.

Jetzt speichere ich für jeden Höhenpunkt meines Arrays einen Geländetyp. Das ist das entscheidende bei dieser Methode, ich speichere also nicht per Quad einen Geländetyp, sondern für jeden einzelnen Höhenpunkt.

Wenn ich dann rendere, kann ich die Geländetypen der jeweils acht benachbarten Höhenpunkte ermitteln.
Ich versuche das hier mal zu illustieren:


In diesem Beispiel ist der zu untersuchende Höhenpunkt mit den * markiert.
An diesem Höhenpunkt ist also Schnee.

Mit dieser Methode kann ich nun die "Geländeanteile" an diesem Punkt ermitteln. Also in dem oben skizzierten Beispiel wäre das:


Da der zu untersuchende Höhenpunkt als Schnee definiert ist, rendere ich nun im ersten Pass per Multitexturing die Grundtextur, und Schnee an dieser Stelle.

Danach, im 2. Pass, kann ich durch das oben ermittelte sehen, das z.B. Fels noch mit beteiligt ist. Also rendere ich an diesem Punkt auch noch Fels, per Blending.

Jedesmal, wenn ich im 2. Pass ein Quad (eigentlich TRIANGLE_STRIP) rendere, untersuche ich für jeden Eckpunkt die Höhenpunkte der Nachbarn, und rendere diese.

Vorteile dieser Methode sind:
- wenn die Nachbarn alle vom gleichen Typ sind, etwa alle Gras, dann brauch ich im 2. Pass garnichts zu rendern!
- es können so viele Texturen verwendet werden, wie man will
- an den Stellen wo sich die Geländetypen der Höhenpunkte unterscheiden, wird nur so viel wie nötig gerendert

Diese Methode wird dann extrem langsam, wenn man wirklich in jedem Höhenpunkt unterschiedliche Geländetypen hat, da dann der 2. Pass entsprechend lang braucht. Für meinen Anwendungsfall ist das nicht relevant, da man z.B. eine größere Grasfläche hat, einen See, zusammenhängende Felsflächen etc. Der zweite Pass kommt also nur zum Einsatz, wenn auch wirklich ein Übergang nötig ist.

Hmm, ich hoffe ich konnte irgendwie darstellen, wie ich's gemacht habe , vielleicht hilfts dir weiter.

Gruss
Mados

*nachrechne*

Jo hast recht. Kein Plan, was ich da gerechnet habe...

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

@Mados: Speicherst du deine Ergebnisse, oder machst du das bei jedem Durchlauf erneut? Wenn dies so ist, kannste das noch optimieren. Du speicherstd ann dein ergebnis in ner Liste, und dazu noch ne Kennzahl welche sich aus den Verwendeten Texturen, und deren Gewichtung zusammensätzt. Bei einer ähnlichen Stelle musst du dann den Zweiten pass nicht machen, sondern du sucht dir nur den passenden Patch aus der Liste. Dann könntest du das ganze noch nach häufigkeit sortieren. Und wenns zuviel werden haust du die am Ende einfach weg.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich speichere diese Werte nicht, da es das nicht wirklich braucht:

Ich hab einen Octree für das Frustum Culling, und alle Endknoten ("Würfel") speichern Displaylisten für das, was sie rendern sollen. Die eigentliche Berechnung findet also nur statt, wenn sich im Terrain etwas geologisch ändert, weil durch die geänderten Höhenwerte sich eventuell die Inhalte der Octree-Endknoten ändern.

Ändert sich nichts an den eigentlichen Höhenwerten, sondern nur an den Geländetypen, so muss ich den Octree nicht neu aufbauen, sondern nur neuzeichnen (also die Displaylisten neu generieren), was so schnell geht, das man mit der Maus in Echtzeit Bodentypen "malen" kann.

Es ist richtig, ich könnte da nochmals Zeit sparen, in dem Fall wenn sich Höhenwerte ändern. Aber: das Neu-aufbauen des Octrees dauert jetzt ca. 2 Sekunden, und da mein Heightfield zu 99% der Laufzeit statisch bleibt, ist das völlig ausreichend. Im eigentlichen Ablauf des Programms verbringt der User höchsten 5% der Zeit damit, an den Höhenwerten oder den Geländetypen rumzufrickeln.

-> Die Performance beim ändern von Geländetypen ist ausreichend
-> Wenn der User etwas an den Höhenwerten ändert, macht er diese erst mit einem Drahtgitter-Overlay. Ein Druck auf "ok" übernimmt die Änderungen und generiert den Octree neu (noch nicht implementiert )


Gruss
Mados