Tach,

WARNUNG,
ich komme heute mit vielen vielen fragen, dies wird ein ellenlanger thread ich weisses jetzt schon .
Also los gehts:

Ich will ne richtige brauchbare !EINFACHE! 3D Engine unter OpenGL schreiben.
Das problem ist aber, ich hab bestimmt schon 30x versucht ne engine zu bauen.
Am Ende scheitert es aber immer an der Struktur, weil ich dann irgendie total alles umcoden muss und dann wäre es einfacher komplett wieder von vorne anzufangen.

Ich will nun von anfang an wissen, wie sollte man am besten anfangen.
Delphi + OpenGL Kenntnisse hab ich, OGL nicht so ausgeprägt wie Delphi, aber es sollte reichen, die ganzen Tuts auf DGL hab ich alle durch, bis auf das Script tutorial das war mir doch ein wenig zu hoch oder irgendwie noch keine lust gehabt dafür. Schatten, Reflektion, Planar mapping, Lightmapping kapier ich alles, das ganze hatte ich ja auch schon in nem editor versucht einzubauen, wie gesagt VERSUCHT.

Jetzt mal eine Struktur die ich mir vorstelle:

***************************************************************************

zur info:
Man sollte auch einen übersichtlichen guten programmierstil bewahren:::
also wenn man nen Type record macht, dann:



Also T = Type und R für Record...


usw

Constanten, Globale Variablen, Variablen die in einer Klasse sind sollte man auch gut beschriften like:



ich finde das sehr übersichtlich und man weiss dann ganz schnell um welchen
typ es sich handelt und für class, aber damit jeder den code gut verstehen kann find ich das schon wichtig.

***************************************************************************

weiter gehts mit der struktur:

// Hier stehen alle Konstanten sachen drin wie versionssnummer, variablentypen aus OGL, farbtypen usw.
engine_types.pas

was könnte da rein:
TVector
TColor
TVertex
TFace
TPolygon
TPlane
TMatrix
TTexcoord

kurzes beispiel:


Das problem ist aber, das es später wenn wir viele solche Klassen haben, dann alles
unübersichtlich wird, deswegen sollte man jeden eigenen typ in ne eigene datei speichern.

wie ist es aber nun, muss TVector ne Klasse werden ? Ne Klasse wäre unsinnig, da diese immer
wieder initialisiert werden muss, also nehmen wir anstatt class nen object.
Da dieses Object viele proceduren braucht, würde ich sagen... ne eigene datei wäre sinnvoll.
engine_vector.pas. <- da soll dann wirklich nur der vector drin sein... oder könnte man da noch was reinmachen.

und so gehts weiter halt, ich könnte jetzt jede typ erläutern, aber ich will heut au noch heim ne ?



So hab ich bis jetzt immer angefangen meine engine zu mache, alles codemässig gut strukturiert aber
so gut wie nix geplant, was überhaupt in die engine rein muss.
Das sollte man eigentlich vorher machen, aber ich denke ich bin nicht der einzigste der einfach drauf los proggt.
Was natürlich total der fehler ist

Also was bringt uns dieser code oben, wenn nix geplant wurde... nix, also sollte man sich erstmal ne planung überlegen:

itsch, ni, san, go:

- Eine Types Unit mit kleintypen und konstanten

- Eine OpenGLRenderer mit Initialisierung von mehreren Rendernkontexten, unabhängig ob Panel oder Form,
berechnungen für Timebased movement, FPS usw sollten auch drin sein.

- Eine Vector Unit mit funktionen zum addieren, subtrahieren, multiplizieren, dividieren
von Vectoren und mehr (dotproduct, length, crossproduct, invert, interpolate usw)

- Eine Texture Unit mit funktionen um Texturen des typs BMP, JPG, TGA zu laden und zu über glBindTexture zu benutzen.
Darin sollte auch eine Texture Listen klassen sein, damit man texturen dynamisch verwalten kann.

