Update 2: Engine choice, importing assets, and terrain
Warning: Much rambling ahead.
Up until today I hadn't actually decided on what engine to use. I'm usually tempted to reach for Unity when attempting game jams for its no-hassle HTML5 packaging and everyone's favorite: Good ol' prefab/live object refs. You know, when you drag and drop things from the scene into inspector properties? It makes prototyping things so genuinely gross (the good kind of gross, I mean).
However, it's been a while since I've attempted a jam in UE4, and there's a lot that's been happening in the UE4 ecosystem that's been getting me a bit fired up. For one, I've always loathed the poor tooling experience around writing C++ for UE4 projects, but JetBrains has been working on a domain-specific IDE for UE4 (Rider for Unreal Engine). I tried it out a few months back, and I was pleasantly surprised at it's speed and accuracy.
To be clear, I have no hangups what-so-ever with UE4's abstractions/tools/frameworks/internals or even C++ itself -- my problem is that VS2019 + Resharper C++ intellisense in a UE4 codebases is:
- dog slow due to UE4 being a huge codebase with 100s of thousands of symbols to index, and
- poor quality due to UE4's heavy reliance on code generation (UnrealHeaderTool) and preprocessing (deeply nested C++ macros).
And codebase-wide intellisense is kind of important for productivity in UE4; I find that remembering common macros isn't much of a problem, but I do often forget where certain headers are located, and without good completion, I tend to spend a lot of time grepping the codebase or surfing docs to re-find headers.
So with a new IDE in hand, my body is ready.
I fired up UE4, exported Polly, and worked through all manner of issue with the imports. First I had multiple root bones, then I didn't have smoothing groups exported correctly, then my axis conversions for UE4 were wrong, then the animations were scaled down 100x due to a unit conversion problem, and then... the worst issue happened.
Time for a little side tangent about Blender...
In Blender, I usually just define actions for animation export. However, the "start" and "end" frames aren't actually stored with actions. And so when exporting actions, Blender automatically renders all frames between the earlest keyframe to the latest keyframe in the action. This behavior works great for non-looping animations, but scales poorly when building lots of loops (which is mostly what I do). So I finally decided to figure out how to do things "right", and defined an NLA action strip for each animation with customized start/end frames, and used the "NLA Strips" option under "Bake Animation" during FBX export. This bakes the contents of each non-muted NLA strip as a separate animation in the FBX.
Out of all the quirky UIs in blender, I've always felt that the NLA editor is among the most quirky. I typically only use Blender to author short animations and loops, and so up until now, my attempts at using the NLA editor have usually ended with me throwing my hands into the air and reverting to a less scalable authoring patterns.
At first, adding these NLA Action Strips seemed to be going smoothy (this can be seen in the timelapse I posted yesterday). It was simple enough to get the animations set up initially... or so I thought.
Once I actually got to the point where I could view animations in UE4 today, my loops were all cutting off at seemingly random spots! After a whole lot of trial and error, I realized that I was accidentally adjusting "Strip Extents" for some of the strips instead of the "Action Extents". After fixing them, it took me a while to realize that when you make changes to "Action Extents", said changes also append to the "Strip Extents". And so after correcting the "Action Extents", Blender automatically adjusted the "Strip Extents" to reflect the difference, and so correcting the "Action Extents" just propagated problems rather than solving them.
So in all, I thought that getting Polly imported would take 10 minutes, but it turned out to suck up hours. Oh well! Future models won't be this hard.
After getting the FBX import tuned right, I moved on to building the start of the terrain material.
See you next update!
