ZFX + Developia

Hi,

erstmal ein großes Lob an euer Forum! Bin jetzt schon seit 3 Jahren hier angemeldet und lese immer interessiert mit und die Suche konnte mir auch schon des öfteren weiter helfen. Doch dieses mal komme ich irgendwie nicht wirklich weiter.

Habe mir vor ein paar Tagen überlegt ich könnte ja mal das Geomipmapping der CryEngine 2 implementieren. Doch irgendwie finde ich keinen brauchbaren Ansatz.

Hier erstmal ein Screenshot: Bei meiner letzten Geomipmapping implementierung habe ich darauf geachtet das immer nur 2 unterschiedlich LOD-Stufen nebeneinander liegen konnten und so kam ich mit 16 unterschiedlichen Indexbuffern pro LOD für alle möglichen Kombinationen aus.

Doch bei dem Geomipmapping der CryEngine 2 können alle unterschiedlichen LOD-Stufen nebeneinander liegen und das würde mit der oben beschriebenen Methode zu extrem vielen unterschiedlichen Indexbuffern führen.

Habe mir schon überlegt die einzelnen Ränder(links,rechts,oben,unten) und die Mitte des Terrain-Tiles einzeln zu Rendern was die Anzahl der unterschiedlichen Indexbuffern wieder stark reduzieren würde. Allerdings habe ich dann pro Terrain-Tile 5 DrawCalls und das ist auch nicht schön.

Noch eine andere Möglichkeit wäre den benötigten Indexbuffer erst beim Rendern zu erstellen,
aber das ist glaube ich auch keine so tolle Lösung.

Vielleicht habt ihr ja noch eine Idee wie man das ordentlich implementieren könnte?

Gruss
Timo

Akustikkoppler hat geschrieben:Noch eine andere Möglichkeit wäre den benötigten Indexbuffer erst beim Rendern zu erstellen,
aber das ist glaube ich auch keine so tolle Lösung.

Genau das tun wir. Jetzt nicht für HeightMaps, sondern für komplett frei formbare Meshes, aber das ist unsere Methode. Die Index-Generierung passiert bei uns allerdings auf der CPU - Du willst das ja evtl. auf der Grafikkarte haben, wo Dir dann schlicht die Informationen fehlen, um zur Laufzeit zu bestimmen, welches Detaillevel das benachbarte Segment hat. Für uns, die wir die Indizes eines Segments nach Bedarf auf der CPU neu berechnen, ist das aber kein Problem.

In Game Programming Gems 2 ist dazu ein ganz netter Artikel. Da werden "Link-" und "Body-Indexbuffer" benutzt.
http://books.google.de/books?id=1-NfBEl ... q=&f=false
Die Stelle des Buches ist zufälliger Weise bei Google Books online...

Akustikkoppler hat geschrieben:Habe mir schon überlegt die einzelnen Ränder(links,rechts,oben,unten) und die Mitte des Terrain-Tiles einzeln zu Rendern was die Anzahl der unterschiedlichen Indexbuffern wieder stark reduzieren würde. Allerdings habe ich dann pro Terrain-Tile 5 DrawCalls und das ist auch nicht schön.

Im Artikel werden einfach noch die unterschiedlichen Nachbarkonstellationen beachtet, so dass man nicht immer 5 Drawcalls benötigt, sondern i.d.R. wahrscheinlich immer so 1-3 pro Tile. Er macht einfach 16 Body-Buffer pro LOD-Stufe (16 mögliche Nachbartile-Konstellationen, bei Stufe 1 nur 1 Body-Stück, weil immer nur von besserer Stufe zu schlechterer Stufe Link-Stücke benutzt werden) und je nach dem wieviele schlechtere Lod-Stufen es gibt so viele Link-buffer pro Seite (Link-Buffer immer nur von besser auf schlechter, bei 4 möglichen Lod-Stufen, hat die 4. Stufe dann 3 mögliche Link-Buffer (4 auf 1/2/3) pro Seite). Beim Rendern schaut man dann welches Body-Tile man nehmen muss und dann setzt man dementsprechend je nach Konstellation noch 0-4 Link-Buffer dazu. Ich gehe stark davon aus, dass das bei Crytek so gemacht wird...

Da die erste Seite des Artikels fehlt: der Artikel heißt "Simplified Terrain Using Interlocking Tiles" von Greg Snook. Auf der ersten Seite lässt sich der Autor über Verfahren wie ROAM und VDPM aus und sagt, dass diese Verfahren eben nicht so flexibel (wg. Preprocessing) sind und mit dem Verfahren, was er vorstellen möchte, dies umgangen wird.

Danke euch beiden erstmal für eure schnelle Antwort.

Die Methode aus den Programming Gems 2 scheint genau das zu sein was ich mir auch überlegt hatte,
denke werde das dann so mal ausprobieren.

Wenn dein maximaler Fehler relativ klein ist, kannst du auch einfach bei allen LOD stufen am rand von jedem tile eine "Schürze" aus Dreiecken machen, die genau um den maximalen Fehler den diese LOD Stufe zulässt nach unten geht. Das ist statisch, einfach und funktioniert in der Praxis sehr gut.

Gruß
Julien

Hallo Timo,
vielleicht hilft dir der Link auch etwas.
Gruß
Despotist

