Quick answer: A 3D WidgetComponent needs collision enabled and either Receive Hardware Input on (for cursor games) or a WidgetInteractionComponent driving it (for ray-based input).
An in-world control panel is a WidgetComponent in 3D space. Buttons render but don’t respond to clicks.
Collision Is Required
The WidgetComponent needs a collision setup so input rays can hit it. Set its collision to a profile that the interaction trace channel can hit (UI / Visibility, depending on your input method).
Cursor-Driven (Receive Hardware Input)
For a mouse-cursor game, enable Receive Hardware Input on the WidgetComponent. The PlayerController must also have bShowMouseCursor = true and an input mode that allows UI. Clicks at the cursor are projected onto the widget.
Ray-Driven (WidgetInteractionComponent)
For VR, gamepad cursors, or first-person interaction, add a WidgetInteractionComponent to the pawn/controller. Point it down the look/controller ray and call PressPointerKey / ReleasePointerKey on input. It synthesizes widget input from the ray hit.
Match the Trace Channel
The WidgetInteractionComponent has a Trace Channel. The WidgetComponent’s collision must block that channel — a mismatch means the ray passes through.
Verifying
Look at / point at the panel and press — buttons hover and click. Hover states update as the cursor or ray moves across the widget.
“3D widgets need collision plus an input driver: Receive Hardware Input for cursors, WidgetInteractionComponent for rays.”
WidgetInteractionComponent is the more flexible choice — it works for VR, gamepad, and first-person with the same code.