4. Grafikenginedesign (OOP mit OpenGL)

Grafikenginedesign (OOP mit OpenGL)

  • S

    @nep:
    Links zu

    spl@t schrieb:

    übersichtliche UML-Diagramme oder sowas in der Art

    würden auch reichen.
    @LiquidAcid:
    Ich nahm an, dass ein Forum da ist um unter anderem Newbies zu helfen, und es beispielsweise ermöglicht, Anderen die Arbeit 100000de Zeilen Code zu durchsuchen um die Struktur diesens zu erfahren, durch Posten eines Links zu einem UML-Diagramm im jpg-Format, der vielleicht in den Bookmarks vorhanden sein könnte, abzunehmen.
    Zur Vektorklasse: Das geht? Hm, da muss aber die Stride-Parameter bei jeder Änderung der Vektorklasse umständlich anpassen, oder würde ein sizeof(Vektorklasse) genügen, wenn die Koordinaten am Anfang stehen?

    0

  • Ja.

    Bye, TGGC \-/

    0
  • L

    spl@t schrieb:

    Zur Vektorklasse: Das geht? Hm, da muss aber die Stride-Parameter bei jeder Änderung der Vektorklasse umständlich anpassen, oder würde ein sizeof(Vektorklasse) genügen, wenn die Koordinaten am Anfang stehen?

    Bitte erst das Redbook lesen, dann denken 😉

    Meine Vektorklasse sieht folgendermaßen aus:

    class basic_vector
    {
    // der ganze public mist

    private:

    float xyz[3];
    }

    Wenn ich jetzt ein ein basic_vector Array als Vertexarray nehmen will dann brauch ich überhaupt keinen Stride angeben, da die Vektoren alle schön dicht hintereinander gepackt sind.

    Wenn ich einen texturierten Vertex nehmen sieht das natürlich wieder anders aus. Da ist Stride dann ganz einfach sizeof(textured_vertex), das wären in meinem Falle 5 DWORDs (2 für UV und 3 für XYZ) - ist doch echt easy 😉

    cya
    liquid

    0
  • C

    vielleicht hilft dir das auch wenn es keine UML diagramme auf der page hat, so werden doch namespaces und funktionen beschrieben

    http://irrlicht.sourceforge.net/docu/index.html

    0
  • S

    LiquidAcid schrieb:

    Bitte erst das Redbook lesen, dann denken

    Bin leider erst in Kapitel 3, aber Vertex Arrays wurden bereits behandelt, und dazu wurden C-Arrays benutzt, was nützt mir da also dieses Buch?

    LiquidAcid schrieb:

    Wenn ich jetzt ein ein basic_vector Array als Vertexarray nehmen will dann brauch ich überhaupt keinen Stride angeben, da die Vektoren alle schön dicht hintereinander gepackt sind.

    Wieso ist stride 0 wenn die Klasse noch Funktionen enthält, liegen die dann nicht zwischen den Daten im Speicher? Sorry aber da kenn ich micht nicht so aus.

    cof schrieb:

    vielleicht hilft dir das auch wenn es keine UML diagramme auf der page hat, so werden doch namespaces und funktionen beschrieben

    http://irrlicht.sourceforge.net/docu/index.html

    Na bitte, das ist doch schon das was ich gesucht habe! Aber es nützt mir leider trotzdem nicht allzu viel.

    Im Moment stell ich mir die Einteilung wie sie in einem flipcode-Tutorial vorgenommen wurde am sinnvollsten vor:
    Tools (extern halt)
    Utility (nützliche Funktionen, Datenstrukturen)
    Console (zur Kommunikation mit der Engine, hab keine Ahnung wie das ohne globale Variablen gehen soll)
    System (Fenster, Sound, Bedienug, Dateien laden, Grafik)
    Render (logischerweise der 3d-Teil)

    Sollte man nun für alle diese Bereiche eine große Basisklasse schreiben? Oder sollte System z.B. ein Consolenobjekt enthalten, in dem wiederrum die Eigenschaften gespeichert sind?
    Hmpf, vielleicht sollte ich auch einfach erstmal das Red Book zuende und den Scott Meyers durchlesen...
    Hätte aber lieber praktisch gelernt...

    0
  • L

    spl@t schrieb:

    Bin leider erst in Kapitel 3, aber Vertex Arrays wurden bereits behandelt, und dazu wurden C-Arrays benutzt, was nützt mir da also dieses Buch?

    Sowas wie ein C-Array gibt es nicht. Arrays funktionieren sowohl unter C als auch unter C++ genau gleich. Deshalb kapier ich nicht was hier immer diese ominösen C-Arrays sollen...

    spl@t schrieb:

    Wieso ist stride 0 wenn die Klasse noch Funktionen enthält, liegen die dann nicht zwischen den Daten im Speicher? Sorry aber da kenn ich micht nicht so aus.

    Dann rate ich dir mal ein Grundlagenbuch über C/C++ durchzulesen. Aber auch Denken wäre hier nicht verkehrt. Der Speicherverbrauch wäre enorm wenn jedes Objekt einer Klasse im Speicher noch zusätzliche Kopien seiner Memberfunktionen/Methoden ablegen würde. Wohin kämen wir denn dann? LOL, das wär ausserdem alles redundante Information.
    Das einzige was hinterlich sein kann sind Klassen die polymorph sind, also eine vtable beinhalten. Aber die Basistypen polymorph zu gestalten ist sowieso absoluter Schwachsinn.

    IMHO solltest du erstmal mit C/C++ zu Rande kommen bevor du jetzt mit OpenGL anfängst. Deine Kenntnis der Sprache ist meiner Ansicht nach nämlich noch recht unzureichend. Das ist jetzt nicht böse gemeint, aber du wirst arge Probleme bekommen wenn du nicht die Grundlagen beherrscht.

    cya
    liquid

    0
  • O

    LiquidAcid schrieb:

    spl@t schrieb:

    Bin leider erst in Kapitel 3, aber Vertex Arrays wurden bereits behandelt, und dazu wurden C-Arrays benutzt, was nützt mir da also dieses Buch?

    Sowas wie ein C-Array gibt es nicht. Arrays funktionieren sowohl unter C als auch unter C++ genau gleich. Deshalb kapier ich nicht was hier immer diese ominösen C-Arrays sollen...

    c array: typ name[zahl];
    c++ array :vector<typ> name;

    0
  • L

    otze schrieb:

    c++ array :vector<typ> name;

    Ein Vector ist kein Array, sonst würde er ja nicht Vector heissen. Obwohl man einen STL Container natürlich als Vertexbuffer nehmen könnte. Man muss halt nur sicherstellen dass die Daten linear im Speicher existieren. Das wäre ja afaik nur bei Vector der Fall (und auch nur wenn der Datentyp nicht bool ist).

    cya
    liquid

    0
  • S

    Wenn du nicht weißt, was es C-Array sein soll, dann tut mir das sehr Leid.
    Und ein Vector ist durchaus ein (dynamisches) Array, der Name ist gleichgültig.
    Übrigens komme ich mit C++ meiner MEinung nach durchaus "zu Rande". Das mit den Funktionen ist schon klar, wenn ichs mir mal überlege. Aber warum kein sizeof(Vectorklasse) als Stride angeben, das machts sauberer.

    0
  • O

    LiquidAcid schrieb:

    otze schrieb:

    c++ array :vector<typ> name;

    Ein Vector ist kein Array, sonst würde er ja nicht Vector heissen. Obwohl man einen STL Container natürlich als Vertexbuffer nehmen könnte. Man muss halt nur sicherstellen dass die Daten linear im Speicher existieren. Das wäre ja afaik nur bei Vector der Fall (und auch nur wenn der Datentyp nicht bool ist).

    Die Klasse ist auch kein vector, immerhin ermöglicht sie keine punktberechnung im n dimensionalen raum 🙄, das zum thema namen.

    jetzt mal ernsthaft:
    vector ist (fast) genausoschnell wie ein array,es leistet funktionell her genau dasselbe wie ein array,der einzige unterschied zu nem array ist, dass die daten nicht an einem stück hängen-was aber auch ein vorteil sein kann, und in anbetracht der enormen funktionalität des vectors nicht ins gewicht fällt, ergo trägt der Vector zu recht den namen "c++ array".

    0
  • L

    Du kannst ja gerne neue Namen für bereits existente Dinge einführen, aber der STL Container Vector bleibt ein Vector für mich. Ein C++ Array funktioniert genauso wie ein Array in C.

    Und offensichtlich hört man mir hier auch nicht richtig zu. Ich habe doch grade betont, dass der STL Vector einer der wenigen (der einzige?) Container ist bei dem die Daten linear im Speicher existieren. Jetzt wird mir hier schon wieder widersprochen. LOL, irgendwie isses doch merkwürdig.

    @splat: OK, wie du willst. Aber ich werde hier kein weiteres Grundlagenwissen vermitteln. Das mußte dir dann schon selbst aneignen.

    cya
    liquid

    0
  • S

    naja, lassen wir das mit den Arrays lieber 😉

    LiquidAcid schrieb:

    @splat: OK, wie du willst. Aber ich werde hier kein weiteres Grundlagenwissen vermitteln. Das mußte dir dann schon selbst aneignen.

    Das finde ich ehrlich sehr schade. Ich bin mir sicher dass du mir noch auf einige Fragen Antworten geben könntest. Meinst du nicht dass das für einem dummen kleinen Flamewar übertrieben ist? Sollte ich etwas arrogant reagiert haben, tut mir das Leid.

    Was halten denn die anderen Erfahrenen hier von der Aufteilung der Engine in genannte Bereiche? Wie macht ihr sowas?
    Mag sein dass ich noch zu schlecht für sowas bin, aber mich interessiert das jetzt halt. Lasst euch doch nicht alles aus der Nase ziehen 😉

    0
  • S

    Im Übrigen gibt es Programmiersprachen, in denen das "Array" "Vector" oder "Feld" heißt... Soviel dazu. 🕶

    0
  • L

    Sind wird hier denn im BASIC Forum??? 😃 *gg*

    0
  • E

    Na das Konzept die Vektorenklassen per Array hintereinander zu packen hat aber
    auch einen _sehr_ großen Nachteil:

    Man muss für jede Flag-Kombination eine eigene Klasse erstellen. Bei bis zu 8
    Texturkoordinaten, XYZ-Koordinaten, Normalenvektor, Farben, etc. kommt da eine
    gigantische Menge zusammen.

    Außerdem hätte das vererben von einem Basis-Vektor noch den Vorteil, dass man
    sämtliche anderen Klassen (Engine, Objekte, VertexBuffer) mit diesem füttern
    kann. Schließlich wird dann jeweils auf die richtige Ursprungs-Klasse zuge-
    griffen.

    Also: Wie macht ihrs? Würde mich über weitere Beiträge freuen, da ich selbst
    gerade an dieser Stelle hänge. Denn wenn man sich hier falsch entscheidet...

    Bei Irrlicht und OGRE bin ich was das angeht noch nicht weit genug durchge-
    siegen. Irrlicht hat zwei Vektor-Klassen, die aber max. ein Tex-Koor-Set
    abdecken und OGRE hat nur eine Basis-Vektor-Klasse. Da muss ich noch was
    übersehen haben... 😕

    0
  • S

    Juhuu, ich WUSSTE doch, dass sich auch noch andere für dieses Thema interessieren MÜSSEN 😃
    Jetzt fehlen nurnoch die Antworten 😋

    0
  • S

    *push* :p

    0
Anmelden zum Antworten