Starter Project 2: Bear Necessities! 🎩

Fluf World is abuzz with excitement for the upcoming fashion show! Our friend Party Bear has been invited, but there’s a catch—he needs to swap outfits on quickly and seamlessly to keep up with the show’s rapid costume changes!

Our task is to build a modular wardrobe system that allows Party Bear to effortlessly transition between different looks. Each accessory within an outfit will be it’s own blueprint instance and we will learn how we can use nested blueprints to multiple 3D objects working together.

By the end of this project, you’ll have a flexible dressing system for a Party Bear—one that can be easily expanded if he decides to pick up a samurai armor or pirate ensemble next!

So let’s dive in and make sure Party Bear has everything he needs—because when it comes to bear necessities, a well-stocked wardrobe is at the top of the list!

​

Getting Started

​

Required Assets

Before we begin building our UBF project, you’ll need a few assets to work with.

For this tutorial, we’ll be using a range of 3D models and textures for both the Party Bear and his wardrobe. You can download the starter asset pack from the Asset Creator Pack provided to you. Get in touch with customersuccess@futureverse.com to gain access.

Additionally, ensure you have installed compatible versions of UBF Studio and UBF Previewer. For installation instructions, see the Installation and Setup sections for the respective apps:

• UBF Studio - Installation and Setup
• UBF Previewer - Installation and Setup

​

Creating a UBF Project

Let’s again begin by launching UBF Studio and creating a brand new project. Select ‘Create Project’ in the welcome screen, then navigate to a suitable location on your drive and create a new folder to store your project. You can name it whatever you prefer, but for this tutorial, we’ll use “UBF - Bear Necessities.”

Once the folder is created, navigate into it and select “Create Project” to initialize your UBF workspace.

​

Project Setup & Importing Assets

In Bear Necessities, we’ll be dealing with a broader range of assets than in our previous starter project. To keep everything neat and easy to navigate, let’s begin by organizing our workspace right from the start.

Firstly, download and unzip the Bear Necessities Starter Pack into your newly created project folder. This ensures that all the relevant 3D models and textures are placed directly within your UBF Project.

After extracting, return to UBF Studio and open or refresh your project. You should now see a folder hierarchy resembling the one below:

- Bear
  └─ Resources

- Accessories
  └─ Head
     └─ PartyHat
        └─ Resources
     └─ Beanie
        └─ Resources
  └─ Eyes
     └─ Goggles
        └─ Resources
     └─ Aviators
        └─ Resources
  └─ Torso
     └─ DenimJacket
        └─ Resources
     └─ SpaceSuit
        └─ Resources

Inside each Resources folder, you’ll find the relevant 3D assets and textures specific to that accessory or body part.

With our foundation in place, we’re ready to move on to the fun part—setting up our Party Bear blueprint and preparing him for his outfit transformations!

​

Build-A-Bear—Laying the Foundations

It’s time to bring our Party Bear to life! Before we start on any accessories, we first need to establish a solid foundation. In this section, we’ll walk through the process of creating and configuring our base bear blueprint. We’ll break this into three key stages: first, prepping our blueprint and wiring up some reusable logic; second, spawning our bear and giving him a glorious fur coat; and finally, bringing him to life with a pair of expressive, customizable eyes.

​

Bear Bones—Creating Our Blueprint Structure

1. Creating the Bear Blueprint

Navigate to the Bear folder in the Project Explorer then right-click and select Create New Blueprint. Name the blueprint ‘BP_Bear’ (prefixing with ‘BP’ helps us quickly identify it as a blueprint and follows standard practice).

With our blueprint created, it’s time to start piecing together the logic—one node at a time.

2. Creating a Scene Node

As we learnt in the first exercise, a Scene Node is a container, effectively the ‘root’ of our bear—it ensures that every part of our character (body, outfits, accessories) stays grouped together.

Start by adding a “Create Scene Node” node to the blueprint and connecting it’s execution from the build node. Inside the node’s settings, assign it a name—we’ll simply call it “Bear”.

At this point, our blueprint creates a container in the scene, but we’ll need to reference it multiple times throughout our blueprint. Instead of constantly dragging wires everywhere, we can make our blueprint cleaner by storing the Scene Node inside a variable.

3. Storing the Scene Node in a Blueprint Variable

Blueprint Variables allow us to store values and retrieve them anywhere in our blueprint, just like variables in traditional programming.

To create a variable, navigate to the Blueprint Inspector (on the left panel of the editor) and select the Variables menu.

Clicking the ”+ Add a Variable” button will open up a popup allowing you to define your variable:

• Set the Variable Type to SceneNode.
• Give it any name you like, we will choose BearSceneNode.

Click Create—you should now see it appear in your Variables list.

Now that we’ve created our BearSceneNode variable, we need to store the output of our Scene Node inside it.

Back in the viewport, open the Create Node menu then search for and spawn a Set BearSceneNode—this is how we assign a value to our variable.

Drag the output pin of the Create Scene Node into the input pin of Set BearSceneNode and link the execution pin from Create Scene Node to Set BearSceneNode—ensuring the variable gets assigned immediately after the Scene Node is created.

We can now access the contents of this variable anywhere in our blueprint without needing to drag wires back and forth.

If you need to retrieve the value of BearSceneNode later in your blueprint, you can simply:

• Drag it directly from the Variables Menu in the Blueprint Inspector into the viewport.
• Alternatively, you can open the Create Node menu and search for Get BearSceneNode.

