Assuming that the Widget Component is a 3d Model or attached to camera and not added to viewport, and Motion Blur is turned on then you are still going to see the blur effect. In fact you will actually see more blur if it’s attached to the camera because it is considered stationary to the screen space and the Velocity Buffer in the camera space will be read a relative 0 for the object but will read velocity for all other items on the screen which when temporal AA reads the buffer will create an edge calculation around that object which motion blur will try to interpolate as the camera moves.
If the 2d Widget is added to the Viewport and not attached to a camera then you will not get an velocity buffer calculations for that object. A 3D object in a widget added to the viewport will because of its 3D nature still be calculated in the engine. We are considering adding the 3D object to a UI pass which would remove Motion Blur and other items, but that request is a ways off from being implemented.
Hey , great to hear from you and thank you very much for the detailed response!
The reason why I was trying to do this using a Widget Component in 3D space and not directly added to the viewport is in this particular instance, you are controlling a Turret from the Turrets POV and I have a Post Process Blendable that adds a very cool old school camera effect, while also altering things like Chromatic Aberration, Tone-Mapping + Color Correction, etc so that the HUD elements were affected by the material in the same way.
It’s possible I could come up with a Material Layer that applies the exact effect inside all the HUD elements that use the same Material but since some things in the blendable are driven by the Screen-Space Texture Coordinates, it may prove a little tricky so that it looks exactly the same.
Also if you look closely, there is some some jitter unfortunately with Temp AA with the element being attached as a Widget Component directly to the camera… (these are temp assets with the original HUD + Effects used)
This is from moving the camera quickly. As a note, that screenshot has MB disabled completely.
That’s great to hear you have that planned in the works, but unfortunate that it will be a while before devs can take advantage of that. I think it would be great if Epic were able to consider still adding an option to omit velocity data knowing that Temp AA will not work. I don’t think every developer is using Temp AA for that matter and I personally would still love to have that option knowing that’s a tradeoff. It gives me a lot more flexibility to do things and the freedom to make that choice. I understand UE heavily relies upon it and I think in many cases, Temp AA is great but clearly has its flaws as you can see in the image with the ghosting and jittery image. Just something I’d love you guys to consider.
I appreciate the response again and have a great day !
Since I ran out of characters , another final thing I’ll leave you with is in my other game, I use 3D Elements as HUD Items (think holographic UI in a cockpit). If Epic doesn’t allow developers like myself to forego Temp AA and an option to omit velocity data, then I’ll never be able to implement that with Motion-Blur ever enabled. I’ll always have to turn that off in that case and I’d rather not if possible unless Epic has another alternative. It would be a big help immensely and personally I’ve been waiting and hoping for this kind of option ever since 4.0.0 was released 2 years ago. Its a bummer I’m likely going to be waiting a much longer time and still, won’t have a fix for 3D Elements regardless. Also, there are a bunch of threads with members of the community very vocal about this issue and potential solution so if at the very least, I could still have that option to do that, knowing it break Temp AA, it would be amazing! However, this could have weird effects with the MB which might all together make it not worth it. But at the end of the day, I’d still love that option and it just gives your devs more flexibility. Temp AA is cool, but as a developer, I don’t want to have to be forced to used it. Thanks!
So I’ve been sitting here thinking about a solution that can make everyone happy. Please take a moment to see my previous comments if you haven’t but this is what I’ve come up with…
Option #1: 1st Cheapest Option While Keeping Temporal AA:
In the other game that has a cockpit and 3D Elements, I only notice this when I’m looking at those Actors with the transparent window behind. Maybe if there was an option to omit potentially the depth data and render these elements last, that could maybe help but you’d lose depth.
Option #2: 2nd Cheapest Option While Keeping Temporal AA:
Even though my cockpit has a glass window, if I had an option could make that transparent material render depth (which may exist), then the effect that is creating this issue at least in the cockpit, could work. Devs could put a transparent plane in front of their view. An option for this wouldn’t solve all instances though.
Option #3: Disable Temporal AA On-Demand + Motion-Blur Scale/Disable:
Epic could easily create a Tooltip in the Motion-Blur Scale Parameter that says, “WARNING: Temporal AA relies upon this data and setting this to a value that is not 0 could have unexpected results and is better suited with Temporal AA disabled. However, we wanted to provide this option to you and the choice for you to choose the tradeoff.” Maybe TempAA auto turns off (if enabled) when a PrimComp using MB Scale != 0 and is in Screen Space. Best Option IMHO.
Option #4: Keep Temporal AA + Added AAA UMG Features:
Maybe Epic creates a setting in the Project Settings that enables a secondary renderer for advanced UI. This could be forward or deferred but giving us options to enable how much quality we need and balance the perf costs. A UI not strapped to the view would potentially suffer from not knowing the depth from the default rendering pass unless it was shared between them for occulsion. I know you said something similar is planned.
I apologize for the delay getting back in touch with you. Thank you so much for the detailed breakdown and I added the information to a new feature request. I talked with our engineers and we are working on a 3D UI Pass which will allow for Temporal AA exclusion, but unfortunately this new feature may be a while off.
Thanks for getting back to me and no worries at all on the delay. I appreciate you guys taking in the feedback and I understand Epic has a ton of other priorities on the plate that are more important.
I don’t want to clutter up this thread but if I may ask one more question on-topic if you don’t mind. Is there a planned solution for Translucent Materials being able to render depth data for the deferred renderer and/or post process effects in the future and/or Translucent in Deferred Pass? (for instance to solve them not currently affecting MB or DOF)
Thanks again and man that was some awesome stuff regarding what you guys showed at GDC!!! Appreciate the feedback and response. Hope you and the team are doing well!
I see this feature was denied but that doesn’t change the problems we have with motion blur. I am un-hiding a bone (the magazine of a rifle) and the mag seems to fly into place for one frame. I have seen others with this problem as well. Turning off motion blur fixes it, but that makes the rest of the game look less good. It’s really an unpleasant situation.
Why was this denied? I think very few developers are concerned about temporal AA functionality – It doesn’t look good. There are many other features (forward rendering, shading modes, tessellation, et al) that disable specific engine functionality. I don’t understand the motivation behind not adding some of the more specific suggestions – particularly the option to disable velocity info on a per-object basis. If there were more vital features besides temporal AA being lost it might be a different story, choosing temporal AA as your hill to die on seems really ill-advised.
It’s a really strange choice, and I don’t understand why they’re picking Temporal AA as their hill to die on. On the flip-side, I think this would be a very easy engine change to implement in C++. If you aren’t already building the engine from source, do so, and start to familiarize yourself with how the base engine classes work. A lot of the time an insanely frustrating blueprint bug can be diagnosed in minutes just by looking at the C++ code of the Actor you’re interacting with.
Many base classes were developed by community members, or Epic Games staffers who have since left the company. They are often not designed ideally, rarely updated, and will sometimes break convention in ways that cause extremely unusual behavior. I just recently learned that calling SetThrottle on a WheeledVehicle from the Server will always fail. The class was hard coded to only update inputs from the client to the server, not the other way around. Most of these things are easy fixes though, in that case a child class and a function override were enough to solve the problem, at least on a functional level.
If you aren’t already familiar with C++ look into it, under the hood C++ and blueprint functions are the same thing. It will be invaluable to your future projects.
Hey everybody, I just wanted to post an alternative solution to your/our problem of 3D UI succumbing to motion blur. Unreal Engine 4 - [PUBG] 3D Live Widget - YouTube Right there they’ll teach you how to make a 3d Widget. I did it, and it works, and there’s no motion blur for those items. Hopefully this will work for you, but be aware, this solution is not as performant as simply strapping a 3d mesh to your camera. Happy creating!
