While using Unreal Engine I find that being able to edit everything individually in a Blueprint is great, and now rarely have any single static meshes in my scene that aren’t part of a blueprint. Recently I’ve been importing entire house assets with interior models into one large blueprint so that I can more easily edit and change them if I need to (animating them, changing materials and getting their location etc.), and instead of creating multiple small blueprints I will create a ‘master’ blueprint which basically controls how the entire game works aside from character controls and things. It seems like this is an inefficient way of doing things as I’m still kind of new to Unreal but I haven’t really seen any drawbacks so far. Is it a good idea to import everything into a single blueprint or not?
Hi, think the blueprint is an object in the world.
All meshes in it is his variable.
if he has so many meshs in it ,every time you reference to it will reference all mesh in it.
So good practice might be make them different blueprints.
That way you can control a door just reference to the door. Not the whole house.
but in my opinion you can use any method you feel like,there’s no a fixed way to do anything.
overthinking too much might cause you to be afraid of what you’re doing,and forgot what you want.
When it caused issues ,it will show.is what I want to say.
alright thanks, I thought that would be the case and for sure on large projects many blueprints are better than one large one. But for smaller projects that I’m working on it seems to not have caused too many issues so far, and just for me seems to be easier controlling everything in a single blueprint rather than constantly referencing other blueprints.
Large C++ files are bad. Large Blueprints are far more worse.
The larger a file is, it usually ends up being harder to read and maintain. It is likely it could easily be split up into many different objects.
Blueprints are even worse because they are even harder to read and are binary files (making them a nightmare for VCS).
But for small projects it probably doesn’t matter. Just think to yourself, would you benefit in anyway from splitting it up? Could this part of the BP be used by another BP?
rarely have a single static mesh* in my scene that isn’t* part of a blueprint
it should be the exact opposite especially for Static Meshes
if a static mesh is going to be static, it should be part of an HISM unless its nanite (even if it will be interacted with later)
array variables should be empty unless it will be used for logic, for that look into structs + data tables. With DTs, arrays can be populated only when they’re needed but then cleared later on.
stitching modular assets with BPs is great, but leaving them in the BP after packaging is not better than converting them to HISMs
references to logic should be stored in HUD / Controller (like player comps) so other BPs can access them easily, that way you won’t need BP interfaces either for many use cases
BP size should be minimized wherever possible, for that you have Macros + Common Functions library and also reduced variables, for that you have the Edit tab > Delete Unused Variables
overall, BPs (or any logic) should be like LODs for a mesh where ever possible