4. Leveraging Mesh Configs

A MeshConfig is a collection of engine-specific configuration data that determines how a mesh is loaded at runtime. It can include settings such as axis configurations (defining which axis is considered forward upon import), skeleton overrides (specifying which skeleton to use for rigging or animations), and other parameters that standardize how a mesh is handled within a given engine context.

It is prudent to expose a MeshConfig input a blueprint for scenarios where a parent blueprint might want to specify its own mesh-loading parameters. For instance, a vehicle blueprint that spawns Party Bear as its driver could pass in a tailored MeshConfig, ensuring consistent orientation and skeletal setups across the entire system.

While our current example doesn’t involve any parent blueprint calling the Bear blueprint (since it’s intended to be a top-level entity), the open and flexible nature of UBF means there could be a higher blueprint at some point down the line. By exposing a MeshConfig input here, we adhere to best practices and keep our blueprint extensible for potential future scenarios.

To set up this input, navigate to the Blueprint Inputs panel in the Inspector and create a new input of type MeshConfig, naming it something like InjectedMeshConfig. Once this input is created, we can incorporate a simple check in our blueprint’s execution flow to see whether the caller has provided a MeshConfig.

Now that our InjectedMeshConfig input is in place, we need to handle the scenario where it is not provided (i.e., it’s null). To accomplish this, we’ll introduce a Branch node that checks whether a valid MeshConfig has been passed into the blueprint.

First, spawn a Branch node in your graph, connecting it to the next step in your blueprint’s flow. The Branch node evaluates a boolean condition, then routes the execution to True or False pins based on the result.

Next, we can retrieve the value of the InjectedMeshConfig input in the same way we do for variables and feed it’s value into an IsNull node. Connect the IsNull node’s bool output to the Condition input on the Branch node.

5. Locking in the MeshConfig

Now that our Branch node splits the flow based on whether InjectedMeshConfig is null, we can implement the logic for each outcome. If InjectedMeshConfig is null (true path), we want to create a new MeshConfig at this stage. To do this, we’ll use a CreateMeshConfig node.

This node requires two inputs:

1. A Mesh Resource, which serves as the basis for generating the default configuration. We can set this to our PB_Body_Standard mesh.
2. A config override key, used to retrieve a specialized configuration in the executing experience. This key plays a crucial role in injecting gameplay-specific functionality into a UBF-spawned character.

Projects using UBF interpreters can define multiple mesh config overrides, which are preconfigured settings that include specific skeletons, rigs, and additional gameplay elements—such as predefined sockets for equipping weapons or attachment points for accessories.

When using the CreateMeshConfig node, the provided key attempts to retrieve an existing override configuration from the running experience. If a matching override is found, it is applied automatically; otherwise, a new MeshConfig is generated based on the specified resource.

Since the primary difference between the two paths (true or false) is which MeshConfig we end up using, we can simplify our blueprint by storing the final MeshConfig in a single variable - simply called MeshConfig. If the condition is true (injected config was null), we create the MeshConfig and assign it to this variable. If it’s false (injected config was not null), we assign the InjectedMeshConfig to the same variable.

​

Fur Real—Spawning the Body and Applying a Custom Material

1. Creating a Body Blueprint

While we could continue adding all the logic for spawning and customization directly into our main bear blueprint, it’s important to remember that this blueprint will soon be doing a lot—handling foundational setup, orchestrating accessories, and more. To keep things clean, modular, and easy to maintain, we’re going to offload the responsibility of actually spawning the bear’s body into its own dedicated blueprint. This approach allows our main blueprint to serve as a high-level orchestrator, delegating specific tasks to more focused sub-blueprints.

So, let’s head back into the Bear folder, right-click, and create a new blueprint. We’ll name it: BP_SpawnBody. This blueprint will be responsible for spawning and configuring our bear’s body mesh and applying the stylized fur material that brings it to life.

2. Spawning the Body Mesh

With our setup complete, it’s time to bring the Party Bear’s body into the world. As we’ve done previously, we’ll use the SpawnMesh node to make this happen. This node requires three key inputs: a mesh resource, a parent SceneNode, and a MeshConfig.

For the mesh resource, we’ll directly reference the PB_Body_Standard.glb file, as the bear’s body mesh will remain consistent across all use cases and doesn’t require runtime variability.

Now, regarding the Parent (SceneNode) and Config (MeshConfig) inputs—while we’ve already created these in our main Bear blueprint, they don’t exist within this new BP_SpawnFur blueprint. Since sub-blueprints do not have access to their parent’s internal variables, we need to explicitly define them as inputs to our BP_SpawnBody blueprint so they can be passed down when executed.

To do this, navigate to the Blueprint Inputs panel of BP_SpawnFur and create the following:

• An input of type SceneNode, named Bear-SceneNode
• An input of type MeshConfig, named Bear-MeshConfig

Once added, you can drag these inputs into the viewport and wire them directly into the corresponding pins on the SpawnMesh node.

With our body-spawning blueprint now ready to receive instructions, let’s jump back to the main Bear blueprint and make use of it. We’ll use the ExecuteBlueprint2 node to run our newly created BP_SpawnBody. Once added, select BP_SpawnBody from the dropdown in the node, and you’ll see the input fields update to match the ones we defined earlier—automatically exposing the Bear-SceneNode and Bear-MeshConfig inputs.

