# BP\_PreviewActor

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 <mark style="color:yellow;">**SceneComponent**</mark>, <mark style="color:yellow;">**PrimitiveSceneComponent**</mark>, <mark style="color:yellow;">**ChildActorComponent**</mark>, <mark style="color:yellow;">**StaticMeshComponent**</mark> and <mark style="color:yellow;">**SkeletalMeshComponent**</mark>.

<details>

<summary>Notes regarding <mark style="color:yellow;"><strong>ChildActorComponent</strong></mark>'s</summary>



1. 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.
2. If possible, avoid <mark style="color:yellow;">**ChildActorComponent**</mark>'s. They are extremely prone to bugs and odd behaviour, and they don't seem to play well with networking.

</details>

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 <mark style="color:purple;">**ComponentTags**</mark> 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.

***

## Camera management

The <mark style="color:yellow;">**BP\_PreviewActor**</mark> 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:&#x20;

<figure><img src="https://3072220171-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FD9UVtAB4Tl9vRkQgcS0X%2Fuploads%2FB5NlZbdOdVWNVHhXSZh8%2FPreviewActorAdjustments.png?alt=media&#x26;token=b2d92a44-b4ca-4f69-b96e-35d5b46cef97" alt=""><figcaption></figcaption></figure>



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 <mark style="color:purple;">**Use Custom Arm Length**</mark>.

***

## Skeletal Meshes

The default animations for skeletal meshes is retrieved via an interface function <mark style="color:red;">**GetEquipmentData**</mark>. 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 <mark style="color:yellow;">**WBP\_InventoryItem**</mark> -> <mark style="color:red;">**TryReleaseGeneratedIcon**</mark>. 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.

<figure><img src="https://3072220171-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FD9UVtAB4Tl9vRkQgcS0X%2Fuploads%2FttC9mWcnqjymEmPfWwFG%2FProfiler_CloneSkeletalMesh.png?alt=media&#x26;token=b7759a5f-c996-4d62-9048-75bd31aff423" alt=""><figcaption></figcaption></figure>

***

## 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`.&#x20;

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.
