2D visualizers are no longer applicable to paths that are behind a pinhole camera other than the space's origin

[Wumpf]

What

Fixes broken heuristics for structure_from_motion.

This is a bit of a hacky addition. We need to solve this with a proper SpatialTopology data structure that can tell us efficiently if we're inside a 2d/3d space and how far it reaches.

See also

• Re-engineer the space-view heuristics engine #4388

picture showing that a 2D space at camera is no longer suggested since it wouldn't be able to show anything: camera/image has a pinhole projection, therefore camera -> camera/pinhole is a 3D->2D projection but by having a 2D space at camera we implied camera to have an eye pinhole.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using newly built examples: app.rerun.io
  • Using examples from latest main build: app.rerun.io
  • Using full set of examples from nightly build: app.rerun.io
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[jleibs]

Suggested change

	pub invalid_subtrees: Vec<EntityPath>,
	pub nested_pinholes: Vec<EntityPath>,

[jleibs]

I retract this suggestion -- there are other things that could be invalid

[Wumpf]

checked performance on python ./examples/python/open_photogrammetry_format/main.py --no-frames: It's not free, but ~0.5ms while generally pretty bad don't make much of a dent here and we already know how to make this significantly better