Now wire up the execution flow so that both paths from the earlier Branch node lead into this ExecuteBlueprint2 call. This ensures that regardless of whether we created a new MeshConfig or used an injected one, we always proceed to spawn the bear’s body.

Lastly, connect the two variables we previously created—BearSceneNode and MeshConfig—into the corresponding inputs on the ExecuteBlueprint2 node.

With everything in place, it’s time to preview our progress. Open the UBF Previewer, switch to Live Link Mode, and hit the Preview button in the top right of the blueprint viewport. If everything has gone according to plan, you should now see the first glimpse of your Party Bear—standing proud and ready for customization!

3. Applying the Fur Material

Now that our bear is showing up in the Previewer, it’s time to give him a dose of realism—fur! At the moment, our friend is looking a bit plain, so we’ll use the Apply Material node to provide a warm, fuzzy coat.

The Apply Material node takes three parameters: Index (we’ll set this to 0, since our bear’s body only has one material slot), Renderer, and Material (which we’ll define shortly).

For the Renderer input, we simply take the first element in Renderers array returned from the Spawn Mesh node. Using the First node, allows us to yield the first (and in our case, only) mesh renderer, which we can then feed into the Apply Material node.

Now we’re ready to create the actual fur material. Spawn a MakeFurMaterial node to define how the fur looks and we will work through customizing the required parameters as follows:

1. Set the render mode to UseDiffuse, since we want to apply a diffuse texture to color the fur.
2. To keep things flexible and allow customization in future instances, let’s create a Blueprint Input of type Resource<Texture> for the diffuse texture. Give your new input a name and a default texture—we will use the name Fur-DiffuseTextureand give it the default value T_PB_Fur_RaspberryRipple_1024.png.
3. This diffuse / base color texture needs to have sRGB enabled, we can ensure this by leveraging a Set Texture Settings node. This node can take in the input texture, enable sRGB and output the texture with the correct settings applied— then we can connect this into the diffuse texture slot on our material node.

4. Next, we’ll add normal, ORM, height, and ID maps to enhance realism. For each of these textures, you can use Set Texture Settings again to ensure sRGB is disabled, then feed them into the corresponding inputs on the MakeFurMaterial node. We do not expect instances to change these textures so we can reference them directly in our set texture settings. Set the different texture inputs as follows:
   1. Normal Tex: T_PB_Body_Standard_LOD0_NR_1024
   2. ORM: T_PB_Body_Standard_LOD0_ORM_1024
   3. Height Map: T_PB_Body_Standard_LOD0_H_1024
   4. ID Map: T_PB_Body_Standard_LOD0_CSTM_1024
5. Lastly, let’s adjust some of the primitive parameters to finish off the material’s appearance:
   1. Set Occlusion to 1.
   2. Set Roughness to 0.5.
   3. Set Metallic to 0.5.
   4. Ensure Use Normal Map is enabled.
   5. Ensure Use ORM is enabled.

With these configurations in place and the Material output connected to the Material input on the Apply Material node, we should have a blueprint that resembles something like the one below:

Once again, open the Previewer, switch to Live Connection Mode, and press Preview in your blueprint editor. You should now see a fully furred-up Bear, ready to show off his new coat.

For completeness, let’s add one final touch. Currently, the diffuse texture used for the fur is exposed as an input in the BP_SpawnBody blueprint, allowing it to be overridden by a parent blueprint or defaulting to the value we set earlier. However, our main Bear blueprint—the one from which we’ll eventually create instances—doesn’t yet expose this input itself. To ensure we can control the fur texture (and thus the color) from our instances later on, let’s add a matching input to the Bear blueprint with the same default value. Once added, simply pass that input down into the BP_SpawnBody execution, wiring it to the corresponding input to maintain consistency.

​

Eye on the Prize — Adding Customizable Eyes

1. Creating the Spawn Eye Blueprint

Continuing our modular approach, we’ll now focus on giving our Party Bear a proper set of expressive eyes. Since both eyes share the same underlying logic—only differing in which model and texture they use—we’ll create a reusable blueprint called BP_SpawnEye. This blueprint will handle all the logic for spawning and configuring a single eye. Then, within our BP_SpawnBody blueprint, we’ll simply call BP_SpawnEye twice—once for each eye—passing in the appropriate mesh and texture for the left and right sides respectively.

Let’s go ahead and create that new blueprint now.

2. Spawning the Eye Mesh

Just like before, we’ll be using the SpawnMesh node to bring our eyes into the scene. As a quick refresher, this node requires three key inputs: a Mesh Resource, a Parent SceneNode, and a MeshConfig.

Unlike our previous body blueprint where the mesh resource was fixed, the eye blueprint will need all three values to be passed in from the outside. This ensures it remains flexible and reusable—allowing us to use the same blueprint for both the left and right eye, with different inputs for each.

Let’s go ahead and define the inputs in our blueprint now:

• A Resource<Mesh> input with name Eye-MeshResource
• A SceneNode input with name Bear-SceneNode
• A MeshConfig input with name Bear-MeshConfig

Once you’ve created these inputs in the Blueprint Inputs section of the Inspector, drag them into the graph and wire them up to the corresponding inputs on your SpawnMesh node.

If we return to our BP_SpawnBody blueprint, we can now follow on from spawning the bear’s body and applying its fur by executing our newly created BP_SpawnEye blueprint—twice, once for each eye. Just like before, we’ll use the ExecuteBlueprint2 node to call the eye blueprint and pass in the necessary inputs.