@ Julien Koenen
Die Methode mit der "Schürze" am Rand jedes Tiles hatte ich vor längerer Zeit auch mal getestet.
Ist aber im Moment nicht das was ich gerne hätte.

@ Despotist
Danke für den Link!

Werde auf jedenfall die Methode mit den Interlocking Tiles verwenden, hatte leider nur noch keine Zeit damit anzufangen.
Muss mir aber auch noch überlegen wie ich die Daten speichere. Bei einer mindest MapSize von 4096x4096 ist das schon eine
Menge an Daten. Habe mir mal ein paar möglichkeiten überlegt.

1. Alles per Tile speichern(Position, Normalen, Texturkoordinaten) macht bei 4k x 4k ungefähr 537 MB + Indices.
-> Diese Methode fällt eigentlich gleich raus.

2. Zwei Vertexstreams einen Buffer in der Größe eines Tiles mit X-Z-Position und Texturkoordinaten und einen Buffer mit der
Y-Position und den Normalen für jedes Tile. X-Z-Position und Texturkoordinaten werden dann im Vertexshader angepasst.
Macht bei 4k x 4k ungefähr 268 MB + Indices.
-> Finde ich eigentlich ziemlich gut

3. Einen Buffer in der Größe eines Tiles mit X-Z-Position und Texturekoordinaten und dann die Y-Position, Texturkoordinaten und
Normalen über die Heightmap im Vertexshader per "Vertex Texture Fetch" berechen.
Macht bei 4k x 4k ungefähr 0,07 MB + Indices + Heighmap Texture.
-> Finde ich im Moment die interessanteste Lösung, bin mir nur nicht sicher wie es hier mit der Geschwindigkeit aussieht.

Welche Methode würdet ihr bevorzugen, oder würdet ihr es vielleicht ganz anders machen?

Gruss
Timo

Man könnte es ja auch über dieses Megatextureverfahren machen, wie bei ID Tech5. Also das die Daten so gestreamed werden.

Ich würde allerdings den Weg gehen, wenn ich nen großes Terrain haben wollte, dass das über Plasmafraktale generiert und eventuell noch parametrisch angepasst wird an den Stellen, wo es nötig ist.
Der Vorteil wäre dann, dass es eigentlich kein Speicher kostet, da es aus dem Nichts genereriert werden kann. Das ganze würde ich dann noch mal in Tiles zerschneiden, die dann um den Spieler herum platziert werden. So hätte man dann sogar eine art Streaming, wenn dann die Tiles an der richtigen Stelle angepasst würden. Und das mit der Schürze ist perfekt. Ein Mehraufwand in andere Techniken zu investieren halte ich für sehr überflüssig.

Hier hab ich mal ein Beispiel für das Schürzenverfahren:
Das Meer wurde über den Vertexshader animiert. Und hier im Drahtgitter... ich finde nicht, dass man da die Übergänge sehen kann.

Bist du mit deiner Interlocked Tile Implementierung voran gekommen?
Wie hast du das Problem mit der Berechnung der Index-Buffer gelöst, oder hast du alles Hardcoded per Hand?

Hi Cobi,

bin leider noch nicht sehr weit voran gekommen, da auf der Arbeit im Moment sehr viel zu tun ist und jetzt auch noch die Semesterferien vorbei sind.
Werde aber sobald ich die Implementierung fertig habe bescheid geben.

Die verschiedenen Indexbuffer wollte ich nicht Hardcoden, werde das ganze über einzelne Funktion lösen.

Gruss
Timo

Hi Akustikkoppler,

Ich hab mit Zettel und Stift etwas rumprobiert aber mir ist kein vernünftiger Algorithmus in den Sinn gekommen mit dem man das Problem der Indexbuffer lösen könnte. Das wird auch in einem Gamasutra artikel zu einer "weiterentwicklung" des IT Algos erwähnt. (Welcher allerdings wieder die Einschränkung der benachbarten LODs einführt)
http://www.gamasutra.com/view/feature/1 ... php?page=2

Another problem with ILT is that there is currently no way to generate these index buffers. Each body and linking piece has to be defined by hand. The inflexibility with this approach was the leading factor in my decision to research and implement a new technique.

Hätte villeicht jemand den code von der Game Programming Gems 2 CD?

Grüße
Cobi

Ps. auf dem Crysis Bild sieht das allerdings reichlich trivial aus... bin verwirrt.

Hi Cobi,

ich hatte vor die IndexBuffer in verschiedene Teile einzuteilen eine Funktion für die Mitte und dann noch eine für jede Seite und diese dann kombinieren.

Werde nächste Woche mal in der Hochschul Bibliothek vorbei schauen. Die müssten das Buch da haben.

Meld mich dann noch mal.

Gruss
Timo

Hi,

habe es gestern endlich mal geschafft in der Bibliothek vorbei zu schauen.

"Grek Snook" hat in seinem Artikel wirklich die ganzen Indexbuffer Hardgecodet,
was meiner Meinung nach keine wirklich gute Lösung ist.

Ich hoffe habe in 2-3 Wochen wieder ein bißchen mehr Zeit und kann mal wieder
ein wenig an meiner Implementierung weiter arbeiten, in der die Indexbuffer
dynamisch erzeugt werden.

@Cobi schick dir gleich mal ne PN

Gruss
Timo