Loom Docs
loomgui.com ↗

LoomView & input

LoomView is a Unity component that:

  • Displays your UI as a transparent overlay over the game scene.
  • Captures mouse and keyboard input and forwards it to the UI.

You don’t write a LoomView yourself. Add one to your scene via Loom -> Setup UI in Current Scene, which creates a canvas with LoomView and a LoomInputCapture already wired up.

How input works

LoomInputCapture polls Unity input each frame. Both the legacy Input Manager and the new Input System are supported (set via Player Settings -> Active Input Handling); when both are enabled, the new Input System takes precedence. When the cursor is over the LoomView rect, it forwards:

  • Mouse move, click (left / right / middle), and scroll wheel
  • Keyboard key down / key up, plus committed text input, with DOM code/key semantics
  • Modifier state (shift, ctrl, alt, meta; Cmd and Win both map to meta)

Loom wires up exactly one LoomInputCapture automatically for you, on the Loom View.

While the cursor is pointer-locked (Cursor.lockState == Locked, typical for FPS camera control) pointer dispatch is suppressed and a synthetic leave is sent so DOM hover state clears.

Pointer events are dispatched whenever the cursor is within the LoomView’s rect and the view is visible. Forwarding input only where your UI actually has interactive elements (so clicks on empty HUD areas still reach the game) is handled on the UI side; see the sample HUD for the pattern.

Transparency

The UI is composited on top of the game scene with full alpha. To make a region transparent, give it background: transparent and no opaque children. The HUD screen in the sample is a good example: most of the screen shows the game beneath, and only the bars, score, and ability rings are opaque.

DPI

The view auto-scales to match the game’s logical resolution. On high-DPI (retina) displays, the UI renders at native pixel density: CSS 1px corresponds to one logical pixel, rendered through the display’s device-pixel ratio (e.g. 2× on retina) for sharpness. Detection is automatic; you can override the scale on the LoomView component if a target machine reports it wrong.

One view per game

Loom renders a single UI surface per process, so there is exactly one active LoomView. If a second LoomView appears (for example, a new scene brings its own Loom canvas), the duplicate removes itself and the original persists via DontDestroyOnLoad. Route between different UI surfaces (HUD, pause menu, inventory) with your Solid app’s own screen switching inside that one view, driven by a [BridgeState] screen enum. See The bridge and the sample’s screen routing for the pattern.