Terrainrendering optimiert für Strategiespiele
-
Hi! Ich bin von meinen Traum-Tripp endlich heruntergekommen einmal ein MMORPG zu schreiben. Ein Strategiespiel ist von den Grafischen Anforderungen wesentlich geringer und liegt daher eher in meinem Möglichkeitsbereich. Ein Strategiespiel wird aus der Vogelperspektive betrachtet und somit fallen sämtliche LOD Algorithmen weg, es ist warscheinlich empfehlenswert ein in Patches unterteiltes Bruteforce Terrain zu rendern und dieses mittels Frustum-Culling zu beschneiden. Außerdem ist die Größe des begrenzt, dadurch fallen wieder Streaming Algorithmen wie das Nachladen von Texturen oder Geometrischen Daten weg.
Ich habe mich bereits dran gesetzt und das ganze versucht um zu setzen. Ich rendere ein Bruteforce Terrain welches in Patches unterteilt ist und aus einer Heightmap geladen wurde. Ich siebe die nicht sichtbaren Patches des Terrains mittels Frustum Culling aus. Da es auch möglich ist die Kamera zu schwenken ist es eher unpraktisch auf Frustum-Culling zu verzichten und eine einfachere Art zu benutzen.
Das Terrain wird mit einer sehr guten Geschwindigkeit gerendert, wenn ich kein Vsync verwende liegt die FPS um 2500. Nun möchte ich jedoch Klippen in das Terrain einbauen, jedoch ist mir nicht wirklich bewusst wie ich dies realisieren sollte. Das Terrain ähnlich wie das von Warcraft III sein. Die Klippen sind nicht einfach eine flache Fläche, sondern haben auch verförmungen.
Ich habe diese Frage bereits in einem anderen Forum gestellt:
http://www.spieleprogrammierer.de/phpBB2/viewtopic.php?t=10683
Jedoch konnte mir dort nicht wirklich geholfen werden!
-
Die klippentiles als nichtbegehbar kennzeichnen und zwischen der untersten und höchsten ebene langsam stufenweise interpolieren.
Also als heightmap.
Sieht dann zwar stufenförmig aus, aber mit +- von Zufallswerten kann man da sicher was nettes basteln.ODER: Du gestaltest ein UniversalModel für die Klippen und baust es an allen Stellen ein.
Zweiteres ist sicher performanter, aber sieht wohl eintönig aus
-
Die zwei Methoden schwirten mir auch im Kopf herum, wobei die erste mir sehr gut gefällt. Ein überhang ist im vereinfachten sinne dann einfach ein Würfel, und jede zeite hat dann eine Quaratische fläche. Nun kann man ganz einfach schauen ob neben dem Hügel noch ein Hügel ist und o weiter, und die eckpunkte dann immer verbinden. Und die eckpunkte ann man dann zufällig immer ein weig verschieben, o das das ganze dann mehr durcheinander aussieht. So könnte man die klippen dann ganz gut realisieren, dabei ist dann aber wieder die editiermöglichkeit wie ich finde sehr schwer, da muss ich mir noch ein verfahren überlegen. Ich könnte das Terrain nun wieder auch in einzelne Patches unterteilen, so das ich immer ein VertexBuffer für ein Patch habe ...
Hmm, aber dann wird es schwer einen kleinen Gelände editor zu schreiben, da ich mir nur schwer vorstellen kann wie ich es am sinnvollste relisiere. Man kann das so schwer erklären, mir fehlen einfach die Worte dazu!
-
Das Problem der Anpassung der einzelnen Meshes der Klippen hast du bei der Interpolationsmethode nicht.
Außerdem muss das ja nur einmal am Anfang geschehen und wird einfach gespeichert.So bekommst du auch immer individuelle KlippenEDIT: Du hast grad den kompletten Beitrag geändert ^^
-
Hbe meinen Post Editiert, habe gerade ochmal drüber nachgedacht und mich doch umentschieden welche variante ich ehme, habe nehmlich mal bei Warcraft3 und Starcraft2 in weig genauer das Terrain betrachtet! Habe da halt noch gewisse Denkblokaden wie ich es am besten gestallte, das die Editiermöglichkeiten auch am besten sind. Siehe vorherigen Post, ist editiert!
-
koenntest du mal ein screen posten der das aufzeigt? ich als nicht WC3 spieler weiss es nicht genau was du meinst.
ich hab den editor von WC3 mal 'gespielt' und dort hat man, glaube ich, fertige terrainstuecke plaziert.
-
http://i133.photobucket.com/albums/q80/PetrusAduro/UAT/warcraft3.jpg
http://www.averlat.net/data/winex/warcraft3/warcraft3.jpg
http://www.carlsguides.com/pictures/warcraft3screenshot3.jpg
http://www.spiegel.de/img/0,1020,181250,00.jpgAleine die Klippen denke ich könnte ich realisieen, kompletzierter wid das ganze ja dann mit den begebahen abhängen, also so zu sagen die treppen ...
Ich befürchte ich habe meine Anforderungen noch immer zu hoch gesetzt! Ich habe mich ja nun schon lang genug mit Heightmaps beschäftigt, und ich glaube ich werde mal ein Stategiespiel machen, welches auf ener Heightmap aufbaut. Dies hat ja nicht nur Nachteile, sondern auch seine Vorteile!
1. Einfacher ein zu binden
2. Einfachere Editiermöglichkeiten
3. Wesentlih größere Feiheiten
4. Textur-Splatting einfacher ein zu binden
5. Wesentlich realistischerDadurch würden die Klippen wesentlich schöner aussehen, lediglich das Patsh-Finding etc wird ein wenig mehr rechenleitung verbrauchen. Aber man kann ja so zu sagen bei laden des Spiels eine "zusatz Map" generieren, in der dann die begebaren wege gespeichert sind. so zu sagen das dann jedes Quadrat der Hightmap einen boolischen Wert hat, 0 = nicht begebar und 1 = begebar.
Ein Editor für ein solches Terrain währe warscheinlich wesentlich einfacher zu erstellen, jedoch hat dieser auch seine Tücken. Ich habe mich noch nie großartig mit dem Locken/Unlocken von Vertex Buffern auseinander gesetzt. Ich habe wo es ur ging darauf gesetzt Statische Meshes zu verwenden, aber bei einem Editor ist das nun nicht mehr möglich.
Das Terrain ist wie gesagt in Patches unterteilt. Wenn ich un soetwas wie ein Pinsel einbauen will, mit dem man Anhöhungen machen kann, dann werden gleichzeitig mehrere Vertices bearbeitet. Hat man noch eine gute Geschwindigkeit wenn man Immer den ganzen VetexBuffer neu beschreibt? Der VertexBuffer ist ja nicht sonderlich groß, nur 33x33 Vertices, somit sollten dabei keine Probleme auftauchen, denn ein Animiertes Modell hat ja wesentlich mehr Vertices die abgeändert werden, und das ganze auch noch performant! Ich werde mich einfach mal dran setzen und dann mal schauen was draus wird
Probieren geht über studieren
-
mach dir nicht zuviel gedanken ueber die geschwindigkeit beim editieren. wichtig ist dass es im spiel schnell laeuft. entwickler setzen eh oft dickere kisten ein als das spiel spaeter benoetigt und selbst wenn es beim entwickler mal ein wenig ruckelt ist es nicht dramatisch und er wird nicht quieken wie es user tun.
find ich aber gut dass du es dir vereinfachen willstich hab auch geacht, dass eine moeglichkeit ein voxelspace waere aus dem du dann metaballs generierst. es gibt im netz viele sourcen dazu (auch freie) die dir aus einem voxel ein mesh generieren.
zum wegfinden, mach dir nicht zuviel arbeit mit automatischer generierung von maps usw. sowas hat am ende immer noch tuecken und generiert nicht immer das gewollte.
generiere grob eine map und lass dann die leveldesigner selbst zeichnen was begehbar, beschwimbar, ueberfliegbar usw. ist.
-
Nein, automtische generierung der Maps möchte ich nicht einbauen. Mit Weg findung meine ich, das die Figuren de Weg automatisch finden! Ich möchte den Editor dann später mit dem Spiel weiter geben, so dass die Spieler die Möglichkeit haben eigene Maps zu gestallten. Für die Kampagnen werde ich warscheinlich auf das Trigger System zurück greifen, so dass man auch im Editor eigene Kampagnen gestallten kann. Naja, ich habe mir viel vor genommen