For both calls, we’ll connect the existing Bear-SceneNode and Bear-MeshConfig variables to their respective inputs on the node. The only thing that changes between the two executions is the mesh resource we provide to the EyeResource input.

• For the left eye, use the resource: SK_PB_Standard_EyeLeft_LOD0
• For the right eye, use the resource: SK_PB_Standard_EyeRight_LOD0

Once both executions are wired up, let’s verify things are working as expected. Open the UBF Previewer, switch to Live Link mode, and hit the Preview button in the top right of your Bear’s main blueprint viewport. You should now see your Party Bear staring back at you—with both eyes in place! They’ll still look a little plain for now, but we’ll fix that next by giving them a proper material.

3. Applying the Eye Material

Now it’s time to give those eyes a bit of personality! Inside our BP_SpawnEye blueprint, let’s continue from where we left off after spawning the mesh by applying a material—just as we usually do—using the Apply Material node.

As always, we can leave the Index input of the Apply Material node at 0 (targeting the first material slot). For the Renderer input, we’ll use the first (and only) renderer returned from the SpawnMesh outputs. To retrieve it, we can use the First node from the array.

Next, let’s create the material itself. Since we’re aiming for a clean and simple look, we’ll use a standard PBR material by spawning a MakePBRMaterial node. Follow up by spawning a SetTextureSettings node to manage our diffuse texture. Set the sRGB flag to true, then connect the texture output to the Diffuse Texture input of the Make PBR Material node.

Now for the actual texture resource—we want to make this customizable, so let’s create an input in our graph of type Resource<Texture> and name it Eye-DiffuseTexture. We can give this a default value for testing, feel free to use any of the included eye BC textures:

• T_PB_Eyes_Green_BC_1024
• T_PB_Eyes_Purple_BC_1024
• T_PB_Eyes_Red_BC_1024

Drag this input into our blueprint and connect it to the SetTextureSettings node we just created.

Next, let’s take the same approach for the Normal and ORM textures. Spawn a SetTextureSettings node for each, setting sRGB to false this time. Since these textures won’t change, we can directly reference them. The textures to use are included in your resources and map to:

• Normal: T_PB_Eyes_NR_1024
• ORM: T_PB_Eyes_ORM_16

Last but not least, let’s ensure that all the properties are correctly configured on the MakePBRMaterial node:

• RenderMode: UseDiffuse
• Opacity: 1
• Occlusion: 1
• Roughness: 0.5
• Metallic: 0.5
• Use Normal Map: true
• Use ORM: true

You should now have a PBR material that looks something like:

Connect your material to the Apply Material node, and voila! You’re ready to preview. Head back to the Previewer, switch to Live Link mode, and hit the Preview button. Now you should see your Party Bear staring back at you with some expressive, vibrant eyes—full of character and charm!

4. Making the Eyes Customizable

Now that we’ve got the eyes sorted, there’s just one more touch we need to address. Currently, the Eye-DiffuseTexture is an input to the BP_SpawnEye blueprint, which means it can be set within the BP_SpawnBody blueprint that calls it. However, to make customization even more accessible, we want to expose this input at the top level in our BP_Bear blueprint.

To do this, we’ll add a new input to the BP_SpawnBody blueprint and link it to the existing input when executing BP_SpawnEye.

Then, we’ll repeat the same process in the BP_Bear blueprint—adding a new input and connecting it to the ExecuteBlueprint2 node for BP_SpawnBody.

Note we could even have two inputs would we want to customize each eye color independently but to keep it simple, we will assume both eyes share a single BC texture.

What we are doing here is effectively “drilling down” the parameter, allowing instance creators to define the customization of the bear—both the fur color and the eye color—at the top level, making it straightforward and intuitive to create unique, personalized Party Bears!

​

All Eyes on Me — Binding the Eyes to the Body

With the eye meshes now spawned and in place, the next step is to ensure they remain properly aligned and animated with the character’s body. Without this connection, the eyes would stay static whenever the character moves.

To handle this, we need to bind the eye meshes to the body’s skeleton—but only if a valid reference to that skeleton is available. Start by adding a new input to your blueprint, naming it something like In-BodySkeleton, and setting its type to MeshRenderer.

After spawning the eye mesh and applying a material, insert a Branch node. Use the getter for your In-BodySkeleton input and connect it to an IsNull node. The output of that node will control the condition of your branch, determining whether or not we proceed with binding.

Now, on the FALSE path (meaning the skeleton is valid), drop in a Bind Meshes node. This is what links the eyes to the body’s rig so they animate together naturally.

The Bind Meshes node expects two inputs:

• Meshes: An array of mesh renderers to bind. You’ll connect this directly from the output of the node that spawns your eye meshes.

• Skeleton: This is the source mesh renderer—the rig—that the other meshes will follow. Simply drag the ‘In-Skeleton’ blueprint input into this input.

With this setup complete, the eyes will dynamically move alongside the rest of the body, bringing more life to your character.

Later, we’ll make sure to pass in the bear’s skeleton into this blueprint from the BP_SpawnBody blueprint. For now, the Spawn Eye blueprint setup is complete.

​

Bear-y Unique — Crafting Custom Bear Instances

With that, our Party Bear’s base blueprint is complete, and we now have the ability to render a Party Bear. This base bear blueprint acts as the template or foundational recipe—it defines how to render any bear, while allowing us to configure the colors of the eyes and fur through its inputs. Essentially, it’s like having a flexible character template that can be customized at runtime.