- Eine Matheunit in den alle wichtigen Funktionen zum berechnen der wichtigesten dinge drin sind.
Ich finds nicht gut, z.b. die geometry.pas von Mike Lischke zu nehmen, weil 1. sie ist in assembler (das verstehen nich viele leute)
und 2. ist diese total riesig und man muss dann die type strukturen von mike nehmen.

- Eine World Unit, wo Leveldaten gerendert und berechnet wird.
Meiner meinung nach das komplexeste an einer engine.

- Eine Physics Unit, wo Berechnungen drin sind, z.b. Ego-Shooter bewegung (Nehe Style).
Kollionsberechnung ??? Gehört diese da rein ?

- Eine Light Unit, tja... jetzt kommt das problem, light units was soll da rein ???
Radiosity berechnung, diese könnte man ja auch in der world unit machen, TCLight ? TOLight ? TRLight ?

- Eine Sound Unit, für sound halt... ist das einfachste überhaupt an ner engine.

- Eine Steuerungs Unit, Steuerung halt, GetKeyAsyncState ? Oh man, einfacher gehts wirklich nicht.

- Eine Netzwerk Unit, das ist schon kompilizierter, was darein soll... weiss ich selbst nicht.



So, das ist mal ne struktur wie ichs mir vorstelle.
Jetzt will ich mal eure ideen, vorschläge hören:::

Ok, dat wars... sorry kann sein das es ein bissel komisch geschrieben ist, ich nehme
kaum acht auf rechtschreibung.

matane,
Final

hm, also ich schreib mal einfach, was mir in den sinn kommt:

- mach für die Vektoren kein Object oder Record oder Class, packs einfach in ein Array rein, das is leicht zu verwalten und man kanns auch schon als VertexArray nutzen.

- überleg dir, wie du das ganze darstellen willst, VertexObjects, VertexArrays, DisplayLists. Das sind so die Möglichkeiten, darauf hin musst du auch deine Mesh Verwaltung hin trimmen.

- Wie soll dien Lighting aussehn, Lightmaps, mit Shadowmap oder dynamisch. Wenn dynamisch, dann musst du dich entscheiden, welche Methode du nimmst. Oder evtl auch ne mischung. Wie sollen an sich die Schatten aussehn, projizierte Schatten, Stencil Schatten

- Wie willst du deine Geometry animieren? Keyframe, Boneanimation, oder beides.

- Stell dir das mit dem SOund nich so einfach vor, ne gute SOund Engine is nich so simpel, wie man denken mag, schau die mal OpenAL an.

- leg keine riesige Struktur an, sondern mach alles Stück für Stück, sonst legst du das projekt von anfang an zu groß aus und es wird nix, also fang mit einer Klasse an und erweiter das dann

- drauflos programmieren ist nich weiter schlimm, aber du darfst nur kleine Schritte machen, bau dir ein Basisgerüst und erweiter dieses. So mach ich es jedenfalls.

- welche Extensions willst du unterstützen? Evtl musst/kannst/solltest du auf den jeweiligen Grafikchip hin optimieren.

- Wie willst du dein Geländer verwalten. Octree, BSP, Portal Darauf hin musst du auch deine Verwaltung auslegen.

so, das ist so das, was mir als erstes in den SInn kam.

mfg,
DEnnis.

_________________
Bush's on a highway to hell with the whole world blind, leading it straight into the flames.

Ich habe mal ein Struktur Bild von meiner Engine hochgeladen. Ob das für einen selber sinnvoll oder nicht ist muß jeder selber entscheiden, denn jeder hat vermutlich einen anderen Programmierstil. Zumindest ist das eine denkbare Lösung.<a href='http://www.delphigl.com/upload/enginestruct.zip' target='_blank'>http://www.delphigl.com/upload/enginestruct.zip</a>

mir ist noch was eingefallen:
du solltest darüber nachdenken, ob du auf MultiThreading aufbauen willst, oder nich. Das dürfte die Struktur deiner Engine doch erheblich beeinflussen.

Und noch ein Rat von mir, fang nicht mit irgendeiner Unit an, sondern bau die erst eine Basisklasse, in die du alles implementierne kannst, um es zu testen, dann hat man schneller Ergebnisse und bleibt daher motivierter. Und klammer dich dabei nicht an optimale Leistung, sondern erstmal an leserlichkeit und leichtverständlichkeit, schliesslich wirst du noch viel an der Basisklasse rumwurschteln. Optimier lieber erst hinterher, wenn alles läuft, sonst baust du diene Funktionen 10 oder 15 mal um und das ist nich Sinn der Sache.

mfg,
Dennis.

_________________
Bush's on a highway to hell with the whole world blind, leading it straight into the flames.

ein vektor und ein vertex beinhalten eigentlich die gleichen daten (3*float oder 3*integer ...)
ich hab daher ein TVectorVertex = array[0..2] of TGLFloat; draus gemacht.


gruß
rochus

_________________
http://www.rochus.net

Also ich hab mich überlegt, das die engine nicht Grafikkarten abhängig sein soll, sondern z.b. Bumpmapping einmal Hardware seitig über Register_Combiners oder Softwareseitig über Emboss Bumpmapping. Und z.b. Grafiken wo kein MultiTexturing oder nur 2 einheiten davon haben, soll der rest dann mit normalen Blending gemacht werden, oder wenn man z.b. kein Detailmapping will, kann man das abschalten, Grafiken die 4 oder höher texturen pro pass rendern können sollen natürlich alles schön mit MultiTexturing darstellen.
Alles soll aber abschaltbar sein, also Bumpmapping, Detailmapping, Lightmapping sollte immer abgeschaltet werden können.

Was Schatten angeht, im moment kenn ich nur Stencil Buffer schatten methode, die ich auch kapier... den rest kapier ich momentan noch nicht.

Wegen dem Vertex:

Also nen Vertex ist bei mir das:



oder ist es sinnvoller die texcoords einzeln zu machen und dann auch über StartIndex, EndIndex zuzuweisen ?



Jetzt kurze frage zu Faces, in einem Face müssen ja wirklich nur Index daten und die Normale stehen oder ?
Und ein Face hat ne Start korrdinaten (Start eines Polygons A) und ende Koordinaten (Ende eines Polygons C).
oder sollte man mehrere korrdinaten beachten ? Also z.b. um nen 5 Eck zu machen ?

wie siehts aus mit Shadern, wie könnte man ne einfache shader struktur machen, wo man für jedes Face unterschiedliche Texturen drüberlegen kann, nicht immer nur Base-Light-Detail-Bump.
Wo man auch Blendoperationen einstellen kann alle q3a. Weil ich will keine Statische Texture Struktur, weil für manche sachen brauch man einfach kein bumpmapping, Lightmapping usw.

Wegen dem MultiThreading... ich wüsste jetzt nicht warum ich Threads benutzen sollte, und wie...
Hatte es so vor, einfach ein normales Idle Loop zum Rendern und berechnen zu nehmen.
Für was bräuchte man Threads bei ner Engine, versteh ich jetzt nich ganz.

matane,
Final

PS: Ich hab mich überlegt, muhahahha Krasses deutsch wa ?

Das hast du dir ja was vorgenommen.

Ich betrachte deine TVertex und frage mich:
- wie du Texturkoordinaten für multiple Textureinheiten unterstützt
- ob du keine punktweisen Farb/Alphakanalinformationen brauchst
- ob Punktnormale generell eine schlechte Idee sind

Ich sehe dein TFace und frage mich:
- ob du alle Schnittpunkte eines "Faces" via GL_POLYGON versenden willst
- ob du evtl. die Möglichkeit berücksichtigst Schnittpunktdaten mittels GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, GL_QUAD_STRIP zu optimieren, oder WENIGSTENS die Möglichkeit viele Dreiecke zu einem glBegin glEnd Paar, bzw. glDrawElements zusammenzufassen
- wo du die Ebenengleichung speicherst, auf dass man evtl. mal Kollisionserkennung auf Polygonebene einbauen kann

Ich inspiziere dein TWorld und frage mich:
- wann du eigentlich Materialeinstellungen und Texturen änderst
- ob alle deine Vertices als Weltkoordinaten vorliegen, da anscheinend keine Möglichkeit vorgesehen wird, die ModelView Matrix zu ändern
- ob es nicht ganz praktisch wäre zumindest noch eine weitere Unterteilungsmöglichkeit in Objekte zu haben, die unabhängig voneinander bearbeitet werden können

Wenn ich mir das jetzt durchlese, klingt es kritischer, als es eigentlich gemeint ist - also nichts für ungut (ich wollte nur nicht so elendsviel schreiben).

Du solltest dir erst mal überlegen, was du konkret mit deiner Engine machen willst - denn je nach Art der Anwendung, kommen evtl. völlig andere spezielle Algorithmen zum Einsatz. DANN kann man anfangen sich zu überlegen, wie die entsprechenden Szenarien am besten im Speicher repräsentiert und als Grafik dargestellt werden - ganz zu schweigen von Sound- und (evtl.) Netzwerkunterstützung.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Jo ich weiss ^_^



Texture Koordinaten tja da gehts schon los, das müsste man dann mit dem Shader system verbinden.
Also wenn man 4 Texturen angibt für ne wand z.b. Base-Bump-Lightmap-Detail, dann brauchst ja für jeden Vertex 4 Texcoords.

Farb,Alphakanalinformationen brauchst, meinst du alphakanal bei ner Texture ?? der wird in der texture gespeichert wo sonst.

Punktnormale, erstens versteh ich deine satzaufstellung nicht und zweitens wenn du meinst für jeden Vertex, wieso ich dachte immer es reicht wenn man für ein Face eine Normale hat.



GL_TRIANGLE_STRIP, weil das funzt bis jetzt am besten ohne probs , GL_POLYGON brauch ich nich, es soll ja alles nur Dreiecke sein. Ebenengleichung ? du meinst Plane ?? Wo könnte man die speichern auch im Face ?


Jop als Weltkoordinaten, aber wegen Modelviewmatrix ... hmm daran hab ich gar nicht gedacht.
Objekt:



matane,
Final

@MultiThreading:

Du wirst nunmal nich schaffen, deine CPU allein mit deiner Engine durchgehend voll auszulasten, also verschenkst du Leistung und damit Zeit, was sich in der FramRate wiederspiegelt. Du kannst z.B. den Grafikteil von Input, Sound und Netzwerkcode trennen und diese dann parallel laufen lassen, wobei halt alles in deiner HAuptklasse zusammenlaeuft. Dadurch lastest du deine CPU aus und deine App profitiert, wenn du es richtig machst, auch deutlich von HyperThreading

@Vertices und TexCoords:
warum willst du das noch in nem Record machen? der Zugriff auf ein Array ist deutlich einfacher, wie ich finde.
Im übrigen solltest du das ganze trennen, da du sonst denke ich nur schlecht vertex arrays nutzen kannst, jedenfalls ist das meine Befürchtung dabei.

@Fallback:
Mit den Fallbackmethoden hast du dir ja was aufgehalst! Du vervielfachst den Aufwand dadurch merklich, wenn du das ganze emulieren willst.
Du brauchst das eigentlich nicht, da man irgendwo schon ein paar Hardwaresache als Standard annehmen kann. MultiTexturing unterstuetzen die meisten karten mit mind. 4 textureinheiten, also is der fallback davon relativ sinnlos und nebenbei bemerkt auch extreeeem ressourcenfressend, da du ja alles mehrmals zeichnest.

mfg
Dennis.

_________________
Bush's on a highway to hell with the whole world blind, leading it straight into the flames.

Wenn du manchmal OpenGL Licht verwendest, solltest du schon die Möglichkeit offen halten, Normale pro Punkt zu vergeben, um weiche Farbübergänge zu erhalten. Ausserdem kannst du noch, unabhängig von der Textur, eine (ab OpenGL 1.4 zwei) Farben (RGBA) pro Punkt vergeben, mit der du z.B. die Textur überblenden kannst. (Ab OpenGL 1.4 gibt's sogar noch eine Nebelkoordinate).


@VertexArrays:


Prinzipiell ja - allerdings gibt es die Möglichkeit,
1) einen Interleave festzulegen oder
2) kombinierte Vertexeigenschaften in Vertex Arrays zu übergeben, was je nach OpenGL Implementation sogar schneller sein kann, als unterschiedliche Vertex und Normale- Arrays (z.B.) zu verwenden.
Mit einzelnen Arrays ist man aber auf jeden Fall flexibler.


Da hab' ich deinen Code missverstanden - ich dachte jede Plane sollte ein koplanares, konvexes Vieleck sein

Beim nochmaligen Durchlesen hab' ich deinen Beitrag ohnehin ziemlich schlampig überflogen - du hast ja gefragt, welche Möglichkeit flexibler ist - und hast das Ganze ja noch gar nicht implementiert:

Eindeutig die Zweite:

<!--pas--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>Delphi-Source </td></tr><tr><td id='CODE'><!--pas1--><pre> TWorld = <span class='reserved'>class</span>(TObject)
<span class='reserved'>private</span>
fFaces : TFaces;
fVectors : TVectors;
fTexcoords : TTexcoords;
<span class='reserved'>public</span>
<span class='reserved'>end</span>;</pre><!--pas2--></td></tr></table><span class='postcolor'><!--pas3-->

Nenn es nicht TWorld sondern von mir aus TObj3D, leg (wenn du's brauchst) ein paar zusätzliche Arrays für zusätzliche Textureinheiten/Vertexfarben/Punktnormale an, speichere eine potentielle Transformation, Textur, Material mit ab, eventuell Kindobjekte/Joints/Bones/Vertexlisten für Frameanimationen - und du hast den Grundstein eines brauchbaren Objektsystems (allerdings erst für die graphische Darstellung unterschiedlicher Einzelobjekte).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

So sinnlos ist es nicht, es gibt noch viele leutz die ne GeForce 2 oder niedriger haben, und haben nunmal nur 2 Textures pro pass. Das reicht gerade mal für base+Lightmapping, das problem ist ja auch. Das ich ja shader machen will, wo ich sagen kann.. das ne oberfläche 4 Texturen haben kann und z.b. ne Fenster scheibe Blending nur eine Texture braucht, verstehst du... das ist das problem.
Das Blending braucht man ja z.b. auch für Partikel.

Aber das mit dem Threads ist ne gute idee, das glaube ich versuch ich zu machen, also einfach 4 Unterschiedliche Threads machen ?, Render, Berechnungen, Sound, Tastatur ?

Ok, hab mir grad mal überlegt wie man ne soundengine machen kann, also sounds abzuspielen ist nicht schwer, aber das dynamisch auf Erreignisse wirken lassen ist hard.

matane,
Final

render thread kannst nich machen, OpenGL is nich threadsicher!
du kannst eine hauptklasse machen, in der deine renderschleife is und von der aus, wird z.B. Sound, Netzcode, Phyik/Animation angesprochen, musst du halt selbst durchdenken, wie du das aufbaust.

@Fallback:
Du kannst es nich allen recht machen und wenn du es gleich so groß aufziehn willst, dann wird dir das Projekt wahrscheinlich übern Kopf wachsen. Wenn du 4 Texturen benutzen willst, aber nur 2 unterstütz werden, hieße das, dass du die Geometry 2mal zeichnen müsstest, da die meisten Oberflächen nunmal wahrscheinlich mehr als 2 Texturen haben werden, dann wirst du fast die gesamte Geometry 2mal zeichnen müssen, was einen deutlichen Leistungseinbruch zur Folge hätte und wer will am Ende noch mit 15FPS oder so noch ein Programm laufen lassen? Du musst dir über den Sinn im klaren sein. Es ist z.B. sinnvoll, wenn automatisch entschieden wird, ob Shader benutzt werden, oder ähnliches, aber jede Extension mit nem Fallback auszurüsten ist wirklich sinnlos.

mfg,
Dennis.

_________________
Bush's on a highway to hell with the whole world blind, leading it straight into the flames.

Erkläre das mal bitte? Wieso ist OpenGL nicht Threadsave? Ich persönlich mache das innem Thread (auch schon mit mehreren) und hatte überhaupt keine Probleme.


So wir die Geschwindigkeit auf kleinen Karten unweigerlich ins Bodenlose sinken (was unvermeidbar ist). Allerdings würde ich das fast für besser empfinden, wenn man die Detailtexturen und Bumpmapping weglassen würde. So könnte man auf natürlichem Wege die anzahl der Texturen auf 2 drücken. Vor allem wenn man bedenkt, dass die TNT 2 auch kein so super tolles Bumpmapping unterstützt.

Zu den Texturen:
Heutzutage würde ich auf jeden Fall Bumpmapping verwenden.
Bei diffusem Bumpmapping und zwei Texturen mußt du pro Licht halt 3 mal zeichnen, bei einer Karte mit 4 Texturen reicht eben einmal aus. Für GeForceFX und Radeon 9700 Karten gibt es ja wieder die gemeinsame Extension ARB_FRAGMENT_PROGRAM. Es ist ja nicht so aufwendig dann zwei oder drei Funktionen mehr zu schreiben.
ARB_VERTEX_PROGRAM wird ebenso wie ARB_VERTEX_BUFFER_OBJECT auf allen NVida Karten untertstüzt, auf manchen aufgrund von Hardware Beschränkungen eben nicht so effizient. Das heißt, das einzige von du wirklich unterscheiden mußt sind nur die Pixel Shader.
Die zusätzliche Geometrie bei mehreren Renderschritten macht das ganze nicht so viel langsamer, weil die Engine vermutlich ehe durch die Füllrate begrenzt wird. Auf einer GF4 ist jeder TriangleStrip bestehen aus 2 Dreiecken über einer Größe von 6*6 Pixeln durch die Füllrate begenzt. Das heißt wenn deine Flächen größer sind, dann kannst du auch mehr davon nehmen. Auf jeden Fall würde ich ein Vertex Format mit einer Größe von 32 Byte nehmen. Man kann ja Texturekoordinaten und Normalen ins smallint packen.

Ja klar, ich glaube das wäre das beste... Karten mit nur 2 Units haben nur Base+Lightmap und karten mit 4 haben dann base-bump-detail-light. Aber ich wills ja nicht Statisch machen, also base, Lightmap muss immer sein... Nein... sondern das muss ja alles über shader gesteuert werden. Also ich hab mir folgende shaderstrukutur überlegt:

engine_shader.pas:


Jetzt kommt noch die frage, wo bring ich jetzt die Texture Koordinaten unter ???
Ist es sinnvoll TShaderProgramType so zu strukutiren ?

@Lars: Ich kapier nich was diffuses Bumpmapping ist, oder Refelktives, EnviromentBumpmap (Was mit übrigens verdammt gut gefällt).

EnvBumpmap ist doch einfach Bumpmap mit der Cubemap oda ? Würd ich mal annehmen?

matane,
Final

Zur info: Jeglichen Code den ich bis jetzt gepostet habe, wurde alles frei bauch raus erstellt, also es wurde bis jetzt noch nicht eine zeile code programmiert
Momentan alles noch Planung in einem sauberen Word Dokument ^_^