Aloha,
ich überlege derzeit, wie man angenehm ein Level/Map/Gebiet etc. strukturieren kann. Dabei spreche ich sowohl von der visuellen Struktur (Texturen, Vektoren, wo welche Shader, Lightsources, etc) als auch von der logischen Struktur (Feldgröße, passable/impassable, Begrenzungen, etc).
Es ist mir zwar vollkommen klar, dass Leveldesign maßgeblich vom Projekt abhängt, das realisiert werden soll, aber generell frage ich mich im Moment, wie ihr eure Level strukturiert und "abspeichert".

Im Moment fällt mir als einzige Gangbare Lösung nur ein, das gesamte Level als großes Modell vorzubauen und zu laden und mit einer logischen Struktur zu versehen. Aber das wirkt so unglaublich umständlich, dass ich mich frage, ob es nicht eine viel sinnvollere Variante gibt.

Mir geht es momentan um ein kleineres, simpleres Strategiespiel. Ich hab es lieber, wenn gewisse Dinge sich nach und nach entwickeln, ehe man sich zu große Ziele steckt und sich dabei enttäuschen lässt, von daher kann ich hier auch nur mit sehr vagen weil undefinierten Anforderungen zum Projekt ansich aufwarten.

Ich hoffe dennoch auf einige Interessante Ideen, vor allem natürlich aus den vielen Projekten der Projektbeiträgen, die unser Forum bereichern. Dort musste sich ja jemand schonmal Gedanken über genau solche Fragen gemacht haben.

Danke schonmal

Wie du schon gesagt hast, hängt es von dem Ziel ab.
Ein Level oder Map ist in sich abgeschlossen, wärend ein Gebiet offen ist.
Geschlossende Areale sind wesentlich unkomplizierter als offende.
Ein Offendes Areal benötigt das vorladen von später eventuell benötigten Daten, wärend bei einem geschlossendem System dies an einem bestimmten Punkt durch ein wechsel des Gebiets passieren kann.

Also brauchst du entweder ein streambares Format oder halt keines.

Nun stellt sich die nächste Frage, aus was soll sich das Gebiet, egal ob geschlossen oder offen zusammen bauen.
Gibt es ein Terrain, Prozedural erstellte Meshes(z.B. rundungen, spline patches) und/oder eigenständige Assets.
Assets sind z.B. Meshes, animierte Meshes und Entities(Partikel Emitter, Umgebungs Sounds, Trigger,...).

Die letzte frage wäre dann noch das Unterteilungs-System für die Umgebung(Spacial System).

Allgemein gesagt, lohnt sich ein Octree basierte zerlegung zu nutzen und Assets in die entsprechenden Node zu packen.

Ich empfehle das Level-Mesh als Asset an zu sehen, dann kannst du z.b. ein Prozedural generiertes Terrain an einer stelle nutzen und ein Mesh basiertes Terrain an der anderen stelle.
Du bist also wesentlich flexibler mit der Implementierung. Das ist im Prinzip eine Description File und die Daten sind aufgeteilt auf mehrere verschiedene Datein.
Ich würde dafür binary xml nehmen, dass für mkv und die Assets in teilweise bestehende Formate und neue Binärformate packen.
Das ganze sinnvoll angeordnet in ein streamfähigen Archive(tar z.B.) legen, damit das Laden nicht unter der Zugriffszeit der Festplatte und des OS leidet.
Ich würde es nicht komprimieren, da die Assets teilweise selber schon Hardware fähige kompressionen vor liegen und ein weiteres Verarbeiten der Daten einfach nur viel Ladezeit kostet.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Schau dir doch mal den Dungeon Generator von Sascha an. Den hat er vor ein paar Monaten in den news gepostet.
Dort wird perlin Noise genutzt um den Level zu generieren und ihn mit details auszustatten. Das geht auch bei Strategiemaps.

Im allgemeinen würde ich sagen, ist es von Vorteil wiederverwendbare Bausteine für deinen Level zu erstellen. Diese Bausteine tragen die Infos für die Geometrie (vertices), Optik (Shader, Lichtquellen, Texturen) und Kollision mit sich, eventuell auch noch die Dekoration (wenn du diese als Variables Element z.B. per PerlinNoise rangenerieren willst).
Diese Bausteine fügst du dann nur noch zusammen.