Instead of duplicating this entire blueprint for every variation we might want (which would be cumbersome and prone to errors), we can leverage blueprint instances. Think of a blueprint instance as a customized version of the base blueprint—a way to define specific configurations without modifying the original. For example, one instance might render a bear with blue fur and green eyes, while another could render a bear with red fur and yellow eyes—all while keeping the underlying logic of the base blueprint intact. This approach makes it incredibly efficient and easy to manage multiple variations without duplicating code.

To create some instances, navigate to our main BP_Bear blueprint and, in the inspector panel on the left, select the Instances menu. From here, select Create Blueprint Instance. This will immediately generate an instance of the blueprint, allowing you to customize any of the exposed inputs. In our case, these inputs are the Fur and Eye Diffuse textures. Change these values to whatever you like, and then save your instance in the Bear folder with a suitable name—we’ll use BPI_SimpleBear (using BPI to denote a blueprint instance).

This method allows you to create multiple bears that differ only in appearance, simply by creating additional instances. We’ll explore this concept further when we add accessories, but for now, feel free to preview your newly created blueprint instance. In the previewer, you should see your customized bear come to life, showcasing just how reusable this approach is!

​

Thread by Thread — Building Our Accessory Arsenal

Now that our Party Bear is fully formed and sporting a great look, it’s time to take his style to the next level with clothing and accessories! In this section, we’ll focus on creating and managing these accessory blueprints—ranging from hats to jackets, and eyewear.

​

Creating the Base Accessory Blueprint

To maintain the same modular philosophy we used for the bear’s body and eyes, we’ll start by creating a base accessory blueprint that can handle spawning any generic accessory. Each unique hat, jacket, or pair of glasses will then become an instance of this blueprint—much like the approach we used for the bear. You will notice some similarities to sections of the main Bear blueprint we set up initially, the reason for this is that it allows us to set up our accessories in such a way that they remain fully independent, allowing them to be viewed and configured on their own, while also making it easy to attach them to a parent (like our Party Bear).

1. Setting Up the Parent Scene Node

Navigate to your Accessories folder and create a new blueprint—let’s call it BP_Accessory. This blueprint will resemble much of the logic from the main bear blueprint but focused on accessories instead of a full character.

In the Blueprint Inputs panel, add a new input of type SceneNode, naming it something like In-Parent. This input will determine where in the scene the accessory is attached; if a valid scene node is passed in, the accessory will become a child of that node. If not, it remains independent.

Inside the blueprint, place a CreateSceneNode node. Drag In-Parent from your variables into the graph and connect it to the Parent pin of CreateSceneNode. This ensures that, if provided, the accessory’s newly created scene node will be a child of the passed-in parent. For the Name, feel free to use something like “Accessory”.

Next, add a private variable of type SceneNode—call it Parent to differentiate it from In-Parent. Spawn a Set Parent node, linking it to the output of CreateSceneNode. This variable will be used later to anchor any meshes we spawn.

2. Handling the MeshConfig

Add another input of type MeshConfig—we’ll call it In-MeshConfig. This will allow the accessory to either use an existing config provided by a parent blueprint or create its own if nothing is passed.

Drag In-MeshConfig into the graph and feed it into an IsNull node, then add a Branch node. Wire the boolean output of IsNull to the Condition input of the Branch, splitting the logic based on whether a valid MeshConfig has been provided.

With this branch node in place we can split the execution into two flows:

• True Path (Null): If In-MeshConfig is null, we’ll create a new MeshConfig. First, add an input of type Resource<Mesh>—call it In-Mesh—so that we can specify which mesh this accessory will use. Next, spawn a CreateMeshConfig node and connect In-Mesh to its Resource pin.
• False Path (Not Null): If In-MeshConfig is valid, we’ll just reuse it.

Add a private variable of type MeshConfig—let’s call it MeshConfig—and place Set MeshConfig nodes in each path of the Branch. In the true path, set it to the output of CreateMeshConfig, and in the false path, set it to In-MeshConfig. This way, the rest of the blueprint can access a “final” MeshConfig variable, regardless of whether we created it or inherited it.

3. Spawning the Mesh(es)

Now that we’ve laid the groundwork with scene node setup and mesh configuration, it’s time to bring the accessory to life by spawning the mesh itself.

To do this, drop in a SpawnMesh node into your blueprint and connect both execution paths from the earlier Branch node into its execution input. This ensures that no matter which path was taken—whether the mesh config was passed in or generated—we’ll move forward with spawning the accessory.

The SpawnMesh node requires three inputs, all of which we’ve already prepared:

• For the Resource input, connect your In-Mesh input.
• For the Parent input, hook up the Parent variable, which holds the scene node we created earlier.
• For the Config input, connect the MeshConfig variable, which now holds either the inherited or newly created configuration.

4. Binding the Mesh(es)

Just like we did with the eyes, we need to make sure our accessory meshes are properly bound to the bear’s skeleton so they animate correctly with the rest of the body. Otherwise, they’ll stay frozen in place while the Party Bear grooves around.

We’ll follow the same pattern: first, ensure your blueprint includes an input called In-Skeleton of type MeshRenderer. This will be the rig that the accessory meshes follow.

After spawning the accessory meshes, insert a Branch node to check whether a valid skeleton has been passed in. You can do this by using the getter for In-Skeleton, hooking it up to an IsNull node, and feeding that result into the condition input of the branch.

