With the addition of the new In-World UMG Widgets (thanks for this, by the way, being able to use real UI as world-space objects opens up a ton of possibility) I’ve been building an in-world nameplate system for NPCs and players, and have run into two related gaps that I think are worth flagging as feature requests.
1. No way to edit the Entity’s pivot point
When a WBP is dragged into the world, the resulting Entity’s widget appears to default to a (0,0) pivot rather than (0.5, 0.5), so even when everything inside the widget (Stack Box, text blocks, etc.) is centered and reporting a 0.5/0.5 pivot at the UMG layer, the rendered content is shifted right/down from where the Entity is actually placed, because the 3D quad’s top-left corner is anchored to the Entity’s origin instead of its center.
The built-in editor pivot tools do not fix this at all. Right-click “Center on Selection” has no effect and the pivot indicator stays stuck in the upper-left regardless, which suggests the Entity’s bounding box isn’t being reported correctly for this widget type yet. There is no usable pivot workaround from the editor side.
The only fix I found was to wrap the widget’s content in a Size Box, set an Override Width (500 in my case), and then apply my own positional offset through Verse to compensate. For reference, in my player nameplate use case I expected an offset of -250 (half the 500 width) to center things, but that wasn’t correct. The nameplate was only actually centered over the player at an offset of -200. I don’t have a clear explanation for why -200 is the correct value instead of the expected -250, which itself suggests something isn’t lining up correctly under the hood between the Size Box dimensions and how the Entity’s actual pivot/anchor is being calculated.
Ask: Expose a numeric Pivot / Pivot Offset property directly on the In-World UMG Entity (in the Details panel, alongside Draw Size and Space), so creators can set 0.5/0.5 centering explicitly instead of relying on a Size Box + manually-tuned Verse offset workaround with unpredictable values.
2. No way to make the widget always face the camera (billboard)
Right now, an In-World UMG widget parented/attached to another Entity (for example, a socket on a character) simply inherits that parent’s full rotation. For a nameplate use case, that means the plate rotates with the character’s head/body instead of staying legible to the viewer. There’s no built-in billboard behavior in SceneGraph for this yet. The only way around it is a manual per-tick Verse correction that cancels the parent’s inherited rotation and substitutes a yaw-only rotation computed from the delta between the widget’s world position and the local player’s camera position, which works but adds extra runtime cost and complexity for something that feels like it should be a checkbox (similar to how legacy billboard components or Screen Space UMG behave automatically). Switching to Screen Space avoids the problem but sacrifices world-space depth/occlusion, which is the whole reason to use an in-world widget in the first place.
Ask: Add a “Face Camera” / billboard toggle on the In-World UMG Entity that handles the rotation correction natively (ideally per-client, since this needs to face each viewer’s camera individually in a multiplayer context), so creators don’t need a manual tick loop just to keep a nameplate readable.
Additional note, widget creation bug (already reported separately, repeating for visibility):
Worth mentioning here too since it’s directly related to working with this feature: newly created UMG User Widgets (even with zero Verse variables) currently fail to place in-world on first drag with a has no reflected Scene Graph entity. Ensure all of its variables have default values and recompile Verse. error. Duplicating an existing, already-working widget avoids the error entirely; only freshly created widgets are affected. This points to the reflection/entity-generation step succeeding for assets that already carry a reflected entity but failing for assets that need one generated from scratch. Filed as its own bug report, but flagging it here too since anyone testing pivot/billboard behavior on new widgets is likely to hit it first.
Happy to answer any questions if that helps get this looked at.