Das wär’s dann erst mal.
Vieeel zu allgemein. Entsprechend kurz:
glDrawPixels. Heute würde man das Bild als Textur auf ein (Einheits-) Quadrat legen, und das Bildschirmfüllend renderingMeshes: Da könnte man lange drüber reden. Es gibt keine “einfache” Datenstruktur für Meshes, die für alle Fälle gut ist. Es gibt im wesentlichen zwei Ziele, die man mit Meshes haben kann:
Zu dem was Marco13 gesagt hat, ein Mesh ist erstmal nur ein Haufen Vertices und Texturkoordinaten und das reicht meistens komplett aus.
Manche nehmen das relativ simple “.obj”-Format, davon würde ich aber abraten weil es relativ kompliziert umkonvertiert werden muss weil die Daten sehr umständlich gespeichert sind.
In der Zeit in der man versucht das obj Format zu verstehen und umzusetzen - was kein Hexenwerk ist - kann man sich auch sein eigenes Format ausdenken und Importer/Exporter schreiben.
Ansonsten ist es ganz davon abhängig was man noch so machen möchte, sprich was für Informationen im Mesh noch gespeichert werden sollen. Z.B. LODs, ein Schattenmesh, Decalpositionen, Oberflächeninformationen für Physikal Based Rendering, verweise auf Texturen und Bump Maps…
Das meiste davon wird im 2D Bereich nicht benötigt.
Wie gesagt hast du meist eher ein Einheits-Quadrat das gezogen oder gestaucht wird und mit dem dann Texturen mit transparenten Pixeln gezeichnet werden.
[quote=“Marco13, post:2, topic:19033”]
Ja, wenn man ein paar Jahre Zeit hat.[/quote]
Das kann man so unterstreichen.
Das würde ich nicht so leichtfertig sagen. Es wurde schon ein ganzen Haufen Dissertationen über Mesh-Datenstrukturen geschrieben. Mit allem, was man sich da so unbedaft ausdenkt, wird man sich vermutlich früher oder später in den Fuß schießen - je nachdem, was man vorhat.
Für das reine GL-Rendering ist eine erste, einfache Mesh-Datenstruktur tatsächlich recht einfach: Ein Buffer mit Indices, und danach eine handvoll Buffers für die Vertex-Attrribute (meistens Positionen, Texturkoodinaten und Vertexnormalen). Für alles, was darüber hinausgeht, wird’s kompliziert. Half-Edge? Und was ist mit nicht-Mannigfaltigkeiten? Polygone oder nur Dreiecke? Ohjeh… Sowas wie https://www.openmesh.org/ ist recht bekannt. Für Java gibt es AFAIK nichts ähnlich generisches. (Ich hatte mal mit sowas angefangen, aber … eines von ca. 200 Projekten, die ich nie bis zur Veröffentlichung gebracht habe…)
Gerade OBJ ist so eine Stolperfalle: Es ist sehr beliebt, sehr verbreitet, und vermeintlich (!) sehr einfach. Dass es auch Polygone und nicht nur Dreiecke enthalten kann, ist eine kleine Lästigkeit, aber nicht schlimm. Dass es auch Bezierflächen und andere Sachen unterstützt, wissen viele nicht, aber die verwendet kaum jemand, deswegen ist das nicht so wichtig. Das größere Problem an OBJ ist: Es ist multi-Indexed! Es gibt für Vertices, Normalen und Texturkoordinaten getrennte Indices. Für GL braucht man aber eine einfache Indizierung. Wenn man also ein OBJ in eine einfach-Indizierte Struktur umwandeln wil, wird’s schon fummelig. (Deswegen hatte ich irgendwann mal ObjUtils::convertToRenderable geschrieben…)
Ansonsten sollte man für den Transfer von assets natürlich glTF verwenden. (Auch wenn es durch die Änderungen zwischen 1.0 und 2.0 einige Fragen aufwirft, die noch zu beantworten sind… bin mal gespannt).
Das meinte ich damit. OBJ ist ein relativ unscheinbar gestricktes Klartext-Format mit eher überschaubaren Features die für die meisten Hobby-Projekte ausreichend sein werden. Aber es ist unheimlich komplex und kompliziert aufgebaut.
Wer obj in Erwägung zieht sollte in Erwägung ziehen lieber sein eigenes Mini-Format stattdessen zu schreiben.
Alles was darüber hinaus geht, und da stimme ich dir vollkommen zu, ist ein standartisiertes Format besser am Platz als das Rad neu zu erfinden.
Jedoch wird man diese Rendering und Physik Techniken dann auch mithilfe einer Bibliothek umsetzen die dann schlussendlich sowieso ein bestimmtes (lizenziertes) Format vorraussetzt und mit Importern/Exportern daher kommt.
Was übrigens auch die Frage beantwortet was Spieleschmieden verwenden: Ich kenn da ein nicht unbekanntes Studio und derren Bekannte und die entwickeln ihr komplett eigenes Format für manche Sachen oder verwenden eben lizenzierte Formate und Techniken in Ihren Produkten.
Worauf sich das bezieht ist nicht ganz klar. Mit version 1.0 war glTF eigentlich offen und Ziel-Agnostisch: Wenn man einmal die Verdrahtung zwischen den techique- und program-Objekten hatte, konnte man jedes glTF-asset rendern. Selbst die fanciesten Sachen konnten dort mit einer relativ einfachen „Engine“ umgesetzt werden - hauptsächlich weil die Shader mitgeliefert wurden. Mit glTF 2.0 haben sie dieses Physically Based Rendering (PBR) mit in die core spec aufgenommen. Ich sehe das mit einer gewissen Skepsis: Man bekommt jetzt ein asset, mit einer Material-Beschreibung, und weiß erstmal nicht, wie das gerendert werden soll. Formal weiß man es, aber einen Shader zu erstellen, der das tatsächlich macht ist schwierig. (Ich befürchte immernoch, dass man da um einen Laufzeit-Shader-Generator nicht drumrumkommt…).
Trotzdem: An glTF und speziell dem PBR-Teil haben erstmals die Experten aus diesem Gebiet zusammen gearbeitet, mit dem erklärten Ziel, dort einen Standard zu schaffen. Da unterhalten sich dann wirklich die Leute von Allegorithmic, Unity, Microsoft, three.js, Unreal und anderen. Vielleicht wird damit die „Lizenzfalle“, die du, falls ich das richtig verstanden habe, angedeutet hast, aufgebrochen.
Danke für Eure Antworten. Ich versuche gerade, GLFW/GLUT/GLU, OpenGL, GLSL, LWJGL und WebGL zu lernen. Klappt auch ganz gut. WebGL finde ich auch gut, weil man sich über die Portabilität keine Gedanken machen muss - es läuft auf Linux und Windows (auch auf dem Handy, hab ich gesehen). Der Nachteil ist, dass jeder den Quelltext einsehen kann - das wäre bei einem compilierten C-Programm nicht so - aber das müsste ich dann für Linux und Windows einzeln compilieren.
Eine Herausforderung stellt sicher da, auch die Mathematik der MathLibs dahinter zu verstehen. Sehr viel Vektormultiplikationen usw. Ein Punkt wird mit einer Matrix multipliziert (M), wird mit einer Matrix multipliziert (V), wird mit einer Matrix multipliziert § usw.
Außerdem gibt es in JS inzwischen Klassen, sogar Vererbung wäre möglich - auch, wenn das syntaktischer Zucker wäre, und man immer this. schreiben muss.
Im moment bin ich gerade bei der Tastatureingabe: i(In), o(Out), w, s, a, d, q, e, r(Reset), up, down, left, right, z !!! 
- Wobei ich feststelle, dass es sinvoll sein könnte, die View-Matrix nicht zu verändern. Die View-Matrix sollte hinter dem Spieler bleiben, und der Spieler wird in der Welt bewegt?
Bei der Wahl der (geeigneten) Datenstruktur… kommt es sicher auch darauf an, ob man tausende Objekte hat - oder nur 3 oder 5.