troika-3d-text request: possibility to define the axis of the text

[feiss]

Hi!

We already used troika-3d-text in our latest demos (https://blog.mozvr.com) and it's amazing. Great job!

I'm currently working on a glTF extension to include text without exporting the mesh but only the metadata needed for recreating it in realtime. My specific goal is to create text in Blender, export the scene to glTF, and recreate the text in realtime in threejs with the same look as in Blender, using troika-3d-text.

But I have a problem: a text in Blender with zero rotation is laid down on the floor, whereas a text in troika-3d-text with zero rotation is standing up, facing Z.

I tried different solutions for this, but none works completely. The best option would be to ask troika-3d-text to create the text "laid down on the floor", in the XZ plane. Do you think it could be possible to add a parameter in the constructor, or a property of the text, to specify the desired plane where the text is created? something like text.axis or text.normal, with the possible string values +x -x +y -y +z -z, specifying where the text is facing on creation time.

I don't know if that would break things. I this case, maybe you could give me some hints about where to hack the library to achieve the desired result. I've been trying but honestly I'm a bit lost on how it could be the best way to do it.

This would be incredibly useful to match Blender and troika-3d-text. Thanks!

[lojjic]

@feiss Thank you for the kind words! I'm super happy you're finding it useful. :) You folks at Mozilla are doing really great work.

This is a very interesting scenario you bring up, and I have no doubt we could add something like that as a feature pretty easily.

To help my understanding, how much control do you have over the structure of the ThreeJS objects created from this metadata? Is this something you're adding to GLTFLoader?

In my naive view it would seem that you could just wrap the TextMesh in a Group, give that Group the object's transform, and the inner TextMesh would just have a rotation (rotateX?) to orient it on the xz plane as desired. There must be some complication with that though; what am I missing?

[feiss]

Thanks! much appreciated :)

Yeah, I'm planning to add stuff to the GLTFLoader.

The Group approach would work technically, but from the user's perspective the scene hierarchy in three would be different to Blender's. The user would find a group object instead of his text. And it would be a bit confusing: you'd have to access the group to change the pos/rot of the text, but you'd have to access the text object to change its properties..

[lojjic]

Ah ok, so there's an expectation by the user that the rehydrated glTF would match the structure of its source with the intention of being able to manipulate it in a 1-to-1 fashion? Yeah I can see how that complicates things. 🤔

Does that user expectation also apply to what the object's matrix and/or matrixWorld look like? My first thought on implementation was to just override the updateMatrix method to preapply a quaternion supplied by the user, but that may not be good if the user expects to be able to do things like decompose that matrix back.

If I can't touch the mesh's matrices, maybe I could pass a quaternion as a shader uniform and apply it there.

[feiss]

Mmm.. the user may want to modify the transform of the text (pos/rot/scale) directly, indeed. That would modify object's matrix.. I'm not sure if that collides with your plans.

[feiss]

You create the sdf text on a base geometry (a plane), don't you? I thought the simplest approach would be to create that plane with different vertex positions.. But I don't know the specifics of how the text is build, it may be very far from the reality.

[lojjic]

Yes the geometry could be created on a different plane, but the shader code makes assumptions about both the input vertices and the instanced glyphs being on the xy plane, so that GLSL would also have to be modified to match the different axis orientations. That's more complicated than I'd prefer.

I think I can just pass a rotation to the vertex shader and apply it there prior to multiplying the modelMatrix; that seems like the approach with the least impact.

So the other question is what the API should look like... A pair of +/- axis parameters (normal + up) like you suggested could work. The most flexible may be a full Quaternion, which would allow off-axis orientations, but I'm not sure if there are any legitimate use cases that would require it. 🤔

[feiss]

Yeah, off-axis orientations sound more like a regular rotation to me. +/-AXIS would be enough I think.

This is awesome! thanks for the effort and support. I hope this feature will be useful to more people.

[lojjic]

Cool, I'll take a swing at this tomorrow if nothing else comes up. For a first pass, what is the orientation Blender uses? You said it lies on the xz plane, but which way does the text's "up" point? Negative z?

[feiss]

-Z in opengl, yup

(actually, Blender uses a coordinate system X, Z, -Y, but that conversion is handled by the gltf exporter)

[lojjic]

OK @feiss I've got what I think is a decent solution. The API now has an orientation property on the mesh, which defines the plane it sits on via its horizontal and vertical axes. It's "+x+y" by default, and in your case I believe you'd set it to "+x-z". I think this is a pretty understandable spec and allows any axis-aligned orientation.

Are you able to pull from the textmesh-orientation branch to test the implementation and verify it works for your needs? I'll merge and publish this to npm today but I'd feel better with your verification first.

[feiss]

I'll try it right now, thanks!

[feiss]

Seems it's working like a charm :)

Amazing work, thanks again 👍

[lojjic]

Great! I've published 0.22.0 to npm that includes this and the other letterSpacing fix you reported.

I look forward to seeing the result of your glTF feature! I could definitely see other possible issues with trying to get an exact 1-to-1 mapping so lemme know if I can help with anything else.

[feiss]

thanks! actually, I have another issue related to line height.. :D

[lojjic]

LOL line height was my first thought! 😆 Open another issue and I'll see how I can help.