Mal ein ganz simples Beispiel, was man vielleicht auch als Techdemo coden könnte: Du baust einen Rennstrecken-Editor. Es gibt drei prinzipielle Elementklassen: Strasse, Untergrund und Misc.

Untergründe gibt es: Kies, Sand und Gras.
Strassenelemente gibt es: Gerade und Kurve.
Misc könnten Objekte wie Gerade-Bande, Kurven-Bande, Reifenstapel, Flutlichtmast, Baum, Busch sein.

Die zu platzieren sollte dir nicht schwer fallen. Damit es nicht langweilig aussieht hast du die oben angesprochene Deko-Info. Das ist einfach ein gespeicherter Seed für einen stabilen Zufallsgenerator. Abhängig von dessen Wert kann dein Kies Grasbüschel enthalten, dein Straßenbelag Flickstellen, die Banden Werbeaufdrucke und die Reifenstapel, Bäume und Büsche unterschiedliche Formen.
Durch die gespeicherten Optikwerte z.B. Lichtquellen, kannst du den Einfluss des "Flutlichtmast"-Objektes auf die umgebenden Objekte berechnen.

Ich hoffe das war eine valide Antwort auf deine Frage und ich hab's mir nicht zu leicht gemacht.


EDIT: Hab gerade die Antwort von Tak gesehen. Unsere Ansätze sind verschiedene Ebenen des selben Problems. Was Tak schreibt ist dann die Speicherung der Infos die ich gerade beschrieben habe. Wenn dein Level, hier die Rennstrecke, sehr groß wird, kannst du den nicht komplett im Speicher halten sondern musst den aufteilen und nachladen wenn du musst. Da ist dann das gesamte Gefiesel aus Taks Beschreibung in Betracht zu ziehen.

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

Okay Danke schonmal für die Antworten
generell geht es mir auf jedenfall um abgeschlossene begrenzte Level, die von der größe her klein genug sein sollten, um sich durch gängige Aufteilungssysteme aufgliedern zu lassen. Streaming offener "endloser" Welten ist definitiv nicht nötig.

Wo ich immernoch etwas "im wald" stehe, ist die Frage, wie ich nun das tatsächliche Visuelle des Levels erzeuge. Ihr rendert das doch kaum im Immediatemode einfach so hin oder? nutzt ihr dafür dann auch modelle, die ihr als vbo importiert? bei einem Untergrund in form eines geländes stelle ich mir das eher schwieriger vor. ich müsste ja doch wieder das gesamte Level in ein "untergrund"modell packen und danach in die einzelnen felder logisch aufsplitten.

Du kannst das Untergrundmodell doch auch prozedural erstellen. Unabhängig davon, ob dus dann als VBO, als DisplayList speicherst, oder gar nicht, und jedes Mal neu erzeugst über Immediate Mode...

Das hab ich jetzt nicht verstanden

Ich wollte nur sagen, dass die Art, wie du das Zeug speicherst, dich nicht daran hindert, es prozedural zu erzeugen.

Das hat für mich irgendwie so geklungen, als ob du annehmen würdest, dass man VBOs nur aus Dateien laden könnte. Man kann sie aber genauso gut prozedural erzeugen, und dann ins VRAM schicken, oder eventuell sogar direkt auf der Graphikkarte erzeugen (naja, das VBO selbst nicht, aber den Inhalt)


oh... hab vielleicht gerade verstanden, was wirklich gemeint war. Dass es bei Outdoor Szenen schwer werden kann das Zeug *richtig* zu unterteilen. Naja, optimale Unterteilung ist wirklich nicht einfach, aber meistens auch nicht nötig. Einfacher Octtree sollte bezüglich Sichtbarkeit schon reichen. Dazu braucht man bei Outdoor Szenen dann meistens noch LoD.

Ach ja... Den Octtree unterteilst du nicht bis zu den einzelnen Dreiecken, sondern nur bis zB < 4000 Dreiecke im jeweiligen Node sind Deswegen machen VBOs da immer noch Sinn, und du "brauchst" nicht den Immediate Mode.

Hoffe, wenigstens eine meiner Antworten beantwortet die eigentliche Frage...

mfg

shark

