# BP_PreviewActor

File Location: Content\Core\Preview\BP_PreviewActor.uasset

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.

There is currently no way to disable BeginPlay, where as with Actor's you can with a ExposedOnSpawn boolean at the beginning of your BeginPlay logic. If you have any logic connected to your BeginPlay, you will need to find a way to disable it for the preview if there's any logic you don't want the preview to run.
If possible, avoid ChildActorComponent's. They are extremely prone to bugs and odd behaviour, and they don't seem to play well with networking.

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.

Even though the render scene component only see’s the preview actor itself and it only receives lighting from lighting channel 1 (Channel can be changed, but it’s recommended not to have it on 1 if your game has day/night cycles), BP_PreviewActor’s lighting can still affect another BP_PreviewActor.
Even while spawning them at a ridiculously long range of random locations, during my playtesting I still had this scenario happen.
To fix this, there’s a BP_PreviewActorCollider which you will spawn first, which will test for collision and adjust its location. Then you spawn BP_PreviewActor itself and set its location inside the collider.

This does mean though that you need to handle the collision responses for this. I recommend creating a new collision channel for BP_PreviewActor and BP_PreviewActorCollider.

# Camera management

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.

# Skeletal Meshes

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.

# Optimizations

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.

# Leader Pose

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.

# Common issues

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.