glTF - What the ...? Eine Übersicht über die Grundlagen des GL Transmission Formats

Im glTF-News-Thread hatte ich mal angedeutet, dass ich mal versuchen könnte, glTF zusammenzufassen. Joa, das hab’ ich mal gemacht:

gltfOverview-0.1.0.pdf

Ja, gar nicht mal so übersichtlich, ich weiß :rolleyes: Glaubt irgendjemand trotzdem, dass sowas für irgendjemanden hilfreich sein könnte?

Das mit @Fancy , @Zombiepriester , @mymaksimus hatte ja schonmal geklappt, vielleicht diesmal wieder.

(Ich gehe davon aus, dass es nicht hilfreich ist, aber vielleicht hat ja jemand eine Idee, was man ändern müßte, um es hilfreich zu machen - ist ja Version 0.1.0 ;-))

meinst du generell?
Finds doch einfach heraus ^^ Gibt es nicht irgendwo Foren wo man sowas posten kann?
Ich weiß nicht… kannst es doch einfach mal irgendwo veröffentlichen, und schauen was die Leute davon halten?

*** Edit ***

aber ich find, das sieht sehr gut aus ^^

Ja, generell. In dem Sinne, dass man sich fragt: “Äh glTF…!? Was ist denn das?” und man sich das dann anschaut, und eine grobe Vorstellung davon hat. Also, was es ist, wie es funktioniert, wie die ganzen Entitäten eines glTFs zusammenhängen, speziell dieses buffer->bufferView->accessor-Konzept, oder auch wo die kleinen Shaderparameter herkommen.

Das ganze irgendwo “sichtbarer” zu machen, hatte ich schon in Betracht gezogen, aber ich wollte erstmal einen Testballon hier im kleinen Kreis starten (darauf bauend, dass jemand sich auch anonym dazu äußern und seine ehrliche Meinung sagen kann :D)

Ich finds gut, zumindest besser als die offizielle Dokumentation weil man hier alles auf einer Seite hat.
Nicht perfekt aber gut.

Ich denke das ganze könnte man noch um einiges komprimieren und damit noch lesbarer machen ohne Informationen zu verschenken.
Schöne Texte hast du geschrieben, aber könnte man das ganze nicht auch kürzer fassen?

Das Layout find ich klasse gemacht; jetzt wäre die Frage ob man es nicht noch ein bisschen besser machen könnte indem das Layout dem gltf Format ein bisschen eher entspräche?
Ist jetzt ein ganz persönlicher Eindruck. Ich mag es wenn Texte so strukturiert sind wie die Struktur die sie beschreiben. :slight_smile:

Wenn ich jetzt nur nicht am Handy wäre… Punkt 1 ist aber am wichtigsten, kürzer knapper und auf dem Punkt und mit besserem Schreibtil.

Zunächst einmal: Ich find’s klasse das du dir die Arbeit gemacht hast! :slight_smile: Da ich leider nicht den allergeringsten Plan von glTF habe kann ich das Sheet lediglich aus „praktischer“ Sicht betrachten - soll heissen ich selber würde mir einen solchen Sheet auf DIN-A4 ausdrucken und griffbereit halten oder abheften. Und dazu hätte ich noch eine Wunschliste:

  1. Eine s/w-Version des PDFs wäre schön, also ganz ohne Farben und Graustufen (nicht zuletzt weil sich schwarz auf rot beim Fotokopieren - ja, wird auch heute noch praktiziert - ganz schlecht macht…)
  2. Die Schrift ist generell recht klein, besonders bei den Quellcodes. Ich persönlich würde zwei gut lesbare Seiten ggü. einer unlesbaren Seite bevorzugen. (dabei am besten auch, wenn möglich, die Registerhaltigkeit beachten).
  3. Und um ganz vornehm zu sein: Für ein angenehmes Lesen sollte eine Textspalte iirc nur so ca. zwei Alphabete breit sein. Darüber hinaus würde es auch ausgewogener aussehen wenn die Zeilen in allen Spalten auf der gleichen Höhe stünden.
  4. Ein Rand zum Abheften wäre auch nicht zu verachten :smiley:

