Allow configuring the kind/category of a space view after its creation

[Wumpf]

Currently, a space view has a single category that is determined once at creation.
It governs what the space view looks like/how it's renderer and how interaction works with it. Additionally, it imposes restrictions on which Entities can be added (we compute a list of categories from each).

The category is determined either by user interaction on creating it or (more common?) by being automatically created through a heuristic.

There are are many cases where it may make sense to choose a different space view after the fact, most prominently Tensor & Spatial view.

There are a lot of open questions related to this, some of which touch on other issues:

• what happens with entities that can no longer or only partially be displayed? How to indicate this?
• how flexible does each category need to be?
• Should 2d & 3d become separate categories again, or stay together in the "spatial" category
• How well integrated should space views be into each other - e.g. is there ever a meaningful way to display a time series in a 3d context? If yes how if no why not.

[teh-cmc]

I was dumping thoughts on the subject and realized there was already an issue for it! Allow me to add my notes.

Ability to pick visualizer/renderer for a given primitive

Most primitives in Rerun can be interpreted (i.e. rendered and interacted with) in many different ways (or at least could).

Example 1: depth maps

A depth map can be visualized as..:

• a 2D image (potentially color mapped) in an image view (nice hover preview & zoom)
• a 2D tensor (potentially color mapped) in a tensor view (not particularly useful)
• a 3D point cloud in a spatial view
• a discrete, raytraced 3D volume in a spatial view
• etc, any number of plugins you can imagine

Example 2: tensors

A tensor can be visualized as..:

• a tensor in a tensor view (nice slicing & dicing interface)
• an image in an image view (provided the tensor can be squeezed into 2D, or that the user has some way of picking 2 dimensions)
• as a discrete, raytraced 3D volume in a spatial view (if its dimensions permit it: WxHxF32, WxHxRGB, etc)
• as a continous, raymarched 3D volume in a spatial view (it its dimensions permit it)
• etc, any number of plugins you can imagine

As a user you want to be able to switch between these different representations at runtime directly from the viewer.

Interestingly, it's easy to think of cases where only the rendered primitive needs to change (e.g. going from a point cloud in a spatial view to a discrete volume in a spatial view), while in other cases the entire way of interacting has to adapt, i.e. we're modifying the kind of space view itself (e.g. going from a tensor in a tensor view to a continous volume in a spatial view).

Also, some cases might require the user to express how the data should be reinterpreted, e.g.:

• interpreting a tensor as a 2D image: what dimensions should be kept? (sometimes it can be guessed with a heuristic if there are empty dimensions etc)
• interpreting a depth map as a discrete volume out of a pinhole: same issue as with our pinhole projection and the distance of the plane

[Wumpf]

we decided to keep space view types fixed