Three.js r184 führt HTMLTexture ein: Live-DOM als 3D-Oberfläche
Three.js r184 ist diese Woche erschienen. Die wichtigste Neuerung ist die Klasse HTMLTexture, mit der sich jedes aktive HTML-Element als Textur auf einem Mesh verwenden lässt. Schaltflächen bleiben anklickbar, Eingabefelder fokussierbar, CSS-Animationen laufen weiter, und der Browser kümmert sich wie gewohnt um Barrierefreiheit und IME.
Chromes offizielle Einführung in die HTML-in-Canvas-API, auf der HTMLTexture von Three.js basiert
HTMLTexture in einem Absatz
HTMLTexture kapselt die HTML-in-Canvas-API von Chrome 146. Du übergibst ein DOM-Element. Three.js setzt layoutsubtree auf dem Canvas, hängt das Element in das DOM des Renderers ein und projiziert seine gerasterte Ausgabe in eine THREE.Texture, die du mit jedem Material unter WebGL 2 oder WebGPU verwenden kannst. Die offiziellen Beispiele (webgl_materials_texture_html und webgpu_materials_texture_html) enthalten formatierten Text, Bilder, SVG, ein funktionsfähiges Eingabefeld und eine Schaltfläche.
In der Praxis bedeutet das, dass React-Komponenten, Designsystem-Widgets, Videoplayer, Diagramme oder vollständig eingebettete Seiten auf einem gebogenen Bildschirm, einer Werbetafel oder einem UI-Panel innerhalb einer Three.js-Szene platziert werden können – ohne den üblichen Kompromiss: „Auf ein Canvas rastern und dafür die Interaktivität verlieren“.
Der Haken
Die Funktion ist nur dort verfügbar, wo die zugrunde liegende API existiert. Derzeit ist das Chromium 146 oder neuer mit aktiviertem Flag chrome://flags/#canvas-draw-element. Produktionsseiten benötigen daher weiterhin eine Ausweichlösung. Der PR hält diese Möglichkeit offen, indem HTMLTexture bei fehlender API kontrolliert fehlschlägt. Bevor du Kunden jedoch ein vollständig interaktives Three.js-Dashboard versprichst, solltest du die Unterstützung der Funktion prüfen.
Safari und Firefox haben noch keinen Zeitplan angekündigt. Da selbst WebGPU erst Ende 2025 in allen drei Browsern den Baseline-Status erreicht hat, dürfte HTML-in-Canvas einen ähnlichen Zeitraum von etwa zwei Jahren benötigen.
Eine Community-Demo von HTML-in-Canvas aus der Zeit vor der Veröffentlichung des Three.js-Wrappers
Die zweite große Neuerung: keine Allokationen pro Frame
Die weniger spektakuläre, aber wohl wichtigere Änderung betrifft den kritischen Renderpfad. Vor r184 konnte das Rendern von 1.000 Meshes mit 60 FPS pro Sekunde 240.000 bis 500.000 kurzlebige Objekte allokieren. In jeder länger laufenden Szene musste sich anschließend der Garbage Collector darum kümmern. r184 beseitigt diese Allokationen aus der zentralen Renderschleife. Lang laufende WebXR-Sitzungen, detailreiche Bauprojekt-Viewer und alle Szenen, die länger als die ersten 30 Sekunden aktiv bleiben, profitieren dadurch ohne zusätzlichen Aufwand von stabileren Frame-Zeiten.
Kleinere erwähnenswerte Änderungen
AnimationAction behält nun beim Erstellen die Interpolant-Einstellungen bei, sodass ein Umkehren von timeScale keinen Sprung mehr verursacht. AudioLoader gerät nicht mehr in einen Wettlauf mit dem Loading Manager. BatchedMesh und InstancedMesh lösen in getColorAt keinen Fehler mehr aus, wenn keine Farben festgelegt wurden. Die veralteten WebGL-Renderpfade für Instancing wurden endgültig entfernt. Die Beispiele wurden um einen SSGI-Bällepool, volumetrische Wolken im 3D-Tiles-Loader und Kurvenneigung für die Achterbahnkamera erweitert.
Was wir damit machen würden
Für Cinevva ist der interessanteste Anwendungsfall eine direkt im Canvas gerenderte Benutzeroberfläche für den Reels-Player und die Creator-Tools. Derzeit legen wir HTML über Three.js. Mit HTMLTexture könnten das Chat-Overlay, der Asset-Browser und das Prompt-Eingabefeld direkt auf Geometrie innerhalb der Szene liegen, ohne dass die Tastaturnavigation verloren geht. Sobald die API ohne Flag in der stabilen Chrome-Version verfügbar ist, werden wir eine per Feature-Flag aktivierbare Variante integrieren.