Nun, es soll ja die offizielle Doku nicht ersetzen :wink: Aber ich erinnere mich, dass ich bei den buffers/accessors und den Shaderparametern ein bißchen gebraucht hatte, und letzteres immernoch etwas von Unsicherheit durchsetzt ist. Ich hatte, grob gesagt, versucht, das zu machen, wovon ich im Nachhinein glaube, dass es mir geholfen hätte, wenn ich es anfangs gehabt hätte. Das „im Nachhinein“ ist aber das gefährliche hier. Erstens will ich mir nicht anmaßen, alles in aller Tiefe verstanden zu haben. Zweitens kennt man ja diesen „Im Nachhinein ist’s immer klar und einfach“-Effekt. Das „klar sein“ trifft zwar gefühlt nicht zu, aber die Symptome können trotzdem auftreten: Man erklärt etwas, aufbauend auf Dingen, die man eigentlich zuerst erklären müßte.

Insgesamt habe ich da schon eine Weile dran gebastelt, genau für die beiden kritisierten Punkte: Text und Layout.

Der Text ist immer eine Gratwanderung, zwischen „überflüssige Füllworte“ bis zu „so kompakt, dass man ihn 3 mal lesen muss, um ihn im Kopf auseinanderzufalten“. (Zugegeben, der „Summary“-Teil war recht schnell runtergeschrieben, um die 0.1.0 fertig zu kriegen). Über den und die übrigen Texte werde ich selbst sicher (vielleicht mit ein paar Tagen Abstand) nochmal drüberlesen, aber wenn du schon konkrete Hinweise hast: Nur raus damit :slight_smile:

Das Layout war auch nicht leicht. Es gibt viel Information in der Spec, und vieles davon (z.B. Tabellen, in denen GL-Konstanten aufgelistet sind usw) sind nicht relevant für die Übersicht. Das ganze dann auf eine Seite zu pressen (und das war das Ziel) hat einige „Refactorings“ beinhaltet. Ich hatte versucht, das ganze durch die Farben in verschiedene einigermaßen zusammenhängende, „konzeptuelle Blöcke“ zu unterteilen. Aber Alternativen hatte ich auch in betracht gezogen. Ich dachte auch, dass es hilfreich sein könnte, einfach eine minimale aber komplette (!) GLTF-JSON auf die linke Hälfte einer (hochkant) Seite zu legen, und die dann „bottom up von oben nach unten (sic)“ zu erklären:


buffers {                          |
    buffer01 {                     |       
       uri:...                     |   Buffers store data from URIs
    }                              |   bla bla, some picture
}                                  |
                                   |
bufferViews {                      |
    bufferView01 {                 | 
       buffer: ...                 |   BufferViews define parts of buffers
    }                              |   bla bla, some picture
}                                  |
                                   |
accessors {                        |
    accessor01 {                   |
       bufferView: ...             |   Accessors define the bufferView interpretation
    }                              |   bla bla, some picture
}                                  |
                                   |
meshes {                           |
    mesh01 {                       |
        primitive {                |
            attributes {           |
                POSITION: acessor01|   Mesh primtives consist of accessors
            }                      |   bla bla, some picture   
        }                          |  
    }                              | 
}                                  |
                                   |
nodes {                            |  
    node01 {                       |
        meshes {                   |
            mesh01...              |   Nodes refer to meshes....
        }                          |   bla bla, some picture
    }                              | 
}                                  |

(Mit vielen grünen Pfeilen, hoch und runter, auf der linken Seite).

Wäre es das, was du meintest, mit „…das Layout dem gltf Format ein bisschen eher entspräche?“?

