enhancement: replace matplotlib with ipyvolume

[jeremymanning]

ipyvolume does amazing (and fast!) interactive 3d rendering. let's consider replacing the matplotlib engine with ipyvolume. To discuss:

• handling of plot options and arguments (how can we preserve as much of the current syntax as possible)?
• do we want to continue to support 2d rendering? is that possible/easy with ipyvolume?
• are there other cool things and/or plot styles we could support if we move to ipyvolume?

demo: https://www.youtube.com/watch?time_continue=1374&v=nZ3HQpSXn2U

[jeremymanning]

Addressed differently in the HyperTools 1.0 update (PR #272, #272): ipyvolume itself was never adopted, but the motivating need — fast, interactive 3D rendering — was met by a new optional plotly backend (hypertools/plot/plotly_backend.py) alongside the classic matplotlib backend, selectable via backend='matplotlib'|'plotly'|'auto' (see hypertools/plot/plot.py docstring, ~line 483; 'auto' picks plotly specifically on Colab/Kaggle).

How this could be built on the 1.0 architecture (if literal ipyvolume support were still wanted): the backend selector in plot.py already generalizes to more than two renderers — a third ipyvolume_backend.py module implementing the same draw-routine interface as matplotlib_backend.py/plotly_backend.py would slot in without changing the public API. This is a well-defined but nontrivial amount of work (every draw path — lines, scatter, surface, density, clustering — would need an ipyvolume equivalent).

Alternatives / prior art:

• plotly (already adopted) — dominant interactive Python viz library today, actively maintained (latest release 2026-06), broad ecosystem/community support, works both in notebooks and standalone HTML.
• ipyvolume — still on PyPI and not archived (GitHub last pushed 2023-11), but has a comparatively large open-issue backlog (213) relative to its userbase, suggesting thinner maintenance bandwidth than plotly.

Note: the literal ask (replace/add ipyvolume) is effectively superseded by the plotly backend, which covers the same "fast interactive 3D in notebooks" motivation with a more actively maintained dependency.

Tagging as low effort (no further code work recommended — this is a documentation/closing decision); leaving open only if the maintainer wants to confirm plotly fully covers the original use case before closing.