On the FALSE path (meaning the skeleton is valid) drop in a Bind Meshes node to connect the accessory meshes to the skeleton. Just like before, this node needs two inputs:

• Meshes: Connect this to the output from the accessory spawning node.
• Skeleton: Use the In-Skeleton blueprint input here.

5. Applying Material(s)

To give our accessory some flair, the final step is to apply a material to the mesh(es) we’ve just spawned. While in most cases an accessory will only have a single renderer, UBF’s flexibility means an asset could contain multiple mesh renderers. To future-proof our blueprint, we’ll use a For Each node and iterate over all of them.

Start by spawning a For Each node, connect the execution pins into this node from both the TRUE exec flow of the branch node and following up from the BindMeshes node. Next, connect the Renderers output from the SpawnMesh node into its Array input. You’ll notice that the Array Element type automatically updates to match the type of the input array—in this case, MeshRenderer. This loop will give us access to each individual mesh renderer, one at a time.

The ForEach node provides two execution outputs:

• Loop Body: Executes once for each element in the array.
• Exec: Executes once after the loop has finished iterating through all elements.

We’ll use the Loop Body pin to connect a Apply Material node. For the Renderer input of this node, simply use the Array Element pin from the ForEach loop—this ensures that each mesh renderer receives the material application.

6. Creating a Dynamic PBR Material

Now that we’ve got our material setup using the Apply Material node, it’s time to define the material itself. For our accessories, we want this material to be dynamic—capable of being configured by each accessory instance through graph inputs. This will allow each accessory to specify its own look and feel using custom textures and properties without needing to rewrite the logic each time. We will create a Make PBR Material that resembles the following image:

Let’s walk through how to set up this material in a dynamic way step-by-step:

1. Spawn a Make PBR Material node into your blueprint.

2. Render Mode

   Set the Render Mode to UseDiffuse, as we’ll always want to use a diffuse texture for visual definition.

3. Alpha Texture

   Create an input into the blueprint named In-AlphaTexture of type Resource<Texture>.

   Route this through a SetTextureSettings node to disable sRGB, and connect the output into the AlphaTex input on the PBR material node.

   Then, enable UseAlphaTex by setting that checkbox to true.

4. Diffuse Texture

   Repeat the process for the diffuse texture:

   • Create an input named In-DiffuseTexture of type Resource<Texture>.
   • Pass it through a SetTextureSettings node, this time with sRGB enabled.
   • Connect it to the DiffuseTex input of the PBR material.

5. Base Color

   Leave the BaseColor input at its default.

6. Use Alpha

   The UseAlpha input should only be enabled if an alpha texture has actually been provided. To achieve this:

   • Drag a pin from the previously created Get In-AlphaTexture node.
   • Pipe it into an IsNull node, then invert the result using a Not node.
   • Connect the result to the UseAlpha input.

7. Fresnel IOR

   Set this to 0.

8. Opacity

   Set this to 1 for full visibility.

9. Emission

   To support emissive elements:

   • Create an input called In-EmissionTexture of type Resource<Texture>.
   • Use a SetTextureSettings node to disable sRGB.
   • Connect the result to the EmissiveTex input.
   • As before, check if the texture is null, use a Not node, and connect the result to the UseEmission boolean input.
   • Set EmissionColorBoost and EmissionTintBoost to 1.
   • Leave the UseEmissionTint and EmissionTintColor settings at their defaults.

10. Normal Map and ORM Textures

Repeat the texture-handling pattern for both:

• Create inputs In-NormalTexture and In-ORMTexture of type Resource<Texture>.
• Pipe each through SetTextureSettings with sRGB disabled.
• Use IsNull → Not logic to control UseNormalMap and UseORM, respectively.
• Connect the textures and booleans to their respective PBR material inputs.

11. Final Float Properties

• Set Occlusion to 1
• Set Roughness to 0.5
• Set Metallic to 0.5

Once all your properties have been configured, connect the PBR material node into the Material input of the Apply Material node you created earlier in the ForEach loop.

And with that, your base accessory blueprint is complete—flexible, modular, and fully customizable from the outside! All that is left is to start creating some accessories!

​

Creating the Accessory Instances using Blueprint Instances

With our base accessory blueprint now complete, we’re ready to start bringing some actual accessories to life! In this step, we’ll create individual Blueprint Instances for each specific accessory—starting with a cozy beanie to keep our Party Bear warm.

1. Beanie – Cozy, Warm, and Stylish

To begin, navigate to your Accessories folder in the Project Explorer, right-click and select New Blueprint Instance. Name this instance something descriptive; we’ll go with BPI_Accessory_Head_Beanie. You’ll be prompted to select a base blueprint—choose the BP_Accessory blueprint we just finished setting up.

Once your instance is created, head over to the Inspector panel on the left side and open the Overrides section. This is where you’ll find all the configurable inputs that we exposed in the base accessory blueprint. Let’s go ahead and provide the correct values for our beanie accessory:

• In-Mesh: PB_Head_Beanie.glb
• In-DiffuseTexture: T_PB_Beanie_Head_BC_1024.png
• In-NormalTexture: T_PB_Beanie_Head_NR_1024.png
• In-ORMTexture: T_PB_Beanie_Head_ORM_64.png

And just like that, we’ve got ourselves a blueprint instance for our first accessory!