Ich hatte das teilweise versucht, sowohl für die gesamte Datei, als auch für die einzelnen Blöcke - aber da wird der Platz in vertikaler Richtung schon recht knapp. Dazu kommt, dass das Verhältnis zwischen „JSON-Größe“ und „Erklär-Größe“ recht unterschiedlich ist: Ein 10-Zeilen „camera“-Node kann IMHO mit „Das ist eine camera“ abgefrühstückt sein. Ein 5-Zeilen „accessor“-Node braucht aber IMHO schon das Bild mit dem Speicherlayout. Aber da habe ich auch eine Idee (Eclipse „Compare with local history“ FTW :D) - vielleicht versuch’ ich das nochmal, jetzt, wo ich (zumindest grob) eine Vorstellung habe, wie man das überhaupt erklären und strukturieren kann, sowohl die (groben) Text- als auch die Bild-Building-Blocks schon vorhanden sind.

*** Edit ***

Hä, wer kann schon damit rechnen, dass man sich nicht mal um diese Zeit mit einer Antwort Zeit lassen kann :smiley:

Hmja, da muss ich mal schauen, wie die Farben von einem SW-Drucker umgesetzt werden.

Ich werde es bei Gelegenheit mal auf A4 ausdrucken, und schauen, ob man dann den Text noch lesen kann. Jetzt ist es so, dass man es an einem großen Monitor gerade noch lesen kann, d.h. auf einem Drucker sollte es klein, aber doch noch lesbar sein. EINE Seite war aber schon eine persönliche Zielvorgabe. Zwei Seiten könnten schon wieder so ausführlich sein, dass es sich von „Übersicht auf einen Blick“ hin zu „Eine möglichst kompakte aber vollständige Referenz“ bewegen würde, und das überlasse ich dann doch Khronos.

Dass es auf dieser Detailebene etwas „unordentlich“ (oder, ja: Schlicht unprofessionell) wirkt, dachte ich mir schon - war mein erster Versuch, sowas mal zu machen :wink: Vermutlich würden es professionelle Setzer auch haarsträubend finden, dass ich dafür Inkscape verwendet habe :rolleyes: Da händisch noch ein bißchen rum-auszurichten ist aber etwas, was ich als „Feinschliff“ ansehen würde (zumal das Layout als ganzes ja noch zur Disposition steht).

[QUOTE=Dow_Jones;133837]
4) Ein Rand zum Abheften wäre auch nicht zu verachten :D[/QUOTE]

Ja, dieser Punkt überschneidet sicht teilweise mit den anderen. Ich muss zugeben, dass die „Zielgruppe“ und der Verwendungszweck mir selbst nicht ganz klar sind: Als Papierformat hatte ich ursprünglich eigentlich A3 eingestellt, weil ich an eine Art „Poster“ dachte (also auf A3 farbig drucken und aufhängen). Später dachte ich dann, dass man es auch als eine Art „Cheat Sheet“ ansehen könnte (also auf A4 schwarzweiß ausdrucken und abheften) - aber dafür hat es nicht genug Details und nicht wirklichen „Referenz“-Charakter. Am ehesten sehe ich jetzt die beiden Optionen: Am Bildschirm (als PNG oder PDF) auf einmal draufschauen und einen Überblick bekommen, oder als „A3-Poster“ ausdrucken weil’s so hübsch ist :o)

Mal schauen wie das mit dem „Zweispaltigen Layout“ (aus dem vorigen Beitrag) aussehen könnte.

Vielleicht wird dann mir selbst auch klarer, warum ich da XX Stunden drin versenke :rolleyes: :wink:

Also, ausgedruckt habe ich es mal, auf A4, einmal schwarzweiß und einmal in Farbe (und bunt!), und das sieht eigentlich beides OK aus - bis auf eine Kleinigkeit: Ich weiß nicht, wo das “reingeflutscht” ist, aber Liaguturen scheinen mit einer anderen Schriftart gedruckt zu werden. (Ob das nun an der SVG, dem Font, der PDF oder dem Drucker liegt…?! Ach, Fonts sind immer KG…)

