Billboard questions and feedback

[jsorel]

Hello,

I just discovered this repo, and wanted to ask a few questions on the billboard extension. Note : I'm the author of the request Annotation, Billboards and texts extension for GLTF

• In your demo, there is an issue with billboard depth ordering inconsistent with the document which says :

If overlay option is given, the depth value of affected primitives needs to be set to zero. If multiple billboards with overlay are present, than they need to be depth sorted based on their position and an increasing Z value near zero should be used. This avoids Z-fighting.

• Is this extension already being under discussion in the GLTF registry ?

On the technical side, the current definition fits our needs in GIS.

In the future a separate extension could be defined for e.g. creating 2D sprites out of text.

I don't even think this should be an extension, there are so many ways and parameters to generate images from text that it's going to be very complicate.

OpenUSD is also working on a billboard specification, which can also anchor sprites in screen space and therefore enables the creation of user interfaces. If similar functionality is desired in glTF, we propose to create a separate anchoring extension, since a lot more corner cases, such as different cameras, aspect ratios, screen sizes, overlapping need to be considered.

We also in GIS would like something similar, the most basic case would be for example the display a small text or logo at the bottom of the screen for the data origin, license, etc ... A different extension could work, but it seems very similar and maybe just adding another parameter would do the trick for 95% of the use cases.

Property	Default	Description
anchor	node	Defines if the billboard should be attached to the current node or to the camera. if the value 'camera' is used then reffer to anchor-cs
anchor-cs	VIEW UP RIGHT	pattern like : (VIEW|SCREEN) (UP|DOWN) (LEFT|RIGHT). view for the [0-1] range, screen for [0-size in pixels]. up, down,left,right are use to define the origin and direction of the axis

I say 95% because, corner cases will always exist, and if we start support for expressions (like the middle - 20px) it's a never ending story which leads to layout manager and so on. This 95% is where I place the limit between what can be in the format and what should be the UI job.