KhronosGroup / KhronosGroup/glTF
Some inspiration can be gained from m3g format
- Dominant language
- HTML
- Stars
- 7.8k
- Forks
- 1.2k
- Avg merge
- 17h 26m
- Merged PRs (30d)
- 5
Description
Not sure if I should have created an issue for this, but I really wanted to share this.
Back when J2ME cell phones were popular, there was a special J2ME API for 3D Graphics, jsr184 or "Mobile 3D Graphics API", which basically consisted of openGLES 1.1 bindings with scene graph and some optimizations for J2ME.
Here's some info about it: https://en.m.wikipedia.org/wiki/Mobile_3D_Graphics_API
The most interesting part, is that this API has its own graphics format, WHICH REALLY REMINDS GLTF.
Its too consists of nodes, stores materials, textures, skeletal animation and meshes as a scene graph. Altho this format is pretty old and was created for openGLES 1.1, I believe that some inspiration and ideas still can be gained from it.
There are even some cool features that GLTF doesnt have, for example, you can store any node in a standalone file and reference to it. This can be userful for storing materials as standalone files. Ive seen games that stored light presets in a standalone file.😳 Also it has a simpler node referencing system, which makes loading this format way easier than GLTF.
Here's m3g format specs: https://nikita36078.github.io/J2ME_Docs/docs/jsr184/file-format.html
Contributor guide
Research direction
Read the linked Mobile 3D Graphics API overview and m3g format specification, then compare the referenced scene-graph, node-reference, material, texture, skeletal-animation, and mesh features with glTF. The issue does not identify a file, test, or specific change, so a concrete implementation target and completion criteria would need to be defined first.
Written by the indexing model from the issue text.
Assessment
- Domain
- computer-graphics
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100