@Oc2k1
ATI unterstützt eine Form Instancing schon mit der R200 Reihe.
TrueForm heisst es und es wertet Flächen mit unterteilung in mehere Polygone und neupositionierung auf.
http://www.3dconcept.ch/artikel/npatches/2.htm

Was soll hier nicht behandelt werden:
Grundlagen zur Programmierung, auch Design Patterns fallen hierbei unter die Grundlagen die man beherschen sollte.
OpenGL Funktionalität, hierfür gibt es den Einsteigerpfad oder auch den Bereich Hintergrundwissen.
Allgemeine Probleme der Entwicklung von größeren Projekten, hierfür raten wir zum Kauf eines entsprechenden Buches oder einer intensiveren Recherche im Internet.

=Das Ziel definieren=
Wenn ihr eine [[Engine]] entwickeln möchtet, so solltet ihr euch zuerst darüber klar werden was ihr mit dieser [[Engine]] erreichen möchtet. Häufig steht hier der Wunsch es einfach einmal von Grund auf selbst gemacht zu haben. Nicht selten möchte man nun mit der eigenen Engine auch noch ein Spiel entwickeln, damit die Engine nicht ausschließlich zur eigenen Weiterbildung geschrieben wird. Hier also zwei Hinweise welche mehr mit Softwareentwicklung denn mit OpenGL zu tun haben:
# Verwendet bestehende Software, ihr solltet nicht alles selbst machen. Beispielsweise eine bestehende Physik-Engine wie Newton oder Sound-Bibliotheken wie fmod werden (wenn es dem Programmierer primär um die Grafikprogrammierung geht) gerne verwendet. Auch Objekt- oder Leveleditoren sollte man sich natürlich nur selbst schreiben wenn man gute Gründe dafür hat, ansonnsten sollte man bestehende verwenden und ggf. (zwecks mehr Komfort) einen Exporter dafür schreiben. Bei den [[Link]]s findet ihr sicherlich einige Ressourcen die euch bei eurem Projekt unterstützen werden.
# Überlegt euch vor eurem wirklichen Start was ihr alles benötigt. Grundlegende Dinge kann man natürlich vorher bewältigen, also beispielsweise ein Virtual File System, spezielle Kontainer-Klassen, OGL- und Fensterklassen, Routinen für mathematische (und bei Bedarf auch physikalische) Berechnungen, ... . Aber bevor ihr das klassische "3D-/2D-Objekt" erstellt solltet ihr schon ziemlich genau wissen was ihr später alles damit machen möchtet. Hierfür hilft beispielsweise eine Liste von Use-Cases sowie ggf. eine Liste der Objekte die ihr in eurem späteren Spiel haben möchtet. Hier solltet ihr auch bereits eine gute Vorstellung der verwendeten Tools besitzen und wenn ihr auf etwas stoßt was von einem Tool kaum oder gar nicht unterstützt wird (beispielsweise Bone-Animationen, ...) so solltet ihr hier die verwendeten Tools überdenken oder eine Lösung für das Problem finden.

Und beim Ziel sei auch noch angemerkt dass die Performance ebenfalls ein Teil des festgelegten Zieles sein sollte. Es ist einfach eine Engine zu erstellen welche alle geometrie-Daten darstellen kann (lassen wir hier erstmal die grafischen Effekte raus). Es ist dafür umso schwerer eine Engine zu machen welche die benötigte Geometrie auch effizient darstellt.

=Objekte in der Welt=
Wie Objekte in die Welt eingefügt werden ist ein weiterer wichtiger Aspekt einer Engine. Obwohl die Frage nach den Attributen eines allgemeinen 3D- oder 2D- Objektes ebenfalls sehr viel mit Softwareentwicklung allgemein zu tun haben, ist diese Frage dennoch verhältnismäßig spezifisch für Engines zu beantworten. Grundlegend können wir sagen, dass ein Objekt folgende Arten von Daten benötigen wird:
* Position
* Aussehen
* Physikalische Eigenschaften
* Sound
* Engine spezifische Daten
Und in der Zukunft vielleicht sogar Daten über Geruch oder Geschmack.