To test it out, open the UBF Previewer, switch to Live Connection mode, and press Preview from your instance’s viewport in Studio. If everything is set up correctly, you should now see a snug beanie rendered and ready to be equipped—a perfect fit for our fashionable bear.

2. Crown – Fit for a King

For our next accessory, it’s time to treat our Party Bear like the true legend he is—with a crown. We’ll replicate the exact same steps we followed for the beanie, creating a new blueprint instance based on BP_Accessory. This time, however, we’ll use the following overrides to configure our crown:

• In-Mesh: PB_Head_Crown.glb
• In-DiffuseTexture: T_PB_Crown_Head_BC_1024.png
• In-NormalTexture: T_PB_Crown_Head_NR_1024.png
• In-ORMTexture: T_PB_Crown_Head_ORM_1024.png

Once you’ve applied these values, jump into the previewer and admire the royal drip.

3. Space Suit – Ready for Lift Off

Next up, it’s time to prepare for zero gravity! For this section, we’ll create a space-themed outfit and just like with our previous accessories, we’ll base this on the BP_Accessory blueprint. Create a new blueprint instance and name it something like BPI_Accessory_Clothing_SpaceSuit. When prompted, select BP_Accessory as the base blueprint.

In the overrides section of the instance, plug in the following values:

• In-Mesh: PB_Clothing_SpaceSuit.glb
• In-DiffuseTexture: T_PB_SpaceSuit_Clothing_BC_1024.png
• In-NormalTexture: T_PB_SpaceSuit_Clothing_NR_1024.png
• In-ORMTexture: T_PB_SpaceSuit_Clothing_ORM_1024.png

Fire up the Previewer, hit Preview—and just like that, we have an astronaut-ready outfit looking stellar.

4. Hawaiian Shirt – Ready for the Tropics

Every great party needs some laid-back island vibes, and nothing says “relaxed but ready to groove” like a vibrant Hawaiian shirt. We’re going to create this accessory just as we did with the others—using our trusty BP_Accessory blueprint as the foundation.

Create a new blueprint instance in the appropriate folder and name it something like BPI_Accessory_Clothing_HawaiianShirt. When prompted, set its base to BP_Accessory.

In the overrides section, set the following values:

• In-Mesh: PB_Clothing_HawaiianShirt.glb
• In-DiffuseTexture: T_PB_HawaiianShirt_Clothing_BC_1024.png
• In-NormalTexture: T_PB_HawaiianShirt_Clothing_NR_1024.png
• In-ORMTexture: T_PB_HawaiianShirt_Clothing_ORM_1024.png

Preview the result and voilà—you’ve got yourself a bear-ready beach shirt, just waiting for some sun and waves!

5. Cyclops Glasses – One Lens to Rule Them All

For the futuristic fashion-forward bear, nothing makes a statement quite like a single, bold lens. Let’s set up the Cyclops Glasses as their own blueprint instance.

Create a new instance named BPI_Accessory_Eyes_CyclopsGlasses, based on the BP_Accessory blueprint.

In the overrides panel, set the following:

• In-Mesh: PB_Eyewear_CyclopsGlasses.glb
• In-DiffuseTexture: T_PB_CyclopsGlasses_Eyewear_BC_1024.png
• In-NormalTexture: T_PB_CyclopsGlasses_Eyewear_NR_1024.png
• In-ORMTexture: T_PB_CyclopsGlasses_Eyewear_ORM_1024.png

Preview this instance and watch your bear get an instant sci-fi makeover—ready for a laser-powered dance floor.

6. Eye Patch – A Bear with a Past

Every party has that one guest with a mysterious story and a silent swagger. Give your bear that rugged edge with a battle-worn eye patch.

Create another blueprint instance named BPI_Accessory_Eyes_EyePatch using BP_Accessory as the base.

Apply the following input overrides:

• In-Mesh: PB_Eyewear_EyePatch.glb
• In-DiffuseTexture: T_PB_EyePatch_Eyewear_BC_1024.png
• In-NormalTexture: T_PB_EyePatch_Eyewear_NR_1024.png
• In-ORMTexture: T_PB_EyePatch_Eyewear_ORM_1024.png

Now preview your work and you’ll see an accessory for a bear who’s clearly seen some things.

​

Dressed to Impress — Equipping Our Bear with Accessories

We’re almost there—our Party Bear is fully built, and we’ve put together a wardrobe of stylish accessories. Now, it’s time to teach our bear how to wear those accessories by wiring them into our main BP_Bear blueprint.

​

Leveraging our Bear’s Skeleton

Before we start making use of our accessory blueprint instances, remember that both our accessories and our eyes need a skeleton to bind to. Specifically, each of these blueprints expects an input called In-Skeleton, which refers to the MeshRenderer of the bear’s body. This allows the meshes to animate correctly in sync with the bear’s movements.

Now here’s the catch: the bear’s body mesh is actually spawned inside the BP_SpawnBody blueprint—not directly within BP_Bear. So we need a way to pass the MeshRenderer back up to the parent blueprint so it can be forwarded to the accessory blueprints.

To do this, we’ll use a Blueprint Output.

Head into the BP_SpawnBody blueprint and open the Blueprint Outputs section in the inspector. Create a new output of type MeshRenderer and call it Out-BodySkeleton.

You may recall that right after spawning the body, we stored the first MeshRenderer in a variable called BodySkeleton. All we need to do now is expose that as an output. At the end of the graph, add a SetOutputs node. This node allows you to specify what values to return to the parent blueprint. Connect the BodySkeleton variable to the Out-BodySkeleton input pin.