Ich hab’s nu’ auch mal ausgedruckt (A4, sw), und kann dir nur Recht geben - es ist gut lesbar (nicht auf Dauer aber zum hin und wieder nachschauen), viel besser als ich erwartet hatte. :slight_smile:
Allerdings bin ich dabei doch noch auf einen caveat gestoßen: Für einen (unskalierten) Ausdruck in A4 sind die Seitenränder zu schmal. (mein Drucker jedenfalls hat an jeder Seite des Papiers ca. 5 mm Platz gelassen, und da dieser Bereich bereits mit Inhalt gefüllt war fehlt mir nun an jeder Seite ein bisschen was)

Ach so, auf die Idee mit dem Poster war ich gar net gekommen… Naja, mach halt einfach zwei Versionen - Poster und Sheet.

Ja sorry… Ich hatte damals mal das Vergnügen ein paar Ausgaben unsere Fachschaftszeitung zu setzen, und daher weiss ich noch das man Jahre damit verbringen kann sich in all die geschriebenen und ungeschriebenen Gesetze des Satzes einzuarbeiten. Aber ein paar grundlegende Regeln reichen schon aus um das Schriftstück gleich 'n Tacken professioneller aussehen zu lassen.
Was ich von damals auch noch weiss: Lektoren sind wichtig, denn irgendwas übersieht man immer (und i.d.R. macht sich keine Sau mal die Mühe fremde Texte korrekturzulesen; das bleibt immer am Setzer hängen…). Ich habe daher mal versucht gegenzulesen. Habe dabei aber lediglich hier und da einen vergessenen Punkt und sowas gefunden und entsprechend markiert.

Die Ligaturen schauen bei mir völlig i.O. aus. Wenn ich das PDF mit Inkscape öffne werden sie als eigene Textblöcke angezeigt, insofern scheinen sie also korrekt codiert zu sein. Beim Ausdruck - wohl mit Inkscape als auch mit Evince (PDF-Viewer unter Linux) - werden die auch genau so gedruckt wie sie sein sollten (siehe Foto):


michael@Papaya:~/Schreibtisch$ pdffonts gltfOverview-0.1.0.pdf 
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
FEOLXQ+LucidaSansUnicode             TrueType          WinAnsi          yes yes yes      6  0
OPMFPE+DejaVuSans-Bold               TrueType          WinAnsi          yes yes yes      7  0
WDVVCE+DejaVuSans                    TrueType          WinAnsi          yes yes yes      8  0
YDMEYU+DejaVuSans                    CID TrueType      Identity-H       yes yes yes      9  0
GNXNMH+DejaVuSans-Bold               CID TrueType      Identity-H       yes yes yes     13  0
AABXQF+CourierNewPS-BoldMT           TrueType          WinAnsi          yes yes yes     14  0

Schaut ja eigentlich so aus als wären die Fonts alle eingebettet. Hmm. Kann man die Verwendung von Ligaturen vielleicht in Inkscape irgendwie abschalten? Wäre vielleicht das einfachste.

Wow, richtiges Feedback - danke! :slight_smile:

Das mit dem Rand … ich hätte jetzt vermutet, dass das mit dem Page Setup des Druckers zusammenhängt. Also, er sollte/könnte ja einfach das, was da ist, auf den verfügbaren Platz drucken (dann halt 2% kleiner oder so…). Hab’s bisher nur mit einem Drucker getestet. (Tatsächlich konnte man es selbst bei einem versehentlichen „Hochkant“ (also dann effektiv A5!) Ausdruck noch gerade so lesen :D)

Allgemein hatte ich schon versucht, das Layout nicht ganz so zusammengeschustert aussehen zu lassen, aber … ein bißchen „Künstler“ bin ich dann doch :smiley: Die Aussage zu dem „zwei Alphabete breit“ bezog sich wohl auf den „Summary-Block“? Wie gesagt, der ist (insbesondere auch inhaltlich) halbgar. Ich hatte zwar versucht, da ein schönes Bild zu malen, aber das haut dann vom Platz her nicht mehr hin.

