Hey all… I’m really new to Unreal, coming from the Unity world. Trying to understand some differences between the two engines.
I’ve been ramping up on Unreal and learning the Blueprint system going through a set of blueprint tutorials that started out creating a Material. I’ll call it TruckMaterial. In the blueprint for the material, we created a couple public variables.
Next we created a TruckMaterial instance, I’ll call it TruckMaterialInst. Inside the blueprint for the instance, you can set the public variables created in the base material.
Then we progressed into dropping a truck mesh into the level. Created a new blueprint for the truck by clicking Add Blueprint in the World Outliner. I’ll call it TruckBP.
TruckBP was then modified so that it could adjust the public variables in TuckMaterialInst.
This all worked. If I clicked on the Truck in the level, in the Details->Default area for the truck, I could see the ■■■■■ variables and adjust them. This all worked fine. I deleted the instance of the truck in the level. I went back and placed a new Truck into the level. I wanted to try and “attach” the TruckBP to the truck but could not figure out how to do this.
Can you, take a new instance of the Truck mesh from the content browser and apply an existing blueprint to it? Through trial and error, something… I attempted to drag the TruckBP from the Content Browser and drag and drop it onto the new instance of the Truck. What I noticed is that when I did that, I new truck appeared in my level all attached and working properly.
Is this to say that after defining the trucks initial blueprint “TruckBP”, it then acts like a Unity “Prefab”? Where once it’s been defined I can just drag and drop it back in place and reuse that blueprint rather than the default Truck from the Content/Materials/Pickuptruck mesh?
I don’t have experience with Unity so I’m not sure what a pre-fab is but it sounds like they probably do act similarly. There isn’t really a proper way to re-use blueprints for multiple instances. It just depends on what you’re trying to do.
For your truck example, the Truck BP can handle all the generic truck things: driving, honking, fuel usage, etc… and you can set different meshes and materials for each instances. You can either do this manually in the editor or at run time through game logic.
If you want all your trucks to have the same mesh/material, then you’d want to change the default blueprint and that will update all the instances.
Just to avoid confusion, I’ve never actually heard these referred to as Public Variables before (even though that’s what they are). Typically they’re referred to as material parameters.
Just to clarify a few things too:
BPs are very different than using a mesh. The mesh doesn’t have game logic where BPs do. So if you place a mesh in a level, its basically just a scenery prop and you won’t be able to dynamically change the material parameters form the editor (like you can with the BP).
You might want to look at the documentation for Actors. Everything you place into a scene is an instance of Actor or one of its subtypes (such as Pawn, Character, StaticMeshActor, etc.).
You cannot actually place a mesh asset directly into the scene - when you try to do this, the engine automatically “wraps” the mesh with a basic built-in Actor BP (StaticMeshActor or SkeletalMeshActor) and assigns the mesh asset to a StaticMeshComponent or SkeletalMeshComponent in the Actor. So,
Sort of, but this is backwards - you would create a BP and add the Truck mesh to it as a component.
I don’t know what a Unity Prefab is but you can add as many mesh components as you want to any Actor BP. For example, you can have a modular Character BP with separate meshes for the shirt, shoes, hair, etc. that you can change at runtime on a per-instance basis. The BP itself is a class, so you can place as many instances of it as you want into the scene.
In Unity, everything is pretty much a game object. Rather it’s a cube, a light, a C# script.
As an example, if I put a cube and in my Unity scene, then applied a material to it and then attached a C# script that would rotate the cube, I could then save that back down into my games “content” section and it automatically becomes a “prefab” where I can drag that prefab back into my scene and it will have all the properties ect already set. I could then just reuse that exact same thing over and over.
The script itself knows how to get the game object it’s attached to, grab the transform, and it’s the transform that the script is actually rotating. So, basically, this rotate script can be applied to ANY game object that has a transform rather it’s a cube, a light, a detailed out mesh etc…
Thanks for the heads up, What’s called a Level in Unreal is called a Scene in Unity. I’m trying to be sure that I’m using the proper terms.
Sure, I do understand the distinction there. The truck mesh is just something that sits there until you add functionality to it using a BP. Same concept in Unity, have to attach a script to it to make it do something. I think my comment got a little murky and probably wasn’t clear.
And that’s what I’m trying to figure out. How do I reuse a blueprint. Lets say that I want to create a BP that can work with my material to expose the two color values. That I can then attach to either a car mesh or a truck mesh and modify the material. Is there a way to “drag and drop” a BP onto a vehicle in the level?
I hope this makes since. If not, I can go into a lot more detail about how the base material and the instance material work. And then how the truck BP was using that material in the construction script of the truck bp.
This is excellent info! I was unaware of how it’s working under the covers. I’m guessing that a StaticMesh is something like a cube, a car, and Skeletal is something like a humanoid that has things that can move, bend, etc.
Yeah this is different than I’m used to. if I wanted a cube that rotates, I would place a cube in the scene/level, create a new C# script. Drag and drop that script onto the cube in the scene. Inside the script, it was easy to get the transform to what ever the script was attached to, once you had the transform, you just rotated.
From what I’m starting to learn, it almost sounds like an Unreal BP is similar to a Unity Prefab. I hate to say they are the same because I’m sure there are lots of differences.
An example of what a prefab in Unity would be is something like a torch. In Unity I would drag a torch mesh into the scene, then I would apply the materials, then I could add particle affects to create the flames and smoke, I could add audio to sound like flames roaring. Once I had it all setup the way I wanted, I would then take all that as a whole and save it off into the; what Unreal calls the Content Browser. Unity would then automatically convert this into a prefab. I could then grab that prefab and place multiple instances of it where ever I needed. IF, I needed to make a change, I could modify one instance of the prefab, and it would stay local to that instance OR I could apply those changes to all prefabs.
I’m sure Unreal has the same concepts with BP, I just need to get more familiar with and understand them better. I’m really liking Unreal so far.
Ah I think I understand – the same code functionality with two different blueprint classes. Not by dragging a BP onto an actor but through class inheritance where child classes inherit the parent’s class functionality.
For example, say you have a vehicle class BP which is the parent of a car class BP and truck class BP.
In the vehicle class, you have a static mesh component that is hooked up to the function to change the material color along with general vehicle functionality (movement, fuel, etc…)
In the truck class, it inherits the static mesh component (not the mesh itself) and all of the general vehicle functionality but you can also add truck specific stuff (like a trailer hitch). Same for the car except you can add car specific stuff.
Thanks Arlyn, Dsyd, I greatly appreciate y our help. I’m probably asking a lot of questions, I’m sorry, I’m just trying to understand how BPs work and the differences between the two engines.
Thanks for the link, I will go read it!
Maybe… When I think about this, what comes to my mind is, two different Actors sharing one blue print.
In Unreal, say I had a level that only had two things in it. A cube and a Sphere. I wanted them to bob up and down. Can I have one BP that is generic enough to modify the transform of no matter what it’s attached to?
OR as this indicates, do I need to have one parent BP then has child BPs where one child is specific to a Cube and the other child BP is specific to a Sphere?
Basically, yes - a Skeletal Mesh is a skinned mesh, so it has a skeleton (hierarchy of joints/bones) and its vertices are bound to the skeleton. A Static Mesh is a non-skinned mesh, so it doesn’t deform (unless you apply an alembic cache to it).
It sounds like Unity’s workflow is sort of the reverse of UE4. In UE4, you don’t “attach” scripts to meshes, you “attach” meshes to (Actor) BPs as components. If you want multiple meshes to share the same functionality, like being able to change materials or transforms at runtime, you could:
Create a custom Actor BP class with a mesh component, code the functionality in that class, then create child classes where the mesh component is overridden, as Arlyn suggested;
Same as 1 but without child classes, and replace the mesh component on a per-instance basis (you can change it after you’ve placed it into the level) or based on runtime logic;
Create an Actor Component BP that codes the functionality and add it to any BP that needs it
#1 is inheritance-based, #3 is “compositional” and probably sounds most similar to what you’re describing in Unity. #2 requires the fewest number of BP classes but could cause other headaches.
Thanks for that feedback. I want to do it the proper way in Unreal and follow the Unreal approach. Not wanting to try and force the Unity way here. From what I’m learning it does sound like they are kind of reverse. Your guys feedback is really helping to clarify things. Greatly appreciated!
For something that simple, you’d probably have a single Actor BP (e.g., BobbingActor) that implements the up/down behavior and has a Static Mesh Component with the cube as the default. Place two instances of it in the level, select one of them, then for one of them, replace the Static Mesh Component’s mesh with the sphere.
You don’t need to create child BPs if the only thing that will vary between instances is the mesh (or any other data values).
I am searching for a proper solution to this since my first day here and I realized that you have 2 proper options:
Create a component blueprint with bob up and down behavior, so you can attach or detach it to any actor with a translation. (instead of making it a blueprint itself). So you would have your BP_Cube and your BP_Sphere, both with a component attached: Comp_Bobbing.
It is disappointing and surprising that through blueprints, you won’t be able to override Comp_Bobbing in your BP_Cube and BP_Sphere, so if you want your 2 shapes bob up and down differently you will need to use inheritance doing something like:
BP_Mesh implements Comp_Bobbing
Make BP_Cube and BP_Sphere child of BP_Mesh
Now BP_Cube and BP_Sphere will be able to override your BobUp function at Comp_Bobbing. Otherwise it is not possible.
The second solution would be to use an interface. So you would add to BP_Cube and BP_Sphere an Interface like “IBobable” :D. And then you can just implement it as you wish, easy and fast and performance efficient!! However…
You will have to re-implement the interface functionality for each and every blueprint using that interface, because, we can’t have a default implementation for an interface in blueprints. So you will need again inheritance.
Hope this help and hopefully there is a 3rd method that I couldn’t find yet and someone bring lights about.
You wouldn’t need child classes if you parameterized the “bobbing” in the Comp_Bobbing component. For example, you could have variables in the component that control the speed and height of the bobbing, plus events that turn it on/off. That way you could use a single component class and control the bobbing behavior on each instance by tweaking the parameters.
