How-To: Showcase the Player's Character

Goal: display the player's actual character - equipped gear, materials, animation - on the loading screen. Your game describes the character (ICrimsonLoadingCharacterProvider) and registers it with the manager (UpdateCachedCharacterInfo); the plugin renders it. FCrimsonLoadingCharacterInfo is the struct that carries the description, and the plugin knows nothing about your equipment system.

The manager never searches the world for a provider. Registering is the only way character data reaches the loading screen, and nothing registered means the normal background is shown. A search would have to trust whichever object answered first - a half-initialized pawn, a front-end placeholder, any actor that happens to implement the interface - and a character the player does not recognize on their own loading screen is worse than no character at all.

Prerequisites

Quick Start is done. To actually see the result you also need How-To: Live Render Target Preview - this page produces the data, that page turns it into pixels in the widget.

1. Understand the data you will fill

FCrimsonLoadingCharacterInfo holds two arrays. MeshComponents describes the character itself as one entry per mesh slot; AdditionalActors describes separate showcase actors (mount, pet, prop). Exactly one mesh entry must be the leader: in Unreal, modular characters animate by having one skeletal mesh component drive the skeleton while every other piece calls SetLeaderPoseComponent to follow it - so only the leader entry needs an AnimInstanceClass.

`FCrimsonLoadingMeshComponent` field	Meaning
`SlotName`	Logical slot (`Body`, `Helm`, `Chest`, `Weapon_R`, ...) - the director maps it to a component
`Mesh`	The `USkeletalMesh`; null means the slot is empty and the director hides it
`Materials`	Per-element overrides; empty = mesh defaults
`AnimInstanceClass`	Anim Blueprint class - set on the leader only
`bIsLeader`	True on exactly one entry (the base body)
`RelativeTransform`	Offset from the stand root; identity for normally aligned meshes

FCrimsonLoadingActorEntry adds ActorTypeTag (e.g. CrimsonShowcase.Actor.Mount - your own tag convention), an optional AttachSocketName (set it to parent the actor to the leader mesh, leave None for free placement), plus the same material/anim fields. An entry carries exactly one of Mesh (USkeletalMesh) or StaticMesh (UStaticMesh) - the static path exists because equipment visuals (weapons, shields) are usually static meshes.

2. Describe the character on your pawn or a component

Implement ICrimsonLoadingCharacterProvider on whichever object owns the authoritative appearance data. An equipment or appearance component is usually the right home, because it already knows what is equipped. Implementing it does not make the character appear - the manager never searches for implementors. Step 4 registers the result, and that is what puts it on screen.

In your Pawn (or an ActorComponent Blueprint): Class Settings -> Details -> Interfaces -> Add -> Crimson Loading Character Provider. In My Blueprint -> Interfaces, double-click Get Loading Character Info. Build Out Info with Make Crimson Loading Character Info fed by a Make Array of Make Crimson Loading Mesh Component nodes - the Body entry with Is Leader ticked and an Anim Instance Class set - and set the Return Node's Return Value to true.

All struct pins are writable

Every field of the three showcase structs is Blueprint-writable, so Make / Set Members in Struct nodes expose all pins. Build the array with one Make node per slot; leave Mesh unconnected (null) for empty slots.

Verify

Call Get Cached Showcase Roster (pure node / GetCachedShowcaseRoster()) after your registration has run and the screen has opened: entry 0 is your character, and its MeshComponents array holds your entries with exactly one leader. An empty result means nothing registered - check that your registration ran, and that it produced a valid description (one entry with bIsLeader and a mesh).

3. Let the plugin render it

There is nothing to build here. Once a character is registered and live preview is on, UCrimsonShowcaseSubsystem creates a pocket world for the duration of the loading screen, puts an ACrimsonShowcaseStage in it, and builds your description: one scene root per character, the leader mesh under it driving the pose, every overlay following through SetLeaderPoseComponent, and one component per additional-actor entry attached to the leader's socket when one is named. It then frames the capture and writes the render target at 30 frames per second.

What you want to change	Where
The set - floor, lights, sky, props, post process	Author a stage level (How-To: Author a Stage Level)
Where each character stands	`ACrimsonShowcaseSlot` actors in that level
The shot	`ACrimsonShowcaseCamera` actors in that level, or the stage's own framing properties
Lighting rig, framing and formation defaults	A Blueprint subclass of `ACrimsonShowcaseStage`, set as Showcase Stage Class
Everything - your own presentation entirely	`ICrimsonLoadingCinematicInterface` (How-To: Live Render Target Preview step 5)

Use an anim Blueprint that works standalone

The showcase stand has no pawn owner, no controller and no movement component. A gameplay anim Blueprint that reads any of those will misbehave there, usually as a T-pose or a frozen idle. Put a self-contained idle or pose anim Blueprint in the leader entry's AnimInstanceClass.

Verify

With a character registered, force a screen with CrimsonLoadingScreen.AlwaysShow 1: the log prints Showcase: pocket world active with 1 character(s) on the built-in studio stage. and the widget shows the character turning on the turntable.

4. Register the character with the manager

This is the step that makes the showcase run. Build the description from step 2 and hand it to Update Cached Character Info. The registration lives on the game instance, so it survives every travel - which is what makes loads with no reachable pawn work at all, whether the pawn was already torn down by the travel or has not spawned yet on a joining client.

When to register: whenever the local player's appearance becomes final or changes - after a save restore, on an equipment change, after character customization. Register only for the locally controlled player: on a listen server every character runs the same code, so a registrant that does not check IsLocalPlayerController() will put NPCs and remote players into the host's loading screen. An invalid description is ignored, so a premature call is harmless and you are free to try as often as you like.

Registering never rebuilds a screen that is already up: the primary is the snapshot that screen started with, and a pawn arriving in the destination map re-registers repeatedly as its equipment replicates in. Nothing registered means the widget simply keeps its normal background - a missing showcase never breaks the screen.

Wherever your look becomes final or changes (an equipment-changed event, after character customization, after a save restore): build the same struct as step 2, then Get CrimsonLoadingScreenManager -> Update Cached Character Info (Character Info = the struct). Use Clear Cached Character Info when the registered look stops being the player's - a character switch, or leaving a session.

Verify

Register when the appearance is final, not merely when the pawn finishes initializing. A pawn that has just spawned is still wearing whatever its default data dressed it in - if the player's saved gear and appearance have not been applied yet, registering there shows them a character that is not theirs. Waiting costs nothing: an unregistered load falls back to the normal loading screen, which is the correct outcome when the real character is not known.

How-To: Showcase the Player's Character

1. Understand the data you will fill

2. Describe the character on your pawn or a component

3. Let the plugin render it

4. Register the character with the manager

See also