spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Okay, vielen Dank schonmal für die Mühe! Hast was gut bei mir.

<- grübelt gerade über das mit dem Terrain-Patch :-)...

Die Grundidee finde ich persönlich gar nicht schlecht, was ich mich nur gerade frage ist, ob es nicht billiger ist die durch LOD-Änderung betroffenen Felder neu zu rechnen als hier je 5 DrawCalls zu benötigen. Gut, um so größer die Patches, um so weniger fallen die DrawCalls in's Gewicht, aber um so gröber werden (flächenmäßig) natürlich auch die LOD-Schritte, sprich Dreieckszahl <-> Qualität. Bei großen Patches hätte man natürlich andererseits den Vorteil, dass man sich im inneren Part um Nachbarn gar nicht zu jucken braucht, da dieser davon ja nicht betroffen wird, wodurch sich das Ganze natürlich schneller berechnen lässt :-).

LG
Alyx

Ich denke auch, dass das Generieren besser ist. Außerdem erlaubt einen eine halb-dynamische Generation von LODs auch theoretisch in der Entfernung mehrere Terrainpatches zusammenzufassen und wiederum Draw-Calls zu sparen.
Letztes Jahr in Xrodon noch waren diese Übergänge mein größtes Problem. Für meinen Fall halt die plumpe Lösung ausgereicht den äußersten Rand stets auf der höchsten Lodstufe zu halten. Das kann ich allerdings nicht empfehlen - für den größeren Stil wird das katastrophal und kann auch zu Beleuchtungsartefakten führen.

Es ist übrigens auch mittlerweile oft üblich, dass man gar keine Übergänge im Grid macht!
Stattdessen sog. "Schürzen".
Das Prinzip funktioniert so, dass man am Rand eines Terrainpatches nochmal eine Vertexreihe macht, die ein Stück nach unten geht. Dabei sind die Schürzen von Patches für je eine LodStufe darunter so angenährt, dass sie sich kurz unter dem Terrain wieder treffen. Dadurch, dass die Normalenvektoren trotzdem so gesetzt sind, als wäre das Terrain normal fortlaufend, fällt der kleine "Abgrund" bzw. die Kante tatsächlich nicht auf!
Das System funktioniert natürlich erst dann wirklich gut, wenn man ein funktionierendes Geomorphing hat. Dann werden die kleinen (immerhin texturierten ) Brüche die gelegentlich bei größeren Gefällen auftauchen fast vollkommen eliminiert.
Bei einem derartigen System tut man sich mit dem Lod Zusammenfassen auf die Distanz auch sehr leicht. Mehere Drawcalls pro Patch sind dann sowieso Vergangenheit.

Von der Grundidee hab ich schon öfter gelesen, hab aber leider jetzt keinen Link parat. Eine imho ausgezeichnete Implementierung ist das mittlerweile fertige neue Terrain von Ogre:
Ogre Terrain Entwicklungsthread

Ich denke mit einer Aufteilung Welt -> Region -> Region zerteilt in 32x32, 64x64 o.ä. Teile, wobei jeder dieser Teile einem Datenblock der Quelldatei bzw. des Quellstream entspricht, ist man ganz gut beraten.

Nehmen wir mal eine Karte von 4km * 4km, eine Höhen und Landschaftstyp-Auflösung von 50cm à 8 Byte für nötige Informationen, käme die Karte insgesamt auf (4000*2)*(4000*2)*8 = 500 MB.

Wenn man diese dann in 64x64 unterteilen würde, sprich ca. 62m-Schritte, käme man dann auf je 0.12 MB große Happen, die sich selbst Single-Threaded völlig unbemerkt nachladen lassen.

Sprich die "Welt" besteht aus einzelnen Regionen, von denen durchaus auch mehrere gleichzeitig aktiv sein können, wenn man sich nahe der Grenzen befindet, wobei jede Region durch eine Datei repräsentiert würde, von der man aber ersteinmal nur die File-Offsets der einzelnen Sub-Regionen laden würde, in dem Fall also ca. 16 KB für den Table. Je nachdem welche Subregionen für das Rendering der aktuellen Szene benötigt werden lädt man diese dann nach bzw. schmeißt sie nach einer gewissen Tolleranzüberschreitung (Distanz) wieder raus.

Natürlich sollte man keine fixe Auflösung von 50cm nutzen, sondern hier je nach Höhen- und Landschaftstyp-Feinheit teils höher, teils gröber auflösen, nur als einfacher Ansatz zum Rechnen :-).

LG
Alyx

Sind 32er nicht etwas zu klein? Wenn du hohe Sichtweiten hast ist das eine recht klein gewählte Batchgröße. Ich würde eher zu 64er raten.
Ich mein bei 32er kannst du auch nur 4 Lod Stufen machen (32, 16, 8, 4).

Welche Größe man nimmt ist denke ich vor allem davon abhängig wie hoch die maximale Auflösung direkt vor den eigenen Füßen maximal sein kann. Mal angenommen das wären 50cm wie in dem Rechenbeispiel, käme man auf 32x32m (bei 64x64), das sollte eigentlich ganz gut passen, wobei man sowas natürlich generell immer flexibel handhaben sollte.

LG
Alyx