Proposal: dynamic text

[jeanahelver]

this popped up during omi-chan meeting where Koolala and me stumbled into talking about fonts.
As far as i know 3D text is currently not supported in gltf it gets triangulated on export in blender.

i think this might be a place to create an extension, making it so the text object is modifiable could be helpful to import back into blender or other editor. but also give a hook as a WASM output field.

iFire let me know including ttf/otf might be a bit out of scope due to text rendering being very different depending on platform.
for this the proposal is trying out a 3D fonts stash as a set of 3D meshes for every character that could be contained into an external gltf file.

[robertlong]

There's some prior work done at Mozilla that we should look into here and see if we can work with them further. https://github.com/MozillaReality/MOZ_text

I know @feiss (the original author) is now at Embark, maybe we can work together on this? Hey Diego 👋

[jeanahelver]

some dialog after the meeting happened about this proposal.
to way out the ups and downs of this i am trying to categorize and summarize as much as i can

• as debug text:
  this means the definition is very lose and it just to get some information to display in the model. using whatever is available in the render to render text.

• as geometry text:
  the characters are all pre-rendered and included in the geometry data or linked from an external file. potential here is to do more then flat text. (on topic of this version it would be possible to not have this as a spec as this could be achieved completely with scripting, to ether generate the geometry from paths or have the geometry stack ether invisible or scaled down to zero.)

• full sdf text:
  having a strict specification how to render this text from a font file or resource making it look he same on any platform, giving exact metrics on how big text would be and formatting like colors, bold, italic, etc. this would be very influenced by a common library for all platforms, which would be hard to integrate to engines.
  this would closely resemble the MOZ_text. wich would be out of the box solution for most web based platforms but harder or even suboptimal for other render engines.

consulting with people about this i feel it may be best to not have this as a gltf extension at all, but giving (wasm) scripts the ability to access to shaders and geometry to solve this problem on a case by case basis.

[feiss]

LOL Hi @robertlong!! nice to see you again, and see that there is interest in the MOZ_text extension. I'm currently quite busy at Embark, and I'm afraid I have no spare time at all to dedicate on this... unless on work hours. We do use gltf at Embark, so maybe there is some alignment here. Will check with my managers.

Feel free to fork/get inspired/do whatever you want meanwhile :)

[robertlong]

Hey Diego, yeah if Embark is interested, we'd love to work together on this!

I think we're still deciding what direction to take but we'll keep your work in mind. Thanks!

[robertlong]

Comment from Don McCurdy:

The challenging thing about SDF text is that for non-phonetic languages, a complete set of textures containing SDF data for all characters is prohibitively large... you kind of need to know the character set required and to 'bake' textures for those characters. Or else have the textures included with the asset. 😕