ROADMAP 7.x.x

[felixmariotto]

In this issue we are discussing the roadmap for the new major version (7.x.x).

@swingingtom made a lot of relevant tests and experiments on the branches refactor-examples-folder and refactor-material-manager.

The goal of this issue is to list what is to be kept from these experiments, and possibly add other short-term goals, in order to define a clear timeline of milestones.

Once this is done, we will open a new 7.0.0 branch to work on the changes, open a new issue with a checklist from this discussion to track the progress, and close the present issue.

Thereafter, changes from the roadmap will have to be merged in the 7.0.0 branch, while master will still receive the quick patches. Once the roadmap is completed, the 7.0.0 branch will be merged in master and v7.0.0 published to NPM.

[felixmariotto]

Here is the proposal :

1 - Reorganization of examples folders

• [x] organize current examples in categories.
• [x] create InteractiveRaycaster module in examples folder to take out intersection logic from the examples pages.
• [x] create Button, CheckBox, RadioButton, and ToggleButton modules in examples folder, and move Keyboard to examples folder.
• [x] add examples for testing (whitespace, interactive components, flex layout, possibly others ?).

2 - Materials refactor

• [x] Split up current fontMaterial by shader chunks
• [x] Compose a FontMaterialDefault class that extends ShaderMaterial and recomposer shaders by chunks
• [x] Standardize uniforms name to follow existing threejs uniforms, and avoid conflicts for customisation without API changes
• [x] Optimize some parts ( u_useRGSS ) could become a WebGL preprocessor, we would reduce "1 webgl if" per voxel
• [x] Remove MaterialManager from TextComponent
• [x] Same process for FrameMaterial
• [x] Build examples of customisation

3 - Geometries

• [x] Text segments : Allowing more segments for vertex shaders
• [ ] Text splitLines : For each outputed line, having a separate mesh child
• [ ] Text splitChars : For each outputed char, having a separate mesh child

4 - Misc

• [x] Cumulative onAfterUpdate? : Currently only one onAfterUpdate is possible.
• [ ] More Hooks : We currently only have onAfterUpdate. Should other hooks be useful? I foreseen bestFit as being externalized into an example behaviour component instead of being pushed in core.

5 - Cleanup

• [x] Webpack 5
• [x] @babel/preset-env : allowing stuff like that
• [ ] ~remove build folder~
  • [x] Add jsm build : build/three-mesh-ui.module.js & build/three-mesh-ui.module.min.js

[felixmariotto]

@swingingtom how would you break down the materials refactoring into manageable steps ? Also I see you put the new text materials in /examples/materials, don't you think we could put all of them in /src/materials ? I mean if possible I would like the experimented three.js user to feel "at home" with three-mesh-ui, so if they are used to have three.js materials in three.js core, I think we should have our materials in our core as well.

[swingingtom]

@swingingtom how would you break down the materials refactoring into manageable steps ?

This is not really "one step", but starting only with FontMaterial ( which is simpler than FrameMaterial ) would allows us to affine the whole picture refactoring, before doing all the job.

This is what I could list for FontMaterial:

1. Split up current fontMaterial by shader chunks
2. Compose a FontMaterialDefault class that extends ShaderMaterial and recomposer shaders by chunks
3. Standardize uniforms name to follow existing threejs uniforms, and avoid conflicts for customisation without API changes
4. Optimize some parts ( u_useRGSS ) could become a WebGL preprocessor, we would reduce "1 webgl if" per voxel
5. Remove MaterialManager from TextComponent
6. Build examples of customisation

Also I see you put the new text materials in /examples/materials, don't you think we could put all of them in /src/materials ?

The main idea is that three-mesh-ui would provide an easy way to customize its own materials : FontMaterial & FrameMaterial whose are placed in /src/materials.

But for customisation, we could only work within examples folders. "Look users, this is how you could customize three-mesh-ui Materials!"

Their is also a runtimeMixin FontMaterialUtils.from( threeJsMaterial ) which will do almost every alteration requires to enjoy a three material as a three-mesh-ui material. But three materials are not all totally similar. In the NormalMaterial implementation, some of our shader chunks are not fully compatible. So we would end up maintaining a bunch of small exception for each existing three material. IMO, what we only want is open a way for customisation, rather than providing all standard ways of customisation.

[swingingtom]

I would still add some ideas, but this is all for today

0. Redefine ways of using three-mesh-ui

As we would do new examples/samples; lets list what we like to write, what we dislike, how we would like, and discuss about it, in order to propose the way of writing examples.

4. Geometries

• [x] Text segments : Allowing more segments for vertex shaders
• [ ] Text splitLines : For each outputed line, having a separate mesh child
• [ ] Text splitChars : For each outputed char, having a separate mesh child
• [ ] geometryNeedsUpdate? replaceGeometry()? : Settings the previous properties would require a layoutUpdate, which will recreate all other children on the parent. Whereas changing segments, splitLines or splitChars won't alter the text dimensions/layout itself.

5. Text styles?

