In a number of places we have had the desire to have various primitives (Niagara systems, Widget Components, Static Mesh) that form an actor, to face the camera or rotate along Z axis so its facing the camera in the X/Y. Obviously we can do that by adjusting the actor, but this comes with the issue that it doesn’t work for our scene captures.
Currently to have it work in the scene captures we are using WPO materials but those come with a number of problems and they make the material unreusable.
I was looking at creating new types of PrimitiveComponent that can do this, using GetDynamicMeshElementson an SceneProxy to do the rotation there, but that requires creating multiple different component and proxies for each type of Component we want this functionality on. Just wondering if something that can do this already existed or if there is a better method you can think of
Hey there! With Niagara systems at least you should be able to set the Sprite Facing Mode to do what you want and that usually suffices to get camera-facing behavior in both main pass and scene captures.
As far as WPO and reusability, would it suffice to put your camera-facing WPO functionality into a material function that you can drop into each of your base materials where this functionality is needed? This way all you have to do to enable the functionality is add the function into the WPO stack of each material, and you can put all the relevant parameters into that material function so any time you need to change it you can make the changes in one place. You’d even be reasonable to put a static switch parameter in that material function so you could selectively enable or disable it as needed.
For WidgetComponents, you could actually add this to the material as well! I’d recommend duplicating the base Widget3DPassThrough material and adding in your WPO material function to it so you get all the parameters that the WidgetComponent expects to exist. Although if you’re using WidgetInteraction components as well you have to make sure that the component itself is rotated so its collision works correctly.
Another thing I wanted to flag is that somewhat recently we added “Visible In Scene Capture Only” and “Hidden In Scene Capture” flags to UPrimitiveComponent, so you could have separate components facing whichever cameras you need without having to make whole new scene proxies. Downside being you’d still be doubling up your component count which could have some negative impacts on performance, if that’s important to you.
Thoughts? Is there something else I’m missing about the WPO approach that limits the reusability of materials?
Hi thanks for your help.
There are a couple of issues - one is that the WPO method has not interacted favourably with TAA. Another is to do with primitive bounds - we have had to set manual bounds because thin screens (like WidgetComponents) can be out of the Frustum when un-rotated but in the frustum when rotated.
Also the Material method requires multiple parameters to be passed to the material to handle the pivot point and rotation axes so it does require more user setup - that could probably be moved into a base Actor that handles this but would like to make it as drag and drop as possible because its something we do need.
However it probably would be a good idea to group this stuff into a Material Functions so we will start with that at least and look into other methods.
We have used “Visible In Scene Capture Only” and “Hidden In Scene Capture” in some instances but there can in some cases be 2 Scene captures so we also would need to organize what is visible in each capture as well as those instances need to know all the capture parameters ahead of time.
My answer for TSR is going to depend on your engine version, since we’ve got some options that have come online more recently. If the material is translucent, it should have “Output Depth and Velocity” set on its material. You can explicitly set the Output Velocities Due to Vertex Deformation setting in your project settings to “On”. There’s also a “World Position Offset Writes Velocity” setting on primitives, but I believe that’s on by default.
As for primitive bounds, I give you my blessing to set and scale those as needed for your effects.
As far as maintainability and ease of use, you’re probably right that moving a lot of the setup into an actor is going to be the right way to go. And/or setting up an editor utility widget to help users with the setup process. I wouldn’t suggest asking users to manually set all the right values on each instance where this functionality is used.
For meshes that are visible in multiple scene captures there’s two parts:
- You’ll likely want some kind of manager class that is handling each scene capture’s Show/Hidden actor lists. There’s not a “Scene Capture Channel” concept in the engine.
- For parameters, I think it depends on what kind of parameters need to be set to get the effect working right. Could you go deeper on that?