The “mouse movement sometimes fixes it” part is the useful clue. A world-space widget only repaints its render target when Slate marks it dirty. The editor viewport often ticks that component every frame, so it looks right there. In a Fortnite session the same component is usually on a timed redraw, and moving the cursor is one of the few things that invalidates the widget and forces a new paint. Until that happens you are looking at a stale target, which reads as a random dark quad.
On the Widget component:
- Set Redraw Time to 0 so it paints every frame. If that costs too much, leave a non-zero time but call RequestRedraw() when the camera or the exposure changes, instead of waiting for a hover.
- Check Blend Mode. An Opaque world widget is lit by the scene and by eye adaptation, so it goes dark as soon as the game camera’s exposure is not the editor’s fixed exposure. Transparent (or Masked) keeps the color you authored in UMG.
- Turn Two Sided on if the component can face away from the camera in play. The back face of an unlit widget is just a dark card.
- Raise Draw Size to match how close the camera gets. A tiny render target plus TSR looks like a dark smear even when the UMG itself is fine.
If it is still dark with Redraw Time at 0 and a Transparent blend, it is exposure rather than the widget: the island’s post process min/max EV is different from the editor viewport. A widget that is correct in the editor and dark only in play is almost always one of those two, and the mouse “fix” points at redraw first.
1 Like
Thanks. I managed to fix it by just changing transluency priority.