BP_PreviewActor
Last updated
Last updated
This is an actor that “should” perfectly duplicate the appearance of any specific actor. It does this by getting all components of the owning actor and then duplicating it and reconstructing the hierarchy structure to match the hierarchy structure of the owning actor. This includes any attached actors.
It currently supports SceneComponent, PrimitiveSceneComponent, ChildActorComponent, StaticMeshComponent and SkeletalMeshComponent.
It should be easy to add compatibility for more components, you’ll have to add them yourself, but the currently supported components should support the vast majority of components that have any sort of visual importance. You can optimize the construction or simply prevent this actor from duplicating a specific component by going into ComponentTags and adding “DONOTPREVIEW”. Though remember, since the actor is trying to reconstruct the hierarchy setup inside your original actor, any components attached to components that you labeled as “DONOTPREVIEW” will break.
This actor will render out a render target for you to use however you wish and this is how the item icon generation is handled.
The BP_PreviewActor will attempt to find the first component which has a socket called “PreviewCameraSocket” and attach the camera to that socket. If none is found, you’ll get an error message and the camera will stay attached to the PreviewActor’s root. Ideally, all your meshes should have this socket that you want to use this actor on. But to improve prototyping, I’ve added a few options to the item data asset:
Once you're far enough into production or willing to keep all meshes up to date with the socket, you should remove these four settings.
The actor supports auto-generated estimated camera distances, so you don’t have to debug every item to create a camera distance while in a prototyping phase. You can disable this by checking Use Custom Arm Length.
The default animations for skeletal meshes is retrieved via an interface function GetEquipmentData. This allows you to assign what animations the previewed skeletal mesh will play. For now it is only looping one animation, but an animation blueprint can be added to this struct if you wish.
It is also up to you to manage the render targets and when they should be released from the GPU. You can see an example in WBP_InventoryItem -> TryReleaseGeneratedIcon. I’ve tried to automate the release and creation for the widgets that come with this plugin, but if you are making a new widget and are new to render scene components, you must call ReleaseRenderTarget2D for the texture.
It is hard to create a perfectly automated system, so if you ever encounter an icon vanishing for an item, that means the render target was released improperly. During your prototyping phase, I recommend you just release and wipe the references when the player closes their inventory. Then when you’re in your optimization phase, you can try to optimize this. Do keep in mind that live captures can get very expensive, very quickly, since they are capturing a new image every frame.
You can limit it by enabling CaptureEveryFrame and limiting the TickInterval inside of SceneCaptureComponent2D.
I have these disabled by default, so if your actor isn’t animating, you need to enable CaptureEveryFrame, or if you're duplicating an item, you can go into its data asset and disable UseStaticCapture.
Any actor being fed into the preview actor should avoid skeletal meshes as much as possible, as they are approximately 50 TIMES more expensive than most other components to clone.
To bind two meshes together, you will have to setup their component tags in a specific way. The leader must contain some tag, in this example we'll use PlayerMesh.
Skeletal Meshes that now want to assign that mesh as their leader pose will then want to add a tag containing the word: LeaderPose: PlayerMesh.
Physics is typically the main culprit for the preview system breaking. If an item or components have physics on by default, they will instantly detach the moment they are initialized. Breaking the entire preview system. Physics will also cause issues with the equipment system, as that system relies on the attachment hierarchy being correct and detaching things due to physics will break it.
