spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"Sebby"«

Hallo,

ich hab mir mal ältere Spiele und auch ganz aktuelle angesehen und etwas festgestellt,

Eigentlich machen es alle Klassisch:

Eckenliste

* Trennung von Geometrie und Topologie

Es ist mir nicht 100% klar was Du meinst. Sagst Du die Topoligie wird überhaupt nur implizit angegeben?

Zitat

* minimale Redundanzen (Punkte werden nur 1x abgelegt)

Ja, macht Sinn.

Zitat

* Kanten werden mehrmals durchlaufen und ausgegeben

Ich würde sagen, >50% der Formate geben Kanten gar nicht an.
Bei den restlichen werden wiederum >50% Kanten nur einmal angeben und dann indizieren. So machen wir das z.B. bei unserem Küchenplanungsprogramm: Flächen verweisen auf Kanten, Kanten auf Eckpunkte. Wir machen das weil wir eine Liniendarstellung haben und die Kanten hierfür Eigenschaften haben.

Zitat

* Suche nach zu Kanten gehörenden Facetten nicht effizient möglich (nur mit erschöpfender Suche möglich) Für alle Kanten in F1 (jedes Eckenpaar) suchen wir in allen weiteren Facetten, ob sie enthalten ist, wenn Nein dann Randkante)

Du musst zunächst unterscheiden wie die Daten auf Platte und im Speicher vorliegen. Auf Platte werden die dafür nötigen Informationen nicht explizit vorhanden sein, da das redundant wäre und man es ja beim Laden "berechnen" kann.

Im Speicher wird es ein Renderer (inkl Renderer eines Spiels) normalerweise auch nicht haben, da er es nicht braucht.

Andere 3D Applikationen (z.B. Modeller) nutzen manchmal die "winged edge" Struktur (siehe Google).

Zitat

Soweit so gut, nur hab ich folgendes festgestellt, bei fast allen spielen kommt nach diesen daten noch ein Datenblock der fast identisch mit dem Block der Scheitelpunkte ist. Wenn ich diesen überschreibe geht trotzdem noch alles.

Vielleicht die Normalen?

Zitat

was könnten das für daten sein? was braucht man denn alles wenn man z. B. Fahrzeuge steuert oder allgemein eine Simulation macht?

Fürs Rendern? Wenn ja, sieh Dir 3D Formate an, z.B. die Beschreibung des *.X Formates in dem DXSDK.

Für die Physik? Ausm Kopf:
- Zumindest für TerrainPolys ein "physikalisches Material" z.B. Asphalt, Grass, Kies etc. Dies beeinflusst Sound und physikalische Größen wie Haftung.
- Info für Damage Model (wie schrottet sich Dein Auto?)
- Info für Kollisionen wenn Du nicht die normale 3D Geometrie nehmen willst.

Man kann auch etliches Spiel- oder Genre-spezifisches haben:
- Info für Effekte, z.B. wo ist der Auspuff?

Übrigens gibts ja mehrere Open Source Rennspiele.

Meist braucht das System die Normalen zur Belichtungsberechnung und meistens sind diese nicht aus anderen Daten errechenbar, also müssen sie in den Dateien gespeichert werden.