Wondering about two different things, but I wanted to just post them as one question to see if anybody can help me out
So, the first question is about 3D widgets’ opacity value. Right now it doesn’t seem possible to directly change the opacity of a 3D widget. I was also not able to find any overall opacity value within the Widget itself, to talk to from the actor that contains the 3D widget. The only workaround I could think of, was to talk to all the element in the widget seperately, and then set their alpha value. This is impractical for a number of reasons. Is there a more elegant way to do this? I’d like to animate the 3D widget (fading in).
The second question is about mipmapping the 3D widget. It doesn’t seem to happen, currently? The only workaround I’ve found is to approach the pixel density the 3D Widget would be presented in on-screen, use that information to determine the resolution of the bitmaps I’m using in the Widget. There’s no power-of-two restriction on textures used in Widgets, so was able to get pretty close. However, as I’m developing for VR, there’s a big chance of the player moving in (or away) from the 3D widget, changing the distance between the camera and the 3D Widget, and then it all starts to look over-sharp or blurry again. More importantly, elements like text are still overly sharp as they’re not mipmapped either. Any solution?
Alright, so half of this question is resolved… I’m not sure why, but somehow the Color and Opacity node that I thought didn’t work, actually did work and is now setting the opacity of my 3D Widget. This is great I’m not sure why it didn’t work.
So what remains is the matter of 3D Widgets not mipmapping. Does anybody know a way to fix that?
I too have run into this issue recently. I found in another post that 3D umg widgets don’t use mipmapping because 3D widgets us a render target so texel density is constant and therefore mip mapping won’t work. This is really frustrating. I have several 3D UMG widgets in my scene and when you look at them from a distance the icons flash and flicker like crazy. I have been trying to work around this by manually (in blueprint) swapping textures based on distance and setting my UMG textures to not use any mipmaps. It works pretty well, but its not an automatic or very friendly process.
Does anyone from Epic have a workaround for 3D widgets not mipmapping. I’ve been fighting with this for awhile and my manual texture swapping just isn’t cutting it.
Here is a way that works but is not elegant.
Set the scale in render transform of widget according to distance to camera and set draw size of Widget Component to match the scale. For example, 0.5 scales with half of the original draw size.
For anyone using 3D widgets and want mipmaps.
I can be enabled in the c++ code, done for you by using this plugin:
Just keep in mind that its not cheap. I would recommend to only use it on widgets which rarely change. You might for example, while interacting with widgets disable mipmap generation and then reanable it once you stop and walk away. (Having two one with and one without mipmaps)
This solution is exactly what I was looking for, thank you so much.
Btw for anyone who looks to integrate this: there is nothing in the BPs that is relevant. Just make the derived custom WidgetComponent class and then you can basically follow the code on github for what they changed in their overridden class. Next simply reparent your WidgetComponent asset or use the derived class directly.
I did what the comment on github said and copied the overridden function’s body and added the mipmapping part. Worked like a charm!
Of course, and this was just mentoned by @Kettenotter, you will only want to update these RTTs if you really need to, otherwise you will waste performance and this is not a problem related to the solution itself but just generally if you do RTT this is what you should do. So turn “Manually Redraw” on and ensure that the component isnt accidentally painted more often than needed, or mipmaps will be costily generated each time. In my case I only update my markers once and then display them until their related game object seizes to exist so this is perfect!
