KhronosGroup / KhronosGroup/glTF
Annotation, Billboards and texts extension
- Dominant language
- HTML
- Stars
- 7.8k
- Forks
- 1.2k
- Avg merge
- 17h 26m
- Merged PRs (30d)
- 5
Description
Hello,
I open this issue after the Khronos/OGC meeting (16-12-2021) where we talked about closing the gap between GLTF and Geospatial.
### To set the context :
- For this case we work on Nautical Charts (maybe you know them as ENC,ECDIS,S-57)
Some details on those maps here [Between GIS and ECDIS, S-57 and S-52 for marine and military fields](https://www.geomatys.com/2016/04/07/between-gis-and-ecdis-s-57-and-s-52-for-marine-and-military-fields/)

To resume it : S-57+S-52 define map datas and it's symbology, It is the oldest and most achieved map symbology which exist, with over 200 objets types, 500 differents attributes, hundreds of styling rules and close to 600 symbols, plus studied color palettes for Day,Dusk,Night. It's an international standard from IHO and it's used worldwide on boats.
- In 2018 we made a test with Cesium 3Dtiles-GLTF-1.0 (before it became an OGC specification) and obtain very good results you can see here : [3D Tiles in action for ENC](https://www.geomatys.com/2018/07/18/3d-tiles-et-enc-en-action/)


Not to much fancy rendering techniques, the correct symbols, clickable, valid for a daily working and professionnal tool.
So far so good !
Yet GLTF 2.0 arrived, much easier, PBR, no shader, much better on the paper.
But we could not make a decent 3D map anymore.
A major downgrade from GLTF 1.0 to 2.0 is the absence of billboards like capability, in 1.0 we could define shaders to achieve billboard visuals. Using 3d meshes to replace them does not work well, not focused, not scaling and uses more resources.
### Possible solutions :
- adding billboard and texts meshes, like in Cesium CZML -> a bad idea, would be complicated, hard to implement and will end up in being unsupported by engine or have different rendering in the end. Not a good solution for an export/exchange format like GLTF.
- Annotation on node transform -> that could work,
rather then giving a transform matrix, translation,scale or rotation, let's add a new field :
```
focus : {
target : $node name or id #could be the node where the camera is
constraint : $codes to be defined #to keep the billboard axis align or scaled or whatever
}
```
This way we skip all the troubles from texts and so on, we just provide 'how' the matrices must be combined to obtain the resulting MVP.
### Futur problem
- combining instancing + billboard ...
Related topics :
https://community.khronos.org/t/adding-billboard-sprites-to-gltf/106664
https://github.com/KhronosGroup/glTF/issues/2092
Thanks
Johann Sorel
Contributor guide
Research direction
Start by reading the related glTF discussions in issues/2092 and the Khronos forum topic linked in the issue. Compare the proposed node annotation approach with the billboard, text, instancing, and rendering constraints described here. Done would require an agreed, implementable glTF extension design rather than only a proposed field structure.
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