Hello Team Epic!
I’m having problems with the UMG Render Transfrom Scale. If I change the scale less than 1.0 I get clipping at the edges of the viewport.
I have included a video to show my problem.
[Video showing the Clipping Issue][1]
Engine Version 4.6.1
Let me know if you need more information. Thanks!
Hello ,
This issue is caused by the bounding box of the widget not being re-sized when the widget is scaled. The bounding box will remain the original size of the widget and this is what determines when widget is clipping. In short you will need to set the size of the widget to fix this issue.
The following is a picture of an image the size of the viewport that has been scaled down by half. I have out lined the bounding box in red. I realize that this looks like the line that shows the edges of the viewport but that is because the original size of the image took up the entire widget. This means that if I move the image in any direction it will start to clip immediately even though it looks as if it is not touching the edge. I hope that this helps
Make it a great day
Thanks for the Response Rudy. I’m having a little trouble understanding the solution. I clamp the movement to not go outside of the scaled widget. It seems the clipping zone is being referenced from the parent widget for the true bounds and then applying it with an extra offset to the render transform.
My question is how do I control the clipping or can I just turn it off? Everything is working perfectly for the dynamic scaling of the widget except for this little clipping issue if I scale less than 1.
The only other way to do what I’m doing is to loop through children’s geometry, padding, and margins to modify it. However, that is very difficult to due currently through blueprints, if possible.
I would be more than happy to give you this UMG project to see what I’m doing if needed.
Hello ,
I would be more than happy to take a closer look at your project if you wanted to provide it. After I receive your project I will be able to provide a more specific answer.
Awesome, I sent the dropbox link to you in a private forum message =). Thanks so much!
Hello ,
I have found a way to solve the clipping issue. However, the text for the buttons will need some fine tuning. I hope that this solution is viable for your situation.
Since you sent your project privately I made sure to leave out as much of your blueprints as possible in the picture below. If you have any questions regarding the changes I made please feel free to reply with those concerns.
Update Size:
I took out the scaling node that was in here before and replaced it with the nodes in the picture. To recreate this all you will need to do is build what is seen in the picture and connect the “Make Vector 2D” node to the “Break Vector 2D” node. (There should be only one make Vector 2D in this graph). Next you will need to connect the out going execution pin of the “Set YScaleRatio” node to the in going execution pin of the “Set New Size” node.
EventGraph:
Initial Size is as it sounds the beginning size of the widget before modification.
On Mouse Button Up:
This is used to reset the Initial Size of the widget to the New Size after the widget has been “scaled”
Make it a great day
Thanks for the suggestion Rudy, I really appreciate it.
I actually started out this way on my first attempt, the problem came when you start to put padding into your buttons or specify sizes for images and then also, as you point out, for the font scaling issues.
I pulled out going down this path as just using the Render Transform fixed all of those difficult problems for a variety of different windows.
Basically, I’m creating a window that I can drag, resize, dock, & collapse. Something I had working in my last engine, which I can take that generic window and layout specific content into it.
It seems very difficult just to resize laid out content in a widget container. Do you have suggestion on this? -Thanks for the continued help. =)
Hi Rudy,
I spent last night focusing on this problem and ended up going into the engine code. I was able to find the “bug” and did an engine fix to confirm it. There is a bug with the clipping calculation. I’m going to do some more testing today and put the pull request in.
I’ll let you know the details when I get my ducks in a row here. But this will also fix other render issues with RenderTransforms
Have a great day =)
Hello ,
That sounds great! I will be interested in learning about your results. If you meet with success could you make a post here with the information needed for the fix? This would help other users experiencing the same issue.
Sure no problem Rudy!
Basically the problem is that the function “int32 SConstraintCanvas::OnPaint” is modifying the ClippingRect without any considerations for the AccumulatedRenderTransforms.
Later down the line after it is calculated for the “FSlateVertex” vertices and sent through the Renderer. After it goes into the rendering thread, it applies the rendertransform to the clipping region as if its still the “whole” widget not the newly clipped version. At this point it “Engine Access” becomes a problem for me, but regardless the data has already been lost from the above function.
The fix is to change the function to:
int32 SConstraintCanvas::OnPaint( ..............
............
for (int32 ChildIndex = 0; ChildIndex < ArrangedChildren.Num(); ++ChildIndex)
{
FArrangedWidget& CurWidget = ArrangedChildren[ChildIndex];
FSlateRect ChildClipRect = CurWidget.Geometry.GetClippingRect();
const int32 CurWidgetsMaxLayerId = CurWidget.Widget->Paint(Args.WithNewParent(this), CurWidget.Geometry, ChildClipRect, OutDrawElements, MaxLayerId + 1, InWidgetStyle, ShouldBeEnabled(bParentEnabled));
MaxLayerId = FMath::Max(MaxLayerId, CurWidgetsMaxLayerId);
}
..........
Now, my first fix was to extract the rendertransform scale information for my problem and only ignore the clipping if the scale was less than 1 for either axis and it worked fine. However, it didn’t take care of the translation transforms.
I ended up researching and testing SConstraintCanvas on how its used and decided that it was unecessary to do the clipping here. It was actually redundant in all of the use cases. Overlay and other controls that clip implement their own version. Then CanvasPanel clipping was handled farther up the chain as it is the view port.
My final fix to fix all of the RenderTransform scenarios was just to remove the redundant clipping. I haven’t had any issues with doing this and all the scenarios are working.
I hope this helps and maybe its not the best solution, but its working =) Thanks!
Yeah, so this works good in Standalone and not as good in PIE. If you don’t clamp your widgets from moving past the viewport edges like I do, you will drag out past the PIE viewport. There will have to be a more thought out permanent solution on this. I’m hoping that Epic can provide a better way to fix it internally?
I’ll use this as a temp fix for now.
Thanks!
Hello ,
Thanks for the update and great work. I am happy that you have this working for you. I am going to go ahead and mark your reply as the answer to the post until changes are implemented internally.
What exactly is the solution for this? The bug is still inside 4.7.4, so I would like to know how to workround this with panels which don’t have a “SetSize” Node.
Hello ,
It all depends on what you are trying to accomplish. I have done something similar to this on my end. I found that creating the widget you would like in a widget by itself and then using it as a user created widget that is placed inside of a scale box (Scale box only holds a single child so this is why two widgets would be needed) will work for any scaling needs.I hope this information helps.
Example:
Make it a great day
This works for me too! On 4.10, this workaround is the only one effectively working to solve UE-4659! Thank you , this one was vital for my project! I hope this gets integrated in the Engine.
It would be really awesome if people who are experiencing this problem could upvote the issue in the issue tracker to help let Unreal know that we’d love it fixed!
Vote here: → UE-4659