==Position==
Die Position ist meistens ein essenzieller Bestandteil der Objektverwaltung. Die Position muss hierbei nicht nur eine 3D Koordinate sein sondern kann ggf. auch Aufschluss darüber geben ob sich dieses Objekt in oder an einem anderen Objekt befindet. Die Position eines Objektes wird häufig als Matrix (oder auch als [[Quaternion]] in Verbindung mit einer [[Translation]]) zum hierachisch übergeordneten Objekt angegeben, wodurch beispielsweise die 4 Reifen eines Autos 4 Objekte mit der selben Geometrie und einer fixen Translation, jedoch einer variablen Rotation angegeben werden könnten. Da sich üblicherweise in einer Welt verhältnismäßig wenig Objekte bewegen, könnte man zusätzlich zur Transformation bzgl. des übergeordneten Knoten auch noch bei jeder Bewegung eines übergeordneten Knoten oder dieses Knotens eine neue absolute Transformation berechnen.

Zusäztlich zur Position kann (oder sollte) auch noch eine Geschwindigkeit und ggf. sogar ein Beschleunigungs-Vektor für ein Objekt vorhanden sein. Im Endeffekt könnte es aus der Sicht eines Softwareentwicklers wünschenswert sein, dass alle Attribute der Position zusammen mit den Physik-Attributen alle relevanten Informationen für physikalische Berechnungen liefern und alle Attribute für Aussehen zusammen mit der Position alle relevanten Informationen zur Darstellung liefern. Somit wären physikalische Attribute und Aussehen voneinander komplett unabhängig.

==Aussehen==
Die Attribute welche mit dem Aussehen eines Objektes zusammenhängen sind in Bezug auf das Thema dieses Wikis wohl besonders interessant. Hier können wir die typischen Eigenschaften auch weiter unterteilen:
* Geometrie: Wenn wir hier wiederum das Auto mit seinen 4 Reifen her nehmen, so können wir für die Geometrie ggf. [[Display Liste]]n verwenden. Die Geometrie kann bei animierten Objekten auch abhängig von den Animationsdaten sein. Zusätzlich kann man hier noch [[LOD]] Algorithmen verwenden um die Performance zu steigern sofern die Anwendung [[Vertexlimitiert]] oder ggf. auch [[Bandbreitenlimitiert]] ist. Im Falle von prozedualen Grafiken wie beispielsweise [[Partikelsysteme]] kann die Geometrie auch erst während der Laufzeit für jedes Frame neu berechnet werden.
* Animationen: Die häufigsten Animationsarten sind [[Bone-Animation]]en und [[Keyframe-Animation]]. Diese können ggf. die darzustellende Geometrie ändern.
* Verwendete Texturen: Wenn die Anwendung [[Bandbreitenlimitierung|Bandbreitenlimitiert]] ist und mehr Texturen verwendet werden als in den Grafikkartenspeicher Platz finden, so kann eine Sortierung nach den Texturen wichtig sein.
* ggf. relevante Lichter (wobei diese eher zu den Engine spezifischen Daten zu zählen sind)
* Sonnstige Materialeigenschaften und/oder Shader

==Physikalische Eigenschaften==
Verwendet man eine bestehende Physik Engine, so hat man meistens bereits einen recht guten Einblick welche Daten hier benötigt werden. Die Eigenschaften können hier anfangen bei Kollisionsvolumen und hin gehen zu Gewicht und Reibung. Wenn man eine Welt besitzt welche über das terrestrische hinaus geht, so kann beispielsweise auch noch Gravitation eine Rolle spielen. Die ungewöhnlicheren physikalischen Eigenschaften die ein Objekt besitzen muss werden meistens bereits bei der Spielidee klar und sind nicht selten auch ein wichtiger Bestandteil davon. Häufig begnügt man sich jedoch auch ausschließlich mit Kollisionsinformationen, welche ebenfalls einen Level of Detail besitzen können.

