Scene Actor's bounding square (screen space)?

Before I start trying to reinvent this wheel, is there an existing combination of nodes that can be used with the (2d) DrawLines UMG node to draw a 2d bounding square around a scene actor?

An example of the desired end result, is shown in screenshot.

I attempted to convert thetriponator’s C++ code as shown here:

but ran into problems where Box2D is used as there are no equivalent Box2D.Min / Box2D.GetSize() functions in blueprint. There is a Box2D type in blueprint, but it seems to be lacking functions.

I tried creating equivalent Box2D functions to store min/max values when iterating over the 8 bounding box points
but couldn’t get it to work.

Cheers.

Hello,

I cannot reproduce the tighter fit bounding box solely in Blueprints, but I can get you everything after that point, and the simpler 3D-bounding box in 2D space method:

For this example, I simply create the widget in the level BP, and assign it to my Actor.

294294-figure1.png

Level BP:

Next in the widget, we create an override function for OnPaint, that draws a box from the top left corner to the bottom right.

Overriden Function in Widget “OnPaint”:

Most of the heavy lifting goes on in the widget blueprint’s event graph. First we calculate the 8 vertices that make up the 3D bounding box.

I have a debugging method to visualize these points, but you can skip or disable it as you see fit. I’ve run out of screenshots, but you can see it in the BlueprintUE link.

Next we convert these 3D points into 2D points on screen. (Its worth noting that if you can find a way to get a more accurate series of points representing your mesh, such as socket that you place at the extents of every joint, you can leave the rest of the code unchanged.)

Then we recalculate the box by finding the uppermost point, and the leftmost point, and combined them to make the top left corner. Similarly we find the rightmost point and the lowermost point and combined them to make the bottom right corner.

Widget Event Graph:

Once thats all set up, you can test the effect by running play-in-editor
Here is a video sample of the end result:

Missed one, sorry. Be sure to reset the BoxStart and BoxEnd variables as shown here just before you recalculate the box.

Hi Ian,

Your solution worked out great!

I had 50% similar (ish) scripting so didn’t have to re-script everything, but the most important part was the ‘box calculation’ (Uppermost / Leftmost / Rightmost / Lowermost points) which is where I got stuck. Your screenshot solved my problem so thanks for that.

Just so I can add a note for future reference: can you briefly explain why the local/absolute size multiplier was necessary?
i.e.,

[Get Player Screen Widget Geometry].GetLocalSize()

[Get Player Screen Widget Geometry].GetAbsoluteSize()

I would never have thought to use the local/absolute division as a multiplier, but noticed that the bounding rect does not work without that multiplication.

>I cannot reproduce the tighter fit bounding box solely in Blueprints, but I can get you everything
>after that point and the simpler 3D-bounding box in 2D space method

The loose rect solution is fine for my purposes as it is only a general ‘region tracker’ and doesn’t have to be exact (for now).



>(Its worth noting that if you can find a way to get a more accurate series of points representing your mesh,
>such as socket that you place at the extents of every joint, you can leave the rest of the code unchanged.)

If I later need a tighter bounding rect I’ll probably experiment with a sphere (capsule?) trace to get the points representing the furthest hit extents on an actor’s mesh (top/bottom/left/right from the camera’s view) . I could then project those four points to screen space, calculate a rect and draw the 2d bounding box. Not sure if it would work, but would be a good place to start.

Cheers!

I’m glad it worked for you!

“why was the local/absolute size multiplier was necessary?”

I set that up on a hunch. My 2D box was initially offset and too large. When I changed the viewport size, the size of the box changed with it. Based on this info I knew that the unit size of the 2D space was missing a multiplier to shrink it to match my viewport size. The division of local widget geometry size by global widget geometry size is finding the percentage of the screen not taken up by editor window widgets (I assume). This would not be necessary if my widget geometry took up the full screen, which it probably does in Standalone Window mode.

Noted.
Thanks Ian!