Що таке файл GLTF?
glTF (формат передачі GL) — це формат 3D-файлу, який зберігає інформацію про 3D-модель у форматі JSON. Використання JSON мінімізує як розмір 3D-ресурсів, так і обробку під час виконання, необхідну для розпакування та використання цих ресурсів. Він був прийнятий для ефективної передачі та завантаження 3D-сцен і моделей програмами. glTF був розроблений Робочою групою 3D-форматів Khronos Group і також описаний його творцями як JPEG 3D.
Формат файлу GLTF визначає розширюваний загальний формат публікації для інструментів і служб 3D-контенту, який оптимізує робочі процеси створення та забезпечує сумісне використання вмісту в усій галузі. Намір створення формату файлу glTF полягав у тому, щоб визначити розширюваний загальний формат публікації для інструментів і служб 3D-вмісту, який мав би оптимізувати робочі процеси створення та забезпечити сумісне використання вмісту в усій галузі. Це мінімізує обробку під час виконання програмами, які використовують WebGL та інші API.
Коротка історія файлу GLTF
Перші специфікації для формату файлів glTF 1.0 були оголошені в жовтні 2015 року. Це було серією зусиль, які Khronos розпочала в березні 2012 року. Мета цих зусиль полягала в тому, щоб оцінити можливості щодо тяги WebGL. Як наслідок, перша демонстрація формату glTF, заснованого на форматі JSON, була представлена на зустрічі WebGl у 2012 році. Час від часу цей формат використовували кілька компаній, зокрема Cesium, 3D Tiles, Oculus, Microsoft, Archilogic та інші.
glTF 2.0 було опубліковано 5 червня 2017 року на конференції Web3D 2017. Існує довгий список компаній, які після цього прийняли формат файлу glTF.
Формат файлу GLTF
Специфікації формату файлу для glTF 2.0 доступні в Інтернеті для довідки, і їх слід використовувати для будь-якої реалізації, пов’язаної з читанням/записом для підтримки формат файлу glTF.
glTF визначає ресурси як файли JSON із підтримкою зовнішніх даних. Представляє 3D моделі за допомогою:
- Повний опис сцени міститься у файлі .glTF у форматі JSON, який містить інформацію про ієрархію вузлів, матеріали, камери, а також інформацію про дескриптори для сіток, анімації та інших конструкцій
- Бінарні файли (.bin), що містять дані геометрії та анімації, а також інші дані на основі буфера
- Файли зображень (.jpg, .png) для текстур
Будь-які зовнішні ресурси, такі як зображення, зберігаються у зовнішніх файлах, на які посилаються через URI. Ці URI зберігаються поряд з контейнером GLB або вбудовані безпосередньо в JSON за допомогою URI даних. Кожен дійсний glTF має вказувати свою версію.
glTF було розроблено для досягнення невеликого розміру файлу, швидкого завантаження, повного представлення 3D-сцени та можливості розширення. Ці унікальні цілі дизайну є головними причинами популярності формату файлів glTF у 3D-доміні. Нижче наведено типи mime, які підтримуються форматом glTF для різних типів файлів:
- Файли .gltf використовують model/gltf+json
- Файли .bin використовують програмний/октетний потік
- Файли текстур використовують офіційний тип зображення/* на основі конкретного формату зображення. Для сумісності з сучасними веб-браузерами підтримуються такі формати зображень: image/jpeg, image/png.
Кодування JSON
glTF накладає такі додаткові обмеження на формат файлу JSON
Щоб спростити впровадження на стороні клієнта, glTF має додаткові обмеження щодо формату JSON і кодування.
- JSON має використовувати кодування UTF-8 без BOM.
- Усі рядки, визначені в цій специфікації (назви властивостей, переліки), використовують лише кодування ASCII і мають бути записані як звичайний текст, наприклад, “буфер” замість
"\u0062\u0075\u0066\u0066\u0065\u0072". - Імена (ключі) в об’єктах JSON мають бути унікальними, тобто дублікати ключів не допускаються.
URI
Буфери та ресурси зображень посилаються через URI. Наступні два типи URI мають підтримуватися клієнтами.
URI даних: URI даних визначені в RFC 2397 і використовуються glTF для вбудовування ресурсів у JSON.
Відносні шляхи URI: або path-noscheme, як визначено в RFC 3986, розділ 4.2 — без схеми, повноважень або параметрів. Зарезервовані символи мають мати процентне кодування відповідно до RFC 3986, розділ 2.2.
