The Khronos Group, an open consortium of leading hardware and software companies, today announced that the glTF™ 1.0 (GL Transmission Format ) royalty-free specification for transmission and loading of 3D content has been finalized for Ratification and is immediately available for use by tools and application vendors. glTF is an efficient, interoperable asset delivery format that compresses the size of 3D scenes and models, and minimizes runtime processing by applications using WebGL™ and other APIs.
Es mag nicht ganz hier herpassen, da ja in der Java-Welt nicht sooo viele Leute sooo viel mit 3D-Zeugx machen, aber ein paar würden mir da schon einfallen
Das GitHub-Repository ist unter GitHub - KhronosGroup/glTF: glTF – Runtime 3D Asset Delivery . Ich verfolge das schon eine Weile, weil es ein interessantes Dateiformat z.B. auch für in-Game-Modelle sein könnte. Es gibt auch anstehende Erweiterungen („binary GLTF“), mit dem tatsächlich die OpenGL buffer mit in die Datei gepacht werden können, und man somit eine Szenen/Modellbeschreibung hat, die extrem kompakt und Hardware (d.h. OpenGL-) nah aufgebaut ist.
Also mein erster Eindruck dazu ist: Es sieht wesentlich geordneter und strukturierter aus, als andere Formate, das ist positiv. Das interessiert mich durchaus.
Die Spec habe ich auch noch nicht komplett gelesen. Insgesamt ist das natürlich ein ziemlich komplexes Ding. Ich hatte nur auf der Arbeit mit einer „Teilmenge“ (+Erweiterungen) von GLTF zu tun. Und ich fand den Gedanken interessant, dass es dabei um ein Dateiformat geht, das 1. SEHR nah an OpenGL (und damit sehr kompakt) ist und 2. von praktisch jedem gerendert werden kann… oder können sollte. Ob WebGL oder Desktop, Android, Linux, wasauchimmer - wobei genau das natürlich durch die Nähe zu OpenGL erst erreicht wird.
Ich hatte (vor etwa einen Jahr) auch schon ein paar Zeilen Code geschrieben, um besagte (winzig kleine!) Teilmenge zu lesen und was auf den Bildschirm zu bringen. Aber wenn man das vernünftig und systematisch machen wollte, müßte man da anders rangehen. Spätestens wenn es um komplette Animationen (bzw. Szenenbeschreibungen geht) wird das sicher recht aufwändig, und bei den „Techniques“ (d.h. Materialien/Shadern) auch konzeptuell nicht so einfach.
Zwischendurch hatte ich dann nochmal angesetzt, bin dann aber „abgedriftet“ - das ging dann erst in Richtung von etwas, was aus einem JSON-Schema Klassen generiert (ähnlich wie JAXB aus XSDs). (Andernfalls würde einem so ein Kleinkram, ohne auch nur einen Hauch von Ahnung vom ganzen Drumherum zu haben, gar nicht auffallen :D).
Aber mal konkret: Wäre eine 1:1-Repräsentation dessen, was im Schema steht, ein gangbarer Weg?
Ich bin mir zwar nicht sicher, aber wahrscheinlich meinst du mit Schema das:
Ich denke man wird auf jeden Fall eine ganz gewöhnliche Textur und Shader Klasse brauchen. Außerdem Klassen für das laden der Indexe und Vertices aus den .bin Dateien. Natürlich muss das ganze strukturiert werden, da ich mich aber mit diesem JSON Format nicht wirklich auskenne, weiß ich nicht ob hier eine Klassentrennung nötig wäre. Mit den Animationen/Skins in den .bin Dateien kann ich leider gar nichts anfangen.
PS: Weiß jemand, wie man die .bin Datei kodieren muss? Bei mir kommt da nur diese schwarzen Balken in Notepad++ raus(Kennt man vielleicht). Dabei sollten dort ja die Vertices stehen, oder hab ich da was falsch verstanden?
Dort ist festgeschrieben, was in dem JSON vorkommen kann, welche Bedingungen gelten, und wie es zu interpretieren ist. Ähnlich zu einem XML-Schema. Siehe auch JSON Schema and Hyper-Schema
/**
* A set of primitives to be rendered. A node can contain one or more meshes. A node's transform places the mesh in the scene.
*/
class Mesh extends GlTFChildOfRootProperty
{
/**
* An array of primitives, each defining geometry to be rendered with a material.
*/
private MeshPrimitive primitives[];
... getter+setter...
}
Mit viel Yak-Shaving (die meiste Zeit ist in den JSON-Schema-Zu-Datenmodell-Generator geflossen), und eigentlich nur um zu sehen, ob Rendering “Sinn macht” oder zumindest “funktioniert”, und nur als hingehackter Test, vorbei an vielen Konzepten, die eigentlich hinter glTF stehen (speziell die Accessors für die BufferViews), und natürlich ohne Szenen, Knoten, Animationen und Techniques, und vieles ignorierend, was sich bei glTF so selbsverständlich auf WebGL bezieht … trotz allem hat der Inhalt dieses Screenshots gerade bewirkt, dass ich meinen rechten Mundwinkel einige Millimeter nach oben gezogen habe:
Auch wenn ich davon ausgehe, dass diese Bemerkung keine verkappte Kritik daran war, dass man einen RenderingEnvironment noch nicht sagen kann, dass AA unterstützt werden soll, habe ich mal intern ein new PixelFormat(32, 0, 24, 0, 4) an den AWTGLCanvas übergeben - schittebön :
PS: Weiß jemand, wie man die .bin Datei kodieren muss? Bei mir kommt da nur diese schwarzen Balken in Notepad++ raus(Kennt man vielleicht). Dabei sollten dort ja die Vertices stehen, oder hab ich da was falsch verstanden?
Ist zwar jetzt etwas zu spät aber: Diese BIN-Dateien sind praktisch OpenGL-Buffer, die direkt als Dateien rausgeschrieben wurden (und zwar ggf. sogar mehrere OpenGL-Buffer am Stück). D.h. man liest diese Daten erstmal so, wie sie sind - z.B. in einen (direct) ByteBuffer - das ist am flexibelsten und direktesten. In den BufferViews steht dann, welche Teile dieses riesigen Memory-Blocks „einzelne“ OpenGL-Buffer sind - praktisch nur definiert über offset+länge der Einzelteile. (Deswegen auch ein ByteBuffer: Da kann man sich dann mit ByteBuffer#slice die passenden Scheibchen rausscheiden ). Etwas frickeliger wird’s dann bei der Frage, wie diese einzelnen Buffer zu interpretieren sind. Also, ob das nun 3D-float-vektoren (z.B. Vertexpositionen) sind, oder 2D-float-vektoren (z.B. Texturkoordinaten), oder Indizes (als unsigned ints, oder unsigned shorts…?!). Das alles geht aus den Accessors hervor. Richtig kompliziert wird es, wenn man die dann in einem Shader richtig verdrahten will. Da entsteht dann ein Gewirr von Referenzen, mit Meshes, Techniques, Parameters, Semantics und Uniforms … vielleicht schreib’ ich das irgendwann mal detaillierter auf (in der Hoffnung, dass ICH es dann kapiere :D). In den Buffern können aber auch andere Daten stehen - also nicht nur „Vertexpositionen für einen OpenGL-Buffer“, sondern z.B. auch der Informationen über Animationen - praktisch als eine Folge von „Keyframes“, etwa von 3D-Vektoren oder Quaternionen, die (wenn man sie richtig interpretiert) irgendwann in Transformationsmatrizen landen, und sowas hier erlauben (was ich gerade als ersten, noch SEHR rudimentären Test mal hingepfuscht habe: )
Wieder nicht viel neues, aber intern viel rum-refactort, um das ganze weniger spezifisch für die Rendering-Lib zu machen. Dabei ist aber immerhin hinten runter gefallen, dass man jetzt relativ leicht zwischen den verschiedenen Kameras umschalten kann:
Ich hadere ja immernoch damit, dass ich https://java.net/projects/vecmath/ verwende … das ist nicht mehr ganz so up to date, wird nicht mehr weiterentwickelt und so… @Fancy , @Zombiepriester , @mymaksimus Hat schonmal jemand https://github.com/JOML-CI/JOML verwendet? Sieht ganz vernünftig aus - bin nur nicht sicher, ob sich das nicht von einer kleinen, pragmatischen, in sich abgeschlossenen Vector-Lib zu irgendwas größerem entwickelt - die letzten Entwicklungen sahen auch etwas suspekt aus: MUSS das mit dem Unsafe denn sein? Ich hatte ja schonmal angeregt, vielleicht eine Java-Version von GLM zu schreiben - genau DAS sucht man ja eigentlich. Es gibt zwar https://github.com/jroyalty/jglm , aber das sieht auch recht tot und nicht überzeugend aus…
Kennt jemand gute Alternativen?
Naja, das ist eine Testszene. Die Texturen sind 256x256, und die ganze Szene insgesamt hat <4MB (also weniger, als EINE Textur in einem “richtigen Spiel” hat :D)
aber: Diese BIN-Dateien sind praktisch OpenGL-Buffer, die direkt als Dateien rausgeschrieben wurden (und zwar ggf. sogar mehrere OpenGL-Buffer am Stück). D.h. man liest diese Daten erstmal so, wie sie sind - z.B. in einen (direct) ByteBuffer - das ist am flexibelsten und direktesten. In den 
). Etwas frickeliger wird’s dann bei der Frage, wie diese einzelnen Buffer zu interpretieren sind. Also, ob das nun 3D-float-vektoren (z.B. Vertexpositionen) sind, oder 2D-float-vektoren (z.B. Texturkoordinaten), oder Indizes (als unsigned ints, oder unsigned shorts…?!). Das alles geht aus den 
