spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Die Strategiespiele die du da aufzählst haben so weit ich weiß noch ein "Ebenen-System" - also keine fließenden Höhen wie beim "richtigen Terrain", sondern mehrere Abstufungen auf denen sich die Figuren dann ledeglich 2-dimensional bewegen.
Klar neuere haben auch bereits fließende Höhen und so wie du schreibst scheinst du ja auf solche hinauzuwollen.

Einen LOD-Algo würde ich grundsätzlich nicht von vorne herein sein lassen, da man ja gerne Zoom und Kameraschwenkungen drin hat.

Außerdem wiedersprichst du dich ein wenig... gerade ROAM ist eigentlich DER LOD-Algo für Terrain.
RealTime-Verformung ist glaube ich mit ihm nicht sehr leicht möglich, da er für seinen Detailreduktionsalgorithmus Änderungsraten des Terrains an bestimmten Stellen berechnet. Ich selbst habe mal einen ROAM ähnlichen Algorithmus implementiert und habe dabei sehr schlechte Erfahrungen gemacht, weil bei mir der Traffic über den BUS viel zu hoch war - das Bruteforceterrain mit der selben Größe war schneller (gut ich habe wohl viele viele Fehler gemacht und keine sehr moderne Form des ROAM angewandt... kann sein dass ich mich jetzt hier von vorne bis hinten vertu).

Joa da wärn wir beim BruteForce... BruteForce kann durchwegs sinnvoll sein für kleinere Flächen und außerdem ist ein mit Quadtree unterteiltes BruteForce-Netz gar nicht mal so langsam.

GeoMipmapping: Mein persönlicher Favorit den ich auch in unseren aktuellen Projekt bereits erfolgreich anwende.
- Gute Detailreduktion
- Kein Traffic über den BUS
- Sehr sehr sehr wenig Zeit zur Berechnung des Detail Levels
Was du da beschreibst ist aber auch nicht umbedingt ganz richtig: Man kommt mit einen einzigen Vertexbuffern und Indexbuffer pro Detailstufe aus! Somit hat man auch einen minmalen Speicherverbrauch... das generieren der Indexbuffer ist etwas knifflig, da man Brüche zu anderen LOD-Stufen vermeiden muss, zahlt sich aber aus.
Womöglich hast du aber recht, es könnte relativ ungeeignet sein, aber ich denke sicher nicht verkehrt.

Geometrische Clipmaps sind für mich eignetlich das selbe, vllt hab ich da was falsch verstanden mal.

Also ich würde dir jetzt keinen ROAM empfehlen. Quadtree-Unterteilung ist ja eh immer Pflicht.. wenn du meinst kein weiteres LOD zu benötigen (ist ja auch gar nicht mal so dumm von deiner Argumentation her) kannst du eben darauf verzichten und mit "BruteForce-Leafs" arbeiten.
Ich würde mich jedenfalls wie immer an mein GeoMipMapping klammern wegen oben aufgeführten Gründen.

Wenn du sehr auf Speichersparen bei GeoMipmapping setzt, kannst du auch einen Vertexbuffer nehmen und mehrere Indexbuffer, die verschieden viele Vertizen verwenden.
Die anderen nicht genutzten werden dann zwar immer noch als Daten überall hin mitgenommen, aber nicht mehr Transformiert und gerendert, was dann eben doch schneller geht als volles Detail.

Ich verwende ein Hybrid aus ROAM und eben genannten.

für dein problem würde ich auich tiling empfehlen, da kannst du eine heightmap laden oder auch mehrere, LOd ist denke ich auch nicht ganz sinnvoll. dann noch schick cullen dann passt das.

wegen echtzeitverformung fällt mir spontan nix cleveres ein, wenn ich was falsches sag macht mich ulong nen kopp kürzer :lol:

@ unsigned long

Der Vertexbuffer ist eine "Highmap", es gibt ein Feld mit den Abweichungswerten, über eine ROAM Algorithmus berechne ich wenns not tut einen neuen Indexbuffer und verwende den statisch.
Ich sagte ja "eben genannten" das schließt Geomipmapping nicht unweigerlich mit ein, was denke ich jetzt aber mit den statischen Indexbuffern auch gehen würde.

Zitat

Ich möchte mal wissen wie das geht. Das wäre so als ob man Turbolader mit Kompressor verbindet

Geklärt? So geht das.

Also ich würd von der Technik her Geomipmapping verwenden, aber alle Vertexhöhen direkt aus einer Heightmap beim Rendern lesen (--> Shader). Falls du dann eine Verformung hast, dann sperrst du genau den betroffenen Bereich der Heightmap und überschreibst die Daten. Für die Heightmap selbst, würde ich dir auf alle Fälle floating-point-textures empfehlen, da ist man nämlich praktisch nicht begrenzt ;-)

Ich denke das müsste eine super Performance geben und dazu noch praktisch unendlich große "frei" verformbare Terrains möglich machen (--> mehrere Heightmaps, und nur wenige geladen (Loadthread für RT))

Seid wann kann man den Texturen im Vertexshader samplen? Hab ich was verpasst?

EDIT: ah oke seid Shader 3.0 .. ich selber hab nur 2.0, darum bin ich nie draufgekommen...
Interessanter Ansatz... wäre interessant, ob es wirklich schneller ist.