Doch man kann einen VBO auch komplett auf der Grafikkarte erzeugen. => Nennt sich Transform-Feedback. Braucht recht neue Hardware, wobei meine Obere-Mittelklasse-Karte von vor zwei Jahren (Geforce 9800 GT) das schon kann

_________________
Yeah!

Ich rate dringen davon ab überhaupt das Triangle-Mesh bzgl des Octrees an zu fassen.
In einem Post weiter oben habe ich ja vorgeschlagen, dass du Assets in die Nodes hängen solltest. Dies hat ein einfachen Grund.
Als ich mit SceneGraph und render Performance gearbeitet habe, hab ich diverse Möglichkeiten durch probiert und es ist wesentlich einfacher Ausnahmen und zusätzliche Arbeitsschritte zu machen, wenn man das ganze Asset zur verfügung hat und nicht nur ein Triangle haufen. Praktisches Beispiel: du hast ein Triangle-Mesh aus einer Datei geladen, es liegt in einem Objekt vor, nun erzeugst du eine neue Klasse, welche z.B. die LOD Stufen zur laufzeit generiert und eine die diese schon mit bringt. Das Objekt, mit den Daten, der Klasse zu übergeben und die in den Octree ein zu hängen ist einfach, dafür gibt es Interfaces. Wenn du das Triangle-Mesh Objekt aber schon zerlegst und dann entsprechend 1-7mal(ein node hat 8 Blöcke,sollte das objekt alle 8 berühren dann wird es im Parent-Node hinterlegt, daher maximal 7 Nodes) das Objekt zerlegt im Baum hast macht einige Probleme. Du musst nun beachten, dass irgendwo im Baum ein weiterer Teil des Meshes rum geistert, welches für einige Techniken bekannt sein muss. Es macht mehr arbeit und kostet auch mehr Performance, da du ja nun bis zu 7mal durch den ganzen Logik und render kram gehst(nicht die masse an Triangle oder die Füllrate ist das Botleneck, heute ist es die masse an Drawcalls).

Ich hatte nach dem erfassen aller benötigten Objekte im Baum ein Pre-Processing step eingebaut.
Dieser hat die VBOs und Materials der Objekte zusammen gesucht und dann die Drawcalls, eines jeden VBOs nach den Materials sortiert.
Damit wird die Anzahl der Shader und Texturbindings auf ein minimum reduziert und ledeglich die günstigeren VBO bindings erhöht.
Dann wurde das ganze Triangle-Mesh in den Z-Buffer gezeichnet und dann mit tiefen Test in das FBO gezeichnet(reduziert den Overdraw massiv und Shader sind in der regel sehr teuer,so das sich schon bei wenigen Pixeln man den extra Triangle rendering schritt wieder raus hat). Dann braucht man auch nicht mehr das solid Mesh sortieren
Was ich nicht mehr fertig gemacht habe, ist die Alpha Problematik, da muss man ja die Alpha Flächen richtig sortieren und nach dem solid mesh rendern.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also meine Fragen zum Leveldesign bezogen sich jetzt nicht vorrangig auf die Performance und Optimierung. Die Eingliederung der Elemente in Octrees und Scenegraphs will ich erst später angehen. Mir kommt es vor, als kommen 3 Untergliederungsvarianten der "Szene/Welt/Level" auf, je nach dem Kriterium, das man zugrunde legt:

- Visuelle Unterteilung: Das tatsächliche Modell. Nimmt man ein einziges Modell für zb. den gesamten Untergrund (Boden) der Welt? Zerstückelt man ihn? Werden Berge auf den Boden gesetzt oder sind sie Bestandteile des Bodens? usw usf
- Logische Unterteilung: Wie werden etwaige Modelle, die die visuelle Unterteilung darstellen, logisch untergliedert. Bestes Beispiel wäre ein Feldbasiertes Spiel. Wie unterteile ich meine Landschaft in logische Felder, auf denen ich mich bewegen kann?
- Performance Unterteilung: Wie unterteile ich meine Szene anhand des geringsten "Renderaufwandes"? Octrees, Scenegraph, Culling etc.

Mir ist jetzt eben wichtig, die Brücke zwischen dem ersten und dem zweiten Kriterium zu bekommen. Klar ich kann prozedural einige Elemente entwerfen und aneinandersetzen. Aber wie bekomme ich dann eine durchgehende Information darüber, wie groß ein Feld steht, welche Einheit auf welchem Feld steht usw usf?


Lässt sich irgendwie ziemlich schwer formulieren ^^ Sorry

Dafür nutzt man ein Scene Graph, dieser muss nicht nur Grafische Elemente Enthalten sondern auch Logik Daten.
Prinzipiell ist ein SG die Daten als Graph präsentiert, die Logik setzt dann auf diesen SG auf.
Je nach dem wie du dein SG designen willst, musst du das Node anpassen.
Also du kannst es generisch halten und ein Pointer von UserData in jeden Node zur verfügung stellen oder du Löst die Sache über Vererbung. 2. ist OOP mässig super toll allerdings kommt nun das "aber" ^^. Diese Variante wäre übelst langsam und braucht ne menge Code, während Pointer einfach nur getypecastet werden und man an seine eigenen Daten ran kommt, welche man für die Logik braucht.
So kann man z.B. ein Record nehmen, welches im ersten 4Byte eine ObjektID hat und dann danach die Daten kommen.
Anhand der ObjektID kannst du sicher gehen, das dein Typecast nicht in die falsche richtung geht und du musst nicht noch Klassen mit dir rum schleppen. In dieses Record kann man dann z.B. ein BulletObjektID rein packen, Callbacks und so weiter.

Wenn du nun eine Physik hast, dann ist es die Kunst es möglichst einfach an den SG an zu binden.
Eine Idee meiner Seite wäre ein Physik Baum in deinen SG ein zu führen, also einfach ein leeres node mit namen Physik und da drin hängst du für jedes Physik Objekt ein Node ein. Diese müssen auch noch ein ein anderes Node, wo der Renderer durch läuft. Wenn du also dein Update durch geführt hast, dann kannst du das Node von oben bis unten durch gehen und alle Objekte mit den neuen Positionen und Ausrichtungen updaten.
Alles, was nicht mit der Physik läuft, z.B. einige Partikelsysteme, Deko oder ähnliches kommt dann in ein Node-Tree, mit dem Namen "Rendering". Du kannst doppelte Buchführung machen, also alle Daten für Physik und Rendering halten oder NodeLinks einführen, die einfach nur auf ein anderes Node zeigen(nun hast du wirklich ein Graphen).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hmm... Ich weiß jetzt nicht wie es Shaddow geht, aber ich kann mit den Detailinfos von dir (TAK) nicht aufs Gesamtkonzept schließen. Vor allem die Architekturentscheidungen fehlen mir.
Die "Schönheit" eines Codecunstructs kann man ja erst dann erkennen, wenn man das Konstrukt und seine Auswirklungen wirklich überblicken kann.

Das Thema Szenegraph wurde bei uns (an der Uni und auch hier bei DGL) nie wirklich gut aufgearbeitet. Ich stand damals an der Uni auch vor nem Berg an Effekten die einzeln ganz toll waren, aber wie man die miteinander kombiniert wurde nicht erklärt.

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

Verstehe ich gut, deswegen hab ich mal fix nen Diagram gemacht.
.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ok, dass macht die Sache zumindest schonmal etwas strukturiert. Jetzt wäre aber wichtig zu wissen, wieso man dieses Node Konzept überhaupt verfolgt (also die Architekturentscheidung die gefällt wurde). Man baut ja nicht aus lauter Lust und Laune - also manche schon - komplexe SW Architekturen, sondern man verspricht sich etwas davon.

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

Meine alte hatte keine Link und Instance Ableitungen, welche ich dann aber als Fehler in mein letzten Konzept aus gemacht hab und seit dem kein neuen SG geschrieben hatte. Eigentlich war es mehr ein SceneTree und kein Graph, da erst das teilen von Informationen und verknüpfen untereinander ein Graphen mit sich bringt.

Das Letzte Konzept lief sauber, hatte aber auch keine Phyisk(war reines rendering). Das Instancing hab ich über eine extra Klasse gelöst, welche Ressourcen verwaltet hatte und halt dann den gleichen Pointer immer und immer wieder zurück gab, wenn er schon in der Liste geladen war. Das ging auch prima aber ich halte es als Node viel schöner und übersichtlicher. Die Physik und AI nutzen oft die gleichen Spacial Information, da sind Links von Vorteil.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004