RatTower
I've started delving into UE4 development recently. I've created some basic systems, and just started to get into 3D modeling with Blender. It's enough to where I can see how I'd create a basic vertical slice of my game concept. Since you also come from a programming background, I just thought I'd ask if you have any suggestions on how to proceed, what to prioritize learning first, and general tips.
Monomyth looks great!
Thanks!
When it comes to Blender I probably can't tell you anything you haven't heard in Andrew Price's donut tutorial already.
There is however one thing that is constantly broken in the Blender->UE4 pipeline, which is bone sizes. When you rig something in blender and import it in UE4 the editor will often complain about bones being too small. As a result root motion won't work properly (it's always a good idea to make sure that works before you start animating anything). The reason is a disconnect between UE4s unit system and the units that are used in blender. Despite both systems being largely consistent when it comes to regular meshes, animations have been causing problems for years. How I understand it, UE4's importer downsizes bones because it misinterprets (?) the unit scale by a factor of 100. So one solution is to change blender's unit scale in the scene properties to 0.01 (metric). Of course, now you gotta scale your objects up as well. Just add a regular cube for reference. This may mess with your animations if you do it in edit mode.
Also, take a look at bone hierarchies and how to make your own rigs compatible with UE4's standard skeleton animations. That involves (but isn't limited to) retargeting. A general rule of thumb: You can always easily retarget the mannequin's animations if your rig has the same bone hierarchy (extensions are allowed, no pruning though), however, some animations may turn out a little funky. You can also bind the standard UE4 skeleton to your mesh, but only if you really like manual bone weighting/weight painting.
Talking of weight painting, blender has its quirks when it comes to symmetrical editing (i.e., weight painting on the left hand bone automatically being transfered to the right hand bone), so make sure your mesh and skeleton are facing the right direction (facing negative Y) and bones are named according to naming conventions. Generally speaking: Get "Mr Mannequin Tools" for reference and just in case you want to make new UE4 standard skeleton animations.
A couple of UE4-related things:
- C++ is a hell lot faster than Blueprint, but don't let that discourage you from using BP (especially not for prototyping). Theoretically, you can even nativize some of its (literal) spaghetti code in the cooking/packaging process. Just look out for circular dependencies.
- Basically, C++ is a good choice for everything that has to happen over and over again during the runtime (e.g., every frame). It's recommendable to have those things written out in C++, everything else should be fine in BP.
- If you can't use C++ for whatever reason, just make sure you disable Ticks for actors that don't need them (under class defaults). If you don't have to update a blueprints state on every frame use timers instead.
- Otherwise, you will see the results in UE4's runtime profiler (which you can find in the session frontend of the developer tools (under "Window")). You can write files at runtime for that profiler via UE4's console commands (stat startFile, stat stopFile). A standalone launch is always more representative of the final performance than the inEditor game mode.
- Another performance thing: When you are using lots of meshes in a blueprint, make sure you have all of those set to static (at least when it's possible). Also perhaps look into instanced Meshes.
- Another BP quirk: UE4 handles a lot of exceptions in the background so sometimes it's not 100% clear what just happened. A thing I noticed lately: Sometimes, UE4 won't allow the modification of an array during its iteration. However, if the array is filled with actors which are destroyed during the iteration, the array won't replace references to those actors with none/null values but actually drop them from the array, which may cause index skipping.
About level design:
UE4 was made with Fortnite in mind so its focus is
not on brush oriented interior level design (like in the original Unreal Editor or Quake) but on large scale, heightmap-based landscapes complemented by modular assets. In fact, lots of brushes (100+) may heavily affect your editor's performance while recomputing the resulting mesh. You can transform brushes into a static mesh, however, that is an irreversible work step, which is always a bad idea to have in a workflow. Though I gotta admit, I haven't built a bigger level in brushes since UE4.18. Either way, keep it in mind when you come up with a pipeline/workflow for level design.
A last thing about computation/compilation time:
Recently I switched from an old i7 (2015) to an AMD Ryzen9 processor. The difference in compilation time is so significant, I assume it has to do with the multithreading capabilities of the R9 and isn't just because the CPU is newer.
I have also heard others having a similar experience, though I can't point to any sources here, really.
Those are just a few things I can think of right now.