Gizmo randomly disappears in Level Instances

Development Pipeline & Plugins
, ,
1

While working within our organization we have encountered an issue that causes the gizmo to disappear. There are no reliable repro steps that cause the issue, but I’m forwarding findings from one our analysts:

Based on my limited debugging skills and several video recordings, my best guess is that the issue occurs when a user edits a Level Instance, saves it, and then starts PIE while still in Edit Mode. After closing PIE and trying to edit the same Level Instance again, the gizmo stops working and the user can no longer move objects inside the Level Instance. Unfortunately, despite trying for a week, I haven’t been able to reliably reproduce the issue.

---------------------------------------------------------------------------------------------------------------------------------

For the context. I can partly repro similar situation in the vanilla UE5: if I start editing some level instance and select actor out of it - this actor won’t have gizmo. So my culprits at the moment are direct edit mode and part loading of the level instances.

---------------------------------------------------------------------------------------------------------------------------------

  1. While editing a Level Instance use ctrl x + ctrl v on a mesh
  2. Notice gizmo disappearing
  3. Use ctrl z
  4. Use ctrl x + ctrl v again
  5. Notice gizmo reappearing

It also appears that similar issues were previously reported in previous versions as in here.

[Attachment Removed]

2

Steps to Reproduce[Attachment Removed]

3

Hi Michał,

Thank you for the report. I have been trying to repro the issue you described, but so far without success, as the transform gizmo keeps visible after performing each set of suggested repro steps.

You mentioned that you were able to repro a similar situation in the vanilla UE5. Ideally, it would be very valuable if you could provide a repro project or detailed step-by-step instructions to obtain that repro from a blank project. If this is not possible, can you please confirm some information to make sure we are on the same page?

  • When you mentioned “vanilla UE5”, do you mean UE 5.7 installed from the launcher?
  • The “Level Instances” related to this issue are the ones obtained by dragging a Level asset into the current persistent level, or by selecting some actors from the persistent level and “Right click -- Level -- Create Level Instance”, correct? Not sublevels added to the “Levels” tab, and not “Packed Level Actors”..?
  • Does the Persistent Level and the Instanced Level have “External Actors” enabled? Are they Basic or World-Partition levels? If world-partition, do they have “streaming” enabled?
  • What is the simplest scenario in which the issue occurs? Can you repro it from a blank project, with only a persistent level containing a single level instance without nesting, and just a simple static mesh on that level instance?

If you want to try to debug the issue on your end while it is happening, the transform gizmo is rendered by the following call stack:

FWidget::Render(const FSceneView * View, FPrimitiveDrawInterface * PDI, FEditorViewportClient * ViewportClient) Line 231	C++
FEditorViewportClient::Draw(const FSceneView * View, FPrimitiveDrawInterface * PDI) Line 4859	C++
FLevelEditorViewportClient::Draw(const FSceneView * View, FPrimitiveDrawInterface * PDI) Line 4962	C++
FSceneRenderer::FSceneRenderer(const FSceneViewFamily * InViewFamily, FHitProxyConsumer * HitProxyConsumer) Line 2721	C++
FDeferredShadingSceneRenderer::FDeferredShadingSceneRenderer(const FSceneViewFamily * InViewFamily, FHitProxyConsumer * HitProxyConsumer) Line 444	C++
FSceneRenderProcessor::CreateSceneRenderers(TArrayView<FSceneViewFamily * const,int> ViewFamilies, FHitProxyConsumer * HitProxyConsumer, bool bAllowSplitScreenDebug) Line 513	C++
FSceneRenderBuilder::CreateSceneRenderers(TArrayView<FSceneViewFamily * const,int> ViewFamilies, FHitProxyConsumer * HitProxyConsumer, bool bAllowSplitScreenDebug) Line 968	C++
FSceneRenderBuilder::CreateLinkedSceneRenderers(TArrayView<FSceneViewFamily * const,int> ViewFamilies, FHitProxyConsumer * HitProxyConsumer) Line 988	C++
FRendererModule::BeginRenderingViewFamilies(FCanvas * Canvas, TArrayView<FSceneViewFamily * const,int> ViewFamilies) Line 5176	C++
FRendererModule::BeginRenderingViewFamily(FCanvas * Canvas, FSceneViewFamily * ViewFamily) Line 5037	C++
FEditorViewportClient::Draw(FViewport * InViewport, FCanvas * Canvas) Line 4744	C++
FViewport::Draw(bool bShouldPresent) Line 1798	C++
UEditorEngine::UpdateSingleViewportClient(FEditorViewportClient * InViewportClient, const bool bInAllowNonRealtimeViewportToDraw, bool bLinkedOrthoMovement, bool * bOutViewportDrawn) Line 2683	C++
UEditorEngine::Tick(float DeltaSeconds, bool bIdleMode) Line 2346	C++
UUnrealEdEngine::Tick(float DeltaSeconds, bool bIdleMode) Line 537	C++
FEngineLoop::Tick() Line 5828	C++

For debugging, I would suggest disabling “Editor Preferences -- General -- Performance -- Editor Performance -- Use Less CPU when in Background”), then placing a breakpoint on FWidget::Render() [UnrealWidgetRenderer.cpp:231] to see if it is being hit (with the callstack above). If not, you can place a breakpoint on each point up the callstack to find out the last point where the execution hits and what is the conditional that is failing. If FWidget::Render() is hit, you can inspect the value of the local variables (especially “bDrawWidget” and “WidgetLocation”) to see if they seem as expected (you can also copy and paste them here if you want help with that).

Best regards,

Vitor

[Attachment Removed]