KhronosGroup / glTF

glTF – Runtime 3D Asset Delivery
Other
7.18k stars 1.14k forks source link

Best practices for .gltf / .glb #1117

Open pjcozzi opened 7 years ago

pjcozzi commented 7 years ago

Documentation for when to export/import .gltf / .glb for different types of apps, e.g., desktop vs. web, consumer vs. developer, etc.

Not 100% sure where this should live but it should be easily discoverable. Perhaps an implementation section in the spec. Or maybe also a glTF Tutorial.

CC @sbtron

Fabrice3D commented 6 years ago

thx @donmccurdy. joined.

Fabrice3D commented 6 years ago

@lexaknyazev, was caused by length != 1 of normals. Added a routine to check them, all fine now. thx!

MaxmaxmaximusAWS commented 4 years ago

we in the company use gltf + assets + webpack loader to CDN. webpack parse gltf and get links to assets. upload it to CDN and add hash to name. then we add presistent cache for this assets. if we change one small thing in our scene. all assets load from browser cache, cuz name change in only in one asset. we also use http2, and loading multiple files in parallel speeds up overall scene loading. 2020 year =)

donmccurdy commented 3 years ago

I haven't been able to come up with any concrete recommendation here except that "glTF Embedded" (with Data URIs) should be avoided. Both "glTF Separate" and GLB work well, and different users seem to have fairly different preferences about the performance and ergonomics of each, e.g. for sharing textures across multiple files.

I'd like to see us more aggressively trying to discourage "glTF Embedded" (e.g. remove its output from Blender and glTF-Pipeline?), but other than that I don't think there's a clear need for more messaging.