• [x] Bold :
  • [x] Define a font as bold in FontLibrary
  • [ ] Fallback if no bold font defined in Library : vertexShader that stretch vertices by x%?
• [x] Italic :
  • [x] Define a font as italic in FontLibrary
  • [ ] Fallback if no italic font defined in Library : vertexShader that skew vertices by their uv.y positions by x% ?

6. Other Updates

• [ ] Webpack 5
• [ ] @babel/preset-env : allowing stuff like that
• [ ] Cumulative onAfterUpdate? : Currently only one onAfterUpdate is possible.
• [ ] More Hooks : We currently only have onAfterUpdate. Should other hooks be useful? I foreseen bestFit as being externalized into an example behaviour component instead of being pushed in core.
• [x] FontClass? Internally relying on an object would make it easier to catch fontLoaded from children of Block.
• [ ] TextSelection?
• [ ] Composition over inheritance?
• [ ]

[felixmariotto]

OK all these ideas are good and relevant. However I think that we will have to prioritize things in order to keep the 7.0.0 milestone to a manageable scope, or I'm afraid we will never ship it.

0. Redefine ways of using three-mesh-ui

As we would do new examples/samples; lets list what we like to write, what we dislike, how we would like, and discuss about it, in order to propose the way of writing examples.

Personally I think that we could take the opportunity that we reorganize examples, to make new very advanced examples showing off the extent of what is possible with three-mesh-ui. Until now, examples have been rather simple in order to be easily understandable for beginners. Having something shiny to show for 7.0.0 release would be great.

4. Geometries

• [ ] Text segments : Allowing more segments for vertex shaders
• [ ] Text splitLines : For each outputed line, having a separate mesh child
• [ ] Text splitChars : For each outputed char, having a separate mesh child

These points are relevant, they improve upon what you already did in your branches.

• [ ] geometryNeedsUpdate? replaceGeometry()? : Settings the previous properties would require a layoutUpdate, which will recreate all other children on the parent. Whereas changing segments, splitLines or splitChars won't alter the text dimensions/layout itself.

Splitting updates into several fine-grained updates is a good idea to improve performance, but as it's not a trivial task and is not directly related to the proposed changes, I think we could open an issue and tackle this later on (8.0.0 ?).

5. Text styles?

• [ ] Bold :
  • [ ] Define a font as bold in FontLibrary
  • [ ] Fallback if no bold font defined in Library : vertexShader that stretch vertices by x%?
• [ ] Italic :
  • [ ] Define a font as italic in FontLibrary
  • [ ] Fallback if no italic font defined in Library : vertexShader that skew vertices by their uv.y positions by x% ?

Seems easy for italic, but are you sure it would work for bold ? Sounds like it would only perform an homothety... If italic is trivial but not bold, we could add italic to 7.0.0 roadmap and keep bold for later.

6. Other Updates

• [ ] Webpack 5
• [ ] @babel/preset-env : allowing stuff like that
• [ ] Composition over inheritance?

The first two points could be included, but we still have discussions to have about composition/inheritance... I feel this last point should be addressed in a separate milestone.

• [ ] Cumulative onAfterUpdate? : Currently only one onAfterUpdate is possible.
• [ ] More Hooks : We currently only have onAfterUpdate. Should other hooks be useful? I foreseen bestFit as being externalized into an example behaviour component instead of being pushed in core.
• [ ] FontClass? Internally relying on an object would make it easier to catch fontLoaded from children of Block.

Definitely relevant for this "cleanup / quality of life release"

• [ ] TextSelection?

Don't you think we need to first ship InteractiveRaycaster and refine VRControls before to venture into advanced interactions ? Baby steps will save us !

Edit: updated my second post

[swingingtom]

I was just throwing ideas. Indeed we would need to choose, priorize and establish dependencies before jumping in it.

Seems easy for italic, but are you sure it would work for bold ? Sounds like it would only perform an homothety... If italic is trivial but not bold, we could add italic to 7.0.0 roadmap and keep bold for later.

Indeed, this might not be our best option. But the idea is to provide a cheap fallback when no bold font version have been loaded/registered. The preferred/ recommended way is to provide a font variant. Which is especially true for italic fonts, which often redesign chars like 'a' example

[felixmariotto]

For bold fonts it just occurred to me, since our text rendering is based on distance fields I'm pretty sure we can improvise a shader-based solution for the fallback. Shall we put bold and italic in a separate issue or do you want to add it to the roadmap ?

[swingingtom]

We could group them into a task FontLibrary / FontClass / API Update - Add font variants. Using the recommended way of loading+registering font variants; italic, bold, black, italic+bold, etc.. would have the same preferred way, and therefore they could have the same logic.

After that, we could provided cheap fallback for those variants + variants combinations. At start, the cheap callback could simply be a warning : "No cheap fallback for the $variant. Please load and register it. +see $documentation-link".

[felixmariotto]

Okay, I created two new issues to track the refactor of FontLibrary and the italic/bold feature, and removed that from 7.x.x roadmap. I also removed style standardization, since you want to handle it beforehand (good idea)