New Actor has unexpected default Bounds

The default SceneComponent that comes with a New Blueprint Actor has unexpected Component Bounds. See Picture1.

The second Picture shows the Problem in Simulation Mode where the Bounds turn Invisible on the Empty Actor and showing the wrong Bounds on the Actor with a MeshComponent attached to the default SceneComponent.

Note: Get Actor Bounds Node will get the wrong extend. But the Get Component Bounds Node with the default Scene Component its correct (0,0,0) as expected. That leads to the Conclussion that there is another not listed Component (I susspect the Billboard) that has those Bounds.

Hello,

I’m not sure I’m following exactly what the issue is.

  • What results are you expecting to see with the Get Actor Bounds node with the new actor blueprint with no additional components?
  • What are the results that you are seeing and why are they unexpected?

Hi Sean,

I think its Quicker to See the Issue for yourself. I give you a Step by Step guide.

  1. Turn on the Bounds Visualizer under Show->Advanced->Bounds that has no side effects its just for visualization
  2. Create a New Blueprint Actor (lets call it Actor A) and Place it in the Scene if you Select Actor A you can See, it already has Bounds (thats the issue!)
  3. Create a New Blueprint Actor (lets Call it Actor B) open the Blueprint and Delete the Default Scene Component.
  4. Add a Scene Component again to Actor B and Place it in your Scene. Select Actor B and you will See there are no Bounds at all. That is what I would Expect in Actor A.
  5. To further Demonstrate the Problem Add a Static Mesh Component to both Actor A and B. Assign it the 1m Cube Mesh that comes with most Template Projects or any small Mesh you like. Select both Actors to See the Bounds again and you will notice that Actor A still has Bigger Bounds than the Mesh. Where Actor B has exactly the Mesh Bounds you would expect.
  6. You can also open the Blueprint Graph of both and add a “Get Actor Bounds” node and print the “Box Extend” Vector on Screen and you will See that Actor A will give you the Unexpected Value (128,128,128). If someone uses Box Extend in his Blueprints this will mess up all Calculations with the Default Component of Actor A.

There should be no Bounds at all with a New Blueprint or alternativly every Functions that Get the Bounds should skip the default Scene Component.

(And sry if you are Confused by my Account name I created “NachtmahrDev” on accident because I thought Answer Hub uses a seperate Account)

Hello,

Thank you for the information. I have been able to reproduce this issue, and have entered a bug report, UE-31496. Thank you for your report.

In the meantime, to prevent any issues, I recommend using a Scene component in place of the Default Scene Root wherever possible.

Have a great day

Hi Sean I want to give you a little Update I noticed. It seems like everything that has a Billboard like a TriggerBox or Lights has those Bounds. In case off the Light there is currently no workaround. Just letting you guys know its certainly a important aspect to solve the Problem or providing a Option to turn the Billboards off as a tradeoff.

Thank you for your Time.

Nachtmahr,

We’ve created a fix for this that will be in 4.13. It’s actually quite simple though, so you should be able to replicate it easily.

// SceneComponent.cpp
// USceneComponent::OnRegister()
void USceneComponent::OnRegister()
{
    // ...
#if WITH_EDITORONLY_DATA
    if (bVisualizeComponent && SpriteComponent == nullptr && GetOwner() && !GetWorld()->IsGameWorld() )
    {
        // Create a new billboard component to serve as a visualization of the actor until there is another primitive component
        // FIX: Change RF_TextExportTransient to RF_Transient
        SpriteComponent = NewObject<UBillboardComponent>(GetOwner(), NAME_None, RF_Transactional | RF_Transient);

        // ...
    }
#endif
}

Now, when viewing bounds for these components in the editor you still may see the wrong bounds. However, when you actually play the level (even in PIE) they should have the correct bounds.

Thanks,
Jon N.

That was esier than I thought! I was looking at a very different point to fix the issue myself =)

Thank you for the Fix Widmo! I will try it out tommorow probably.