Die Anmerkungen: Ehrlich gesagt hatte ich es in 0.1.0 noch nicht gewissenhaft’est’ durchgelesen, weil ich erstmal wissen wollte, ob das überhaupt so Sinn macht. Aber kurz:

  • „s am Ende (für Plural)“: Ich denke, " … that the 3D objects consist of" (ohne s) ist richtig. „The objects consist of“ vs. „The object consists of“
  • „mal mit, mal ohne Bindestrich“: Da muss ich nochmal schauen, wie das im Englischen ist…
  • „an URI“ (2x) : Ich bin mir ziemlich sicher, dass es „a URI“ heißt. Ob man „an“ verwendet, hängt davon ab, wie das nachfolgende ausgesprochen wird, und „U“ fängt mit „J“ an :smiley:
  • „hellere Texturbeispiele“: Stimmt, das war mir auch aufgefallen. (Schwarzweiß war die Ente auch recht dunkel, aber noch OK…)
  • (Punkte und Doppelpunkte: Ja…)
  • „r fehlt“: Aber mal sowas von …

Das Ligaturen-Problem … ja, ich weiß nicht wovon das abhängen kann - ich muss es nochmal mit einem anderen Drucker probieren. Vielleicht hängt es auch am viewer? Ich hatte das direkt aus dem Firefox-Viewer raus gedruckt… also auch nochmal Sumatra und Acrobat testen…

du hattest recht mit dem a / an. 12 jahre schule und ich wusste das auch nicht…
dachte es hängt von konsonant / vokal am anfang ab
Which is correct - a URL or an URL? - Writing for Business - A Whatis.com Blog

Ja, hab’s gerade nochmal (auf’er Arbeit) gedruckt, und da stimmt vom Druckbild her eigentlich alles: Der Rand ist nicht abgeschnitten, die Helligkeit der Texturen (schwarzweiß) auch OK, und inbesondere die Ligaturen stimmen. (Aus Sumatra heraus - immernoch keinen Plan, wo das herkommt, muss am WE nochmal aus Sumatra raus mit den anderen Drucker testen).
Die Texturen werd’ ich trotzdem nochmal aufhübschen (das waren nur die erstbesten Patterns aus Gimp - sollten ja nur Symbole für “irgendwelche Texturen” sein). @Dow_Jones Das mit dem Rand irritiert mich noch ein bißchen - kann es sein, dass da beim “Page setup” irgendwas unpassend war? Irgendeine Einstellung wie “Print original size” vs. “Print to fit page” oder so?

In der Regel ist es genau diese Einstellung, die zu dem Druck"fehler" führt. Wenn „Print to fit page“ ausgewählt wird, wird die Seite auf den Druckbereich des Druckers, welcher aus dem Treiber hervorgeht, herunterskaliert. Korrekt gedruckt wäre es aber eigentlich mit „print original size“. Daher sollte bereits beim Layout ein „ausreichend großer“ Rand berücksichtigt werden.

Nun, ein “Print to fit the area that can be covered by this printer” wäre ja OK… (War das ein Tintenstrahler?)

Stimmt. An die Sache mit der Aussprache (von wem eigentlich?) hatte ich gar nicht mehr gedacht. Wie peinlich, klugschwätzen wollen und es dann nicht schaffen… :culpability:

Es kam mir auch seltsam vor, deshalb hatte ich extra noch nachschlagen wollen (was allerdings schwierig ist wenn man den grammatikalischen Terminus Technicus nicht kennt). Irgendwann hatte ich dann tatsächlich ein oder zwei Seiten gefunden wo vom Plural die Rede war. Hatte dann aber wohl ignoriert das es dort um das Hauptwort „consist“ geht. Mann, wie blöd… Kurzum: Du hast erneut Recht behalten, das „s“ gibt’s natürlich nur für dritte Person singular.

