API des Asset Loader moduls
A) Wollen wir weiterhin public structs für alles, oder Klassen mit private sections und gettern?
Public structs wie jetzt hat den Vorteil, dass es simpel ist. Semantisch macht es allerdings wenig Sinn, dass jeder Schreibzugriff auf die vektoren im Scene-struct hat...
vkcv::asset
) aussehen?
B) Wie soll die API (die Funktionen in - nur die Funktion
loadScene(const std::string &path, asset::Scene &scene)
: Lädt alles aus einer glTF-Datei - Aufteilung in
-
loadScene(const std::string &path, asset::Scene &scene, bool shallow)
: Lädt alles aus einer glTF-Datei und überspringt optional das Laden der Binärdaten, sodass man ein "shallow" struct zum durchsuchen/iterieren erhält -
loadMesh(asset::Scene &scene, const std::string &name)
: erhält ein Scene-struct und den Namen eines Meshs und lädt dieses, wenn es in der Szene gefunden wird (befüllt das erhaltene Scene struct mit den Mesh-Daten)
- Async:
loadScene(const std::string &path, const asset::callback cb, asset::Scene &scene)
lädt insgesamt alles aus einer glTF-Datei, returned aber direkt (bzw. nach dem Parsen der glTF) und lädt die Binärdaten asynchron. Dabei ruft es callbacks auf wannimmer ein Objekt der Szene fertig geladen wurde. - Es gibt folgende Funtionen, von denen alle den Pfad zu einer glTF-Datei kriegen aber etwas anderes mit der Datei machen:
-
loadMesh(const std::string &path, asset::Scene &scene)
lädt ein spezifisches Mesh aus der Datei und erstellt eineasset::Scene
mit nur den Daten, die für dieses Mesh gebraucht werden -
probeScene(const std::string &path, asset:Scene &scene)
parsed die glTF-Datei ohne Binärdaten zu laden sodass der Nutzer ein struct zum Durchsuchen/Iterieren kriegt ohne lange Warten zu müssen -
loadScene(const std::string &path, asset::Scene &scene)
lädt einfach alles aus einer glTF-Datei direkt, braucht entsprechend viele Ressourcen abhängig von der glTF-Datei
Der Konsens fällt auf Variante 4. Die Diskussion wurde bei BBB-Treffen vertieft, die Entscheidung basiert nicht allein auf den posts hier im issue.
Das issue kann geschlossen werden sobald issue #79 (closed) abgeschlossen wurde.
Edited by Trevor Hollmann