Hi ich hab mal ne Frage.

Und zwar möchte ich eine eigene OGLEngine schreiben, kann mich aber einfach nicht entscheiden, wie ich das rendern von objekten darin anstellen soll.

Bisher habe ich mir folgendes gedacht:



Was meint ihr denn dazu?

Und wenn das schlecht sein sollte (wo ich mir schon ziemlich sicher bin) wie stelle ich so was denn an?

Also die Idee mit den Objekten für jedes Primitiv sind zwar auch Objekt Orientierter Sicht sicherlich Ideal. Allerdings die Aufteilung ist für meinen Geschmack zu Atomar. Besonders, da du dafür Klassen benutzt. Wenn du sagen wir mal 100.000 Instanzen davon erstellst und wieder freigeben willst. Dann bekommt der Speichermanager von Delphi einen Schock. Das Erstellen geht zwar schnell aber das Freigeben kann dann durchaus viele Sekunden dauern.

Außerdem verschließt du dich so neuen und irgendwann zwingen vorrausgesetzten Technologien wie Vertex Buffer Objects. Was alleine das Rendern um ungeahnte Faktoren beschleunigt. Typischer wird von daher sein, dass du Actors oder Meshes haben wird. Also Personen und Objekte. Und diese bestehen aus einer Vielzahl von Vertices etc. Für die Speicherung intern würde ich da aber auch eher einen zusammenängenden Speicherbereich bevorzugen. Ich bin aber nicht der "engine" Experte. Ich würde aber in jedem Fall eine zu extreme Zerstückelung in Klassen vermeiden.

Und sonst kommt es natürlich stark darauf an für was deine Engine gemacht werden soll.

PS: Willkommen im Forum

Das Problem ist, dass ich doch auf jeden fall einen type für ein polygon haben muss.

Wenn ich nun weiter denke, stellt sich mir die Frage, wie ich das alles verbinden soll.

D.h. wie und wo soll ich die Polygone bzw. Quads unterbringen? Und ich wollte dringend eine engine haben, die größeren Objekten wie T3DGroup und allen, die davon abstammen den Befehl z.B. Move übergeben kann.

So sollen sich z.B. mover und andere dinge realisieren lassen.

Insgesamt habe ich den Aufbau ein wenig von der SpriteEngine aus DelphiX kopiert (das grundmodell).

Aber meine frage ist nun: Wie kann ich das anders mache?

Immerhin soll das game einen Editor bekommen und noch später ingame veränderbar sein --> man rennt rum und sagt z.B. "erstelle hier einen block oder sonst was"

Hier ist z.B. eine testanwendung, die meine engine nutzt (die engine ist aber erst 2 tage alt^^)

Ich schliesse mich meinem Vorredner an und kann nur empfehlen, eine art Meshklasse zu erstellen und dort listen mit vertice,normal,tex,...-daten zu speichern und zur laufzeit ein zeichenobjekt zu zuweisen.

TZeichenverhalten=object
private
FVerts:...
FNorms:...
...
public
Constructor Create(verts:array of TVector3f;norms:array of TVector3f;...);
procedure Draw; virtual; abstract;
end;

TVBOZeichenverhalten=object(TZeichenverhalten)
procedure draw; override;
end;

TTriangleZeichenverhalten=object(TZeichenverhalten)
procedure draw; override;
end;
...

TMesh=object
public
verts:array of TVector3f;
normals:array of TVector3f;
....
Zeichenverhalten:TZeichenverhalten;
end;

Man kann das auch über ein Interface machen, wenn keine Variablen zum einsatz kommen, was aber bei VBO unvermeidlich wäre.

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

Projekte: https://github.com/tak2004

Ich habe aber leider ein kleines Problem mit "Array of..." und das heißt Delphi 3 !

Kennt da jmd. ne andere lösung für oder könnte ich auch einfach nur ne TList nehmen und die Vertices als classe definieren?

Eventuell ist es für den anfang nicht so gut gleichg in form eines headers zu beginnen. Besonders dann nicht wenn dort schon quads und ähnliches zu sehen ist. Ansätze wie diese enden meistends in einer grafik bibliotek die zwar ein etweas höherers level als Opengl hat, jedoch eine extrem eingeschränkte funktionalität. Jedoch kann man heute unter einen reinen grafikkbibliotek keine grafikengine mehr verstehen.

Eine Engine solte sich darin auszeichen:

Der angezeigte inhalt sollte sich verändern lassen ohne das das Hauptprogramm neu compeliert werden muss. Ist das nicht der Fall ist es eher eine bibliotek. Ein denkares beispiel für eine engine wäre z.B. Autorennen bei dem mit hilfe eines menüs oder einer konfigurationsdatei die Strecke gewählt werden kann. Besser wäre jedoch wenn eine scripting unterstützung vorhanden ist.

Schaffe nicht nur eine menge von klassen/objekten, sondern verwalte sie auch in einem Scenegraph. Ohne einen (zumindest einfachen Baumbasierendem) Scenegraphen endet das ganze wieder ein einer samlung von funktionen/klassen /objecten. Auch hier ist scripting eine wertvolle unterstützung...

Vermeide den immediate mode von Opengl (glBegin() glEnd()) und alles was darauf basiert. Diese funktionen fressen sich durch den ganzen code und sind langsam. Man findet sie besonders in fremdcode, die Modelle rendern. Besonders beispiele sind sind z.B. MD2 oder MD3 modelle, die quasi intern anweisungen haben welche opengl befehle verwendet werden sollen um die vertices in Stripes oder Fans zu rendern.
Das einzige sinvolle format sind Vertrexarrays (als VBOs) mit einem optinalem index (spart platz und beschleunigt).
Durchaus sinvoll ist es besser auf externe converter zu setzten als alle fileformate in die engine einzu bauen.

Kapsel alles ein was mit irgenwelchen Pointern zu tun haben könnte, dazu gehöhren auch die im letztem absatz genannten Vertexarray oder VBOs, Texturen o.Ä.

Bei texturen wähle besser ein sinvolles format. DDS hat sich als relativ brauchbar erwiesen und unterstützt auch S3TC textur kompression was nicht nur für die performance gut ist, sondern auch noch platz spart.

Nur dinge implementieren, die man selbst vrsteht und auch sinn machen. Keine versuche als einzelperson formate wie Collada (sehr dicke Spezifikation) Im besten Fall endet so etwas ein einem Collada viewer stat einer engine.

Das war jetzt nur der erste Teil Nun kommt die interaktivität:

Viele versuchen eine physik engine wie z.B. newton direkt einzubauen. Die fatale neben wirkung ist, dass Monate später jeglicher versuch scheitert das projekt multiplayer fähig zu machen. Wesendlich sauberer ist es physik und grafik über eine netzwerk schnittstelle zu trennen. Im single player modus läuft der server einfach auf dem gleichem rechner mit.

Vermeide es am Anfang tolle Effekte einzubauen. So etwas treibt nur die anzahl der zu wartenden Code Zeilen nach oben. Viele dieser dinge lassen sich später einfacher implementieren

Immer Optionen für die Zukunft offen lassen. Auf wenn beim "extreme programming" (komerziell gesehen wäre es wohl die am ehesten zu vergleichende entwicklungs technik wie beio privaten projekten) gesagt wird, das nur das implementiert wird was auch gebraucht wird. Macht es sin dinge und idee einfach als kommentar mit in den code zu schreiben. D.H. ein file format sollte so entwickelt werden das es auch in zukunfts erweitert werden kann. Oder das eine implementation die auf die schnelle im immediate mode von OpenGL implementiert wurde, sich später auf VBOs umstellen lässt, ohne das endlos daten konvertiert werden müssen.

Zum Schluss: überlesge ob es nicht sinn macht sich auf einen teilbereich zu spezialisieren gegebenfalls mit anderen zusammen zu arbeiten...

_________________
Lumina plattform unabhängige GLSL IDE

1.) Es geht ja um den Grundaufbau einer Engine. Und das was ich mir da ausgedacht hatte funktioiert ja auch und ermöglicht einen späteren ausbau ohne probleme.

2.) Gibt es nicht so etwas wie ne gute Engine, wo man das grundprinzip abgucken kann? (sollte indoor sein)

Delphi 3?

Wie wärs hiermit ?

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

*lol* ich glaube hier gibt es Missverständnisse, was eine Grafik-Engine ist: http://de.wikipedia.org/wiki/Grafik-Engine
Ein paar Klassen ergeben noch keine Engine.



Ich weis jetzt nicht, warum du noch "Netzwerk" einbaust, aber ansonsten stimm ich voll zu. Die Physik sollte getrennt behandelt werden, insofern man wirklich eine Engine machen will. Gibt ja nicht umsonst Physik-Engines =)

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup