Forget 3D

[axelpale]

We tried to make Tapspace.js to work in 3D. After a lot of work and many trial-n-error attempts, we must conclude that it is not worth it, at least in the context of zoomable web UI. Tapspace v2.0.0-alpha.8 was the last version with much of 3D stuff in place and implemented. And then we had to drop it. This issue documents some of the reasons why.

Problems with 3D:

• browser compatibility
  • browsers support 2D CSS transforms much better than 3D.
  • Firefox and Safari render text in the original pixel size and upscale that while Chrome renders the text in the viewport resolution. Because Tapspace.js must support all common browsers, Firefox and Safari form the bottleneck. The app developer should be able to automatically resize the content according to how large the content is on the viewport. That causes content reflow, lines jumping and work.
• problematic navigation
  • scaling vs translation along z. In 2D, going deeper meant only one thing: scaling. In 3D we have either scaling or translation. If we have content in various scales in 3D space, maybe even recursive fractal structures to infinitely small scales, it is so complex to build an easy way to navigate in that situation.
  • finding the navigation basis. While in 2D everything behaves similarly, in 3D, the effect of a gesture on an object near camera is much smaller than the same gesture on an object far away from camera. It is possible to transit the gesture effect onto the target and it worked quite well. However, if gesture was made on the background, which often was the case, it required complicated search for an object near by. Possible but complex and computationally intensive without octree indexing.
• keep it simple, stupid
  • gut feeling: problems are 10x harder in 3D
  • if both 2D and 3D were supported: almost every method would have if(viewport.mode === '2d') kind of code. Requires constant retrieval of viewport and additional checks everywhere.
  • maintaining the library for all possible situations that emerge from 3D features. Huge task.
• no nested content in 3D, without tricks
  • elements steal input events. If we placed content below a transparent node, we cannot interact with the content, because the node would steal all input. Setting pointer-events: none does not help either, because the content would not be an ancestor for the transparent node.
• efficiency for big data visualizations
  • 3D is computationally intensive. We cannot do visualizations that have more than about 300 elements in 3D.
  • Flat 2D content can handle thousands of elements with smooth interaction.
  • Flat 2D surfaces in 3D space works fine from computational efficiency perspective. Limits the value of 3D, though.

Benefits of 3D:

• interesting content layouts, cool.
• parallax motion may help in perceiving depth.
• browsing dense content may be more practical because perspective allows peep between.
• might provide insight for spatial data.

Therefore, for these reasons, we decide that 3D Tapspace.js is not worth given the benefits. Starting from v2.0.0-alpha.9, most 3D features are removed. Still, geometry and tensors likely stays 3D and there will be tools to project 3D geometry to 2D so that it can be efficiently rendered. Also, we might have planes that refresh their position and scale in 2D to simulate 3D space.