==Sound==
Ein Objekt kann ggf. eine Soundquelle sein und vor allem wenn man 3D Sound haben möchte, so spielt vor allem die Position und Geschwindigkeit des Objektes auch hier eine wichtige Rolle. Komplexere Objekte (Häuser oder allgemein Levels) könnten ggf. auch Daten über Echowirkung oder ähnliches besitzen, meist wird man derartige Daten natürlich zumindest für jeden Raum eines komplexeren Objektes angeben.

==Engine spezifische Daten==
Hier findet das wahre Leben der Engine statt. Angefangen von Daten welche für die [[Raumunterteilung]] nötig sind, bis hin zu Daten welche für die künstliche Intelligenz benötigt werden. Häufige andere Arten von Daten sind:
* [[Bounding Volumen]], also beispielsweise eine [[Bounding Sphere]] welche sowohl für physikalische Berechnungen, als auch für die Sichtbarkeitsberechnungen von Objekten verwendet werden kann.
* Ereignisse, welche von Animationen, Geräuschen und dem verschwinden eines Objektes oder dem erstellen eines neuen Objektes bis hin zu komplexeren Vorgängen wie es ein Lift oder Teleporter bietet alles auslösen können. Die Eigenschaften können durch die Verwendung von Scripten sehr flexibel gestaltet werden ohne etwas am Hardcode ändern zu müssen.
* Spezielle Daten für spezielle Objekte, beispielsweise durchscheinende Objekte können nach ihrer Tiefe sortiert werden, Lichter können ihren Einflussbereich bekannt geben, Portale ihre Zielkoordinaten und natürlich können auch Listen von Objekten erstellt werden welche in jedem Frame animiert oder transformiert werden.

=Verwaltung der Objekte=
Nehmen wir einmal an wir besitzen ein allgemeines 3D- (bzw. 2D-) Objekt und wir möchte viele dieser Objekte in unserer Engine verwalten. Die einfachste Variante ist natürlich, dass wir eine Liste besitzen in welche alle zu verwaltenden Objekte aufgenommen werden und diese können wir natürlich sehr einfach zeichnen und wir können auch Kollisionsabfragen durchführen. Wenn wir jedoch keine weiteren Informationen über diese Objekte besitzen, so müssen wir jedes Objekt mit jedem anderen Objekt auf eine Kollision prüfen, wir müssen jedes Objekt auf seine Sichtbarkeit prüfen (um zumindest etwas effizienter zu rendern), wir müssen für jedes Objekt alle Lichter berechnen usw. Hier können Raumunterteilungstechniken Abhilfe schaffen. Anzumerken sei noch, dass wir zum einen mehrere Raumunterteilungstechniken kombinieren können (so können wir beispielsweise komplexere Objekte wie Häuser auf einer Landschaft in einen Octree verwalten und jedes dieser komplexeren Objekte besitzt auch noch Portale um auch die Innenräume der Häuser effizient aus dem Zeichenvorgang auszuschließen). Wir können auch für unterschiedliche Verwendungszwecke unterschiedliche Algorithmen verwenden. Ein (etwas extremeres) Beispiel für unterschiedliche Algorithmen wäre:
* [[PVS]] und/oder [[Portale]] sowie ggf. zusätzlich noch einen [[Octree]] für Sichtbarkeitsabfragen
* Einen [[BSP-Baum]] für Kollisionsabfragen, ggf. auch hier zusätzlich noch ein [[Octree]]
* Ein Octree für das herausfinden von Objekten welche durch ein Licht beleuchtet werden können (wenn keine Hindernisse im Weg stehen).
Man könnte auch für Aussenlandschaften und Indoor unterschiedliche Algorithmen zur Verwaltung der Objekte verwenden. Die Verwaltung der Objekte ist einer der ausschlaggebenden Faktoren dafür, wofür die Engine geeignet ist und wofür sie weniger geeignet ist.

Des weiteren stellt sich natürlich die Frage ob spezielle Objekte wie Lichter, (teilweise) transparente oder durchscheinende Objekte, ggf. Portale, ggf. Octree-Knoten, ... im selben Kontainer landen sollten wie geometrische Objekte oder nicht. Dies ist jedoch wiederum eine Frage welche eher im Bereich der allgemeinen Softwareentwicklung von größeren Projekten angesiedelt ist.