Yup, auf den und auf alles andere das breiter ist. Bei den paar Zeilen geht das zwar, aber… naja… trübt halt die „Lesefreude“ ein wenig.

Ja klar, da gibt’s 'ne Option um die Druckaufträge auf den tatsächlich bedruckbaren Bereich zu skalieren. Habe ich standardmäßig allerdings nicht aktiviert. Weiss nicht ob ich damit der einzige Mensch auf der Welt bin, aber da es mir dadurch nun zufällig auffiel und es ein potentieller Stolperstein ist hatte ich’s halt erwähnt. Da du schon die Strapaze ein solches Poster/Sheet zu erstellen auf dich nimmst, da sollte das doch durch solchen Kleinigkeiten nicht beeinträchtigt werden. :wink:
Der Drucker war übrigens kein Strahler sondern ein Laser-alleskönn-Dingsbums (Samsung SCX 4200).

Nein, du bist damit nicht allein. Zumindest ich drucke grundsätzlich auch alles im Maßstab des Dokumentes - nur wenn der Druckbereich verletzt wird, lasse ich herunterskalieren.

Dann mal eine vielleicht etwas naive Frage: Woher weiß man, wie viel Platz man lassen muss? Dass man da mit einem Locher zum Abheften ggf. wichtige Informationen wegstanzt ist eine Sache, aber … der “Rand” hängt doch vom Drucker ab? (Wie angedeutet: Tintenstrahler haben wohl eher ein Problem, bis zum Rand zu drucken…)

Stimmt. Üblicherweise macht man einen Rand aber auch nicht von den technischen Merkmalen irgendwelcher Drucker abhängig sondern eher von „ästhetischen“ Kriterien. Auch leerer Raum ist ein Mittel um den Betrachter zu beeinflussen. Wenn man doch mal eine genaue Kontrolle des Randes braucht dann wird der Druck nachher zurecht geschnitten.
Hier würde ich mal sagen: Lass halt einfach genug Platz an den Rändern (bei A4 vielleicht so >= 10mm bis zum Text? die bunten Kästen können ja ruhig angeschnitten werden). Oder weise die Leute beim download darauf hin das sie zum drucken „scale to fit“ aktivieren mögen.

Ich weiss, sind alles keine tollen Lösungen - aber niemand sagte das es einfach ist Medien ordentlich zu gestalten… :nevreness:

Aber ist das hier nicht eher ein “Plakat” als irgendeine DIN A4 Seite die man sich in irgendeinen Schnellhefter klemmt und vergisst?

Ja, wie schon in #7 (gegen Ende) gesagt: WAS das eigentlich sein soll, das ist nicht ganz klar

  • “Infographics”
  • “Poster”
  • “Cheat sheet”
    Im Moment liegt es eher zwischen 1 und 2. Ich denke, der Haupt-“Nutzen” wird sein, es entweder als PNG oder PDF direkt anzusehen und einen ersten Überblick zu bekommen.
    (Die Option es auf A3 (oder ggf. auf A4) auszudurcken und an die Wand zu heften besteht zwar, aber ich weiß nicht, wie viel “Rand” für diesen “Rand-Fall” geerechtfertigt ist ;-))

In 0.1.1 habe ich jetzt das Feedback von Dow_Jones weitgehend eingarbeitet, die Zeilenumbrüche und -ausrichtungen müssen noch angepasst werden, aber ich denke, dass 0.1.2 dann auf GitHub landen könnte. Ich würde aber mal zusehen, ob ich am Wochenende auch ein bißchen Code auf den Stand bringen kann, der veröffentlicht werden könnte. (Zuletzt hatte ich das “eigenständiger” gemacht, so dass es mit meiner Rendering-Lib eigentlich nichts mehr zu tun hat)