Handle features for picking in a more scalable way

[ptrgags]

Right now, the picking system requires making a Cesium3DTileFeature (or ModelFeature) for every feature in the property table. This can be problematic, especially for point clouds:

• In ModelExperimental, right now property tables are turned into feature tables without any checks for the size or whether a tile is a point cloud. This means creating thousands if not millions of Cesium3DTileFeature in memory 😬
• In 3D Tiles 1.0 code, picking is disabled point clouds to avoid such a problem

If possible, it would be better to store features in a more scalable way. A couple initial ideas, though I think this requires more discussion.

Option 1: Pick ID Ranges

What if we allocate pick IDs by ranges (e.g. a point cloud might store a single object representing 2000 consecutive feature IDs that map onto pick IDs 1000-2999)

Then when a content needs to call .getFeature() it's just a few math operations to index into the global list of features in the context. The Cesium3DTileFeature object can then be constructed on the fly.

There's one big caveat though: for EXT_mesh_features, we want to support arbitrary feature IDs for indexing into external databases. There's no guarantee that these are consecutive. I'm not sure if there's a way to handle this without creating a huge table of valid values in some form or another...

Option 2: Write ID directly to framebuffer(s)

This one would be a larger change of the picking system - what if instead of mapping feature IDs to pick IDs in a constrained uint8 RGBA texture, we used multiple render targets (requires MRT). Then each pixel could write multiple values: (primitiveId, featureId).

This way, the context would only need to store a list of pickable primitives rather than every single feature. The featureId value read from the framebuffer pixel could then be used to construct the Cesium3DTileFeature object on the fly.

The one benefit of using MRT here is it will also help with property texture picking (see #9852)

See also

• Model EXT_mesh_features: handle feature IDs without a property table #9884 (comment) -- more about the feature ID picking issues
• Supporting picking properties from property textures #9852 (comment) -- for more about the MRT idea.