RoadMap:Mapformat
Aus PantheonWiki
Inhaltsverzeichnis |
Features
Fertig/implementiert in [F]ormatdefinition, [L]oader, [E]xporter
- Mehrere Arten von Modellen in der Szene
- Statisches Level, alles was sich nicht bewegt (Bäume, Berge, 'Bäude) [FLE]
- Lichter [FLE]
- 3D-Sounds [FL]
- Gräser, wiederholender Kleinkram und Gebüsche, durch Mesh wird deren Vorkommen und Dichte bestimmt.
- Bewegliche Aktoren (fliegende Plattformen oder ähnliches) [F]
- Benötigt Animationtrack-Files
- GameObjecte [FLE]
- Partikelsysteme [FL]
- Zonen
- Allgemeine Zonen ("Dunkler Wald", "Oberstadt", "Planquadrat A38"). [FL] Dabei auch Parameter für:
- Soundzonen [FL]
- Lichtzonen [FL]
- EAX-Einstellungen [F]
- Triggerzonen (mit Ruby Klassennamen) [FL] , Bodenplattenschalter (Physik oder Zone?)
- Allgemeine Zonen ("Dunkler Wald", "Oberstadt", "Planquadrat A38"). [FL] Dabei auch Parameter für:
- Wegpunktnetz
- benannte Knoten [FL]
- benannte Pfade [FL]
- Umwelteinstellungen
- Sky [FL]
- Fog [FL]
- Veränderte Naturgesetze (Gravitation, Zeit, Reibung, ...)
- Besondere Oberflächen (Wasser)
-
Startpunkt für Player/PartyPlayer/Party sind in der Map gewöhnliche GameObjecte, werden dann im Ruby-Skript anhand der ID gefunden, verarbeitet und übergeben - (vereinfachte)Kollisionskörper (unsichtbare Wände, Baum als Zylinder und kollisionslose Krone, Rampen auf Treppen) [F]
- Kamerapunkte in speziellen Räumen (Zeldamodus)
- Zerstörbare Objekte
Ein Beispiel für das Format ist im SVN-Repository unter rl/trunk/docs/documents/scene_format_proposal.xml zu finden ([1])
Bemerkungen zum Mapformat
- Bemerkungen zum .scene-Format
- Die Physik-Proxy-Typen convexhull und mesh können nicht skaliert werden, sie orientieren sich immer an der Mesh-Größe
- Bei zu wenig angegebenen Punkten oder einem mesh, das in einer Ebene liegt, verursacht der Typ convexhull Speicherfehler, daher wird dann stattdessen box verwendet
- Ob der Typ capsule so umsetzbar ist, muß noch geklärt werden, er wird eigentlich über Radius und Höhe definiert, das ist so in Blender aber nicht direkt realisierbar
- Modeller benutzen ihr Tool um eine .xml - Scene zu erzeugen, die Verweise auf Meshes enthält und Metainformationen
Map Processor
- Externes Tool nimmt diese Scene und führt folgendes damit aus
- LODs für markierte Meshes erzeugen
- Zusammenfügen - Alle statischen Meshes werden verschmolzen Dabei werden für verschiedene LOD Riesenmeshes generiert, die die jeweiligen LOD Repräsentationen der EinzelMeshes enthalten, bzw. bestimmte, kleine Meshes gar nicht mehr, je nach RenderingDistance.
- Lichtberechnung - Es werden Lightmaps für alles statische generiert und als zusätzliche UV Koordinaten in das große Mesh gebacken, Eventuell werden auch nur VertexColors der Meshes moduliert, durch die Beleuchtung der Lightmaps. Das UV Mapping wird auch auf das niedrige LOD angewandt.
- Gras u.ä. verteilen - Anhand des Bedeckungsmeshes (zB. einem Stück des Terrains) und Metainformationen werden Meshes zufallsverteilt/gedreht und Anhand der Normalen des Meshes ausgerichtet und anhand der Lightmap/Vertexcolors abgedunkelt.
- Zerschneiden - anhand vorgegebener Blockgrößen wird das Riesenmesh mit dem inkludierten Gras zerschnitten. Dabei werden die SchnittKantenInformationen gespeichert, um bei niedrigen LODs die Kanten an die nächsthöheren LOD Kanten anzupassen. Danach haben alle, auch die niedrigsten LODs die höchstLODdigen Kanten. Eventuell niedrigere generieren.
- Speichern - Die Blöcke werden gespeichert
- In Zip kombinieren
Offene Punkte
- Berechnung des PVS auf Zellenbasis.
- Im Ogre-Forum auf Plausibilität prüfen lassen.
Erstmal normal rendern, dann evtl. eigenen Scenemanager bauen.