Since the eyes are spawned within BP_SpawnBody itself, you should also make sure to connect the BodySkeleton variable to the In-Skeleton input on both of your BP_SpawnEye blueprint calls.

Back in our BP_Bear blueprint, you’ll now notice that the ExecuteBlueprint2 node calling BP_SpawnBody now exposes an output pin for Out-BodySkeleton. Let’s store this value in a new variable named BodySkeleton of type MeshRenderer. We can then use this variable to feed the In-Skeleton input of our clothing accessory node.

​

Equipping our First Accessory

Time to make use of our created Accessory Blueprint Instances. To do that, we’ll now add a new ExecuteBlueprint2 node and tack it on to the end of our execution logic.

When working with the ExecuteBlueprint2 node, you can select a specific blueprint or blueprint instance directly from the dropdown. Once selected, UBF Studio automatically populates the node’s inputs and outputs to match the selected blueprint’s interface. You can try this now by selecting one of the accessory blueprint instances we created earlier—such as BPI_Accessory_Clothing_HawaiianShirt—and you’ll see all of the exposed inputs appear:

This is a great feature when you want to explicitly override every input. However, in our case, it introduces a subtle issue.

We only want to pass in the MeshConfig, SceneNode (Parent), and Skeleton. The rest of the parameters—like Mesh, Textures, and other visual elements—should be defined by the blueprint instance we pass in. Unfortunately, if we select a blueprint instance directly in the node, any unassigned fields are still overridden as null—which unintentionally wipes out the default values inside the instance. In other words, we’re nullifying the behavior of the instance even if we leave those fields empty.

To work around this limitation, we’ll create a lightweight blueprint that acts as a template or interface definition. It won’t contain any logic or nodes—it simply mirrors the signature of the inputs we want to pass explicitly into our accessory blueprint. We’ll call it BP_AccessoryTemplate.

In your Accessories folder, create a new blueprint and name it BP_AccessoryTemplate. Inside the Blueprint Inspector, add the following inputs—ensuring the names and types match exactly with those from BP_Accessory:

• In-MeshConfig — MeshConfig
• In-Parent — SceneNode
• In-Skeleton — MeshRenderer

Once complete, return to the BP_Bear blueprint. In your ExecuteBlueprint2 node, select BP_AccessoryTemplate from the dropdown. You’ll notice the node now exposes only the three inputs we care about—perfect for our needs.

Even though the node is configured with this template, we don’t actually want to run that blueprint. At runtime, we want to dynamically execute the real blueprint instance—like the Hawaiian shirt. To support this, we’ll create an input into BP_Bear that allows us to specify which accessory blueprint (or blueprint instance) should be used.

Open the Blueprint Inputs section in the inspector panel and create a new input of type Resource<Blueprint>. Name it In-ClothingBlueprint. Then, simply drag in the new input into the blueprint and connect it to the Blueprint input pin on the ExecuteBlueprint2 node.

Finally, connect the three required input pins using the variables we’ve already prepared:

• MeshConfig → In-MeshConfig
• BearSceneNode → In-Parent
• BodySkeleton → In-Skeleton

With everything wired up, open your BPI_SimpleBear blueprint instance and set the In-ClothingBlueprint field to one of your accessory instances—let’s go with the Hawaiian shirt for that perfect summer vibe.

Save your instance, open the UBF Previewer, and hit Preview in the top-right corner of the viewport.

You should now see your fully dressed bear, complete with laid-back island style—ready to party like it’s luau season in Fluf World!

​

The Full Ensemble

With the clothing slot complete, all that’s left is to wire up the rest of the accessory slots we want to support—Head and Eyes. Just like before, add two new inputs to your BP_Bear blueprint:

• In-HeadBlueprint → Resource<Blueprint>
• In-EyeBlueprint → Resource<Blueprint>

Then, drop in two ExecuteBlueprint2 nodes—one for each accessory type—and connect them in series at the end of your existing execution flow. For each node:

• Set the blueprint to BP_AccessoryTemplate to expose the correct input signature.
• Connect your existing variables to the corresponding input pins:
  • MeshConfig
  • BearSceneNode
  • BodySkeleton
• Finally, override the Blueprint input by plugging in the matching In-HeadBlueprint or In-EyeBlueprint input variable.

Now jump back into your BPI_SimpleBear blueprint instance, and you should see both In-EyeBlueprint and In-HeadBlueprint as available fields. Select your favorite blueprint instances for each slot—we’ll go with Cyclops Glasses and the Crown—hit Preview, and there you have it…

A party-ready bear with full drip, from head to toe!

​

That’s a Wrap—Fluf World’s Freshest Fit

You’ve done it! We’ve gone from a humble base blueprint to a fully modular, mix-and-match dressing system worthy of the Fluf World Fashion Show runway.

With just a few reusable components—smart use of nested blueprints, input parameters, and dynamic blueprint instances—we’ve given Party Bear the ultimate wardrobe. From cozy beanies to space suits, and stylish eyewear to royalty-approved crowns, your bear can now dress for any occasion… in real time, no patching required.

Even better, this system is fully extensible. Add new accessories, create more blueprint instances, or even build an entire outfit manager—the possibilities are endless. Whether Party Bear is headed to a beach party, outer space, or a secret pirate rave, he’ll always be dressed to impress.

So go ahead, hit that Preview button one last time and watch your bear shine.