Blender Basics - Game Development
MipMap #032: What You Need From Blender, and What Blender Needs From You
Did I say that I was taking a break from talking about game development? Technically. But that doesn’t mean I can’t talk around it.
Game development is a multi-faceted task. There are so many little moving pieces that have to be assembled in just the right way to make the game that was planned. Even though we only outwardly see and feel the models, animations, and game design elements, there’s really a lot more happening underneath the hood. Music has to be made that fills the silent void, UIs are designed so that players know what is actually happening, VFX needs to fit the exact situations, and all of it has to run on code and networking infrastructure that brings everything together.
Where I’ll be fitting into this larger inter-locking mechanism is in the art and animation side. Specifically, everything that is suited for working within Blender. And while I’ve touted that the software boasts a “Swiss-army knife” of features, in reality their are only a few tool sets that are actually applicable for game development.
So let’s talk about what tools Blender provides for making games.
A Quick Rundown
For the areas we’re concerned with, Blender is great at doing three things; polygon modeling, armature rig creation, and animation composition. There are also other tasks that can be accomplished within Blender, like Vertex Painting, Texture Baking, and even some minor VFX work, but as you begin to stray from the main priorities of Blender, you’ll find that official support drops off and that you’d need to start venturing into plugins to get a satisfying experience.
That’s not to say that Blender is the absolute best at the things that I just listed. In fact, common sentiment on the internet says that (at one point) 3D Studio Max had a better tool set for polygonal modeling, while Autodesk Maya is still better for rigging and animation. There are a whole host of software better suited for VFX work, and whatever is left over can typically be done in engine (assuming it has those features). But for game developers, and indie or AA game developers at that, all of those DCCs all come with hefty price tags that all add up. All the while, Blender will do the job for all of them for the low price of zero dollars.
I’m trying to reveal what tasks are better suited using Blender for because it helps to simplify the work ahead of you. It’s all good and dandy to go out, research the tools you need, and select the absolute best of the best DCCs in order to make your dream game. I won’t tell you you can’t do that. But I will tell you that when it actually comes time to begin working in all of those different programs, you’ll find yourself sinking to the bottom of an ocean of your own creation. Trust me, I’ve been there before.
But, covering modeling, animation, and rigging is way too much for one article. Instead, I’ll use the rest of this week’s issue to discuss using Blender in the context of moving assets in and out of the software, including the things to be aware of when exporting.
Key Concepts
File Formats
Let’s start with what is the core of any project utilizing Blender: the .blend file.
Much like the Universal Scene Descriptor (.USD) format, a .blend file contains everything that you’ve ever imported, modeled, animated, textured, simulated, or rendered for a given project. If you aren’t careful, .blend files can grow monstrously large, especially if you’re dealing with sculpts, environments, and simulations.
With the exception of Godot, game engines don’t natively support the importing of .blend files into engine environments. Instead we have a variety of different file formats that will act as our bridge between Blender and our destination DCC of choice.
Here’s a list of the most commonly used file formats:
Wavefront (.OBJ)
Old reliable, the file format that hasn’t aged so gracefully. OBJ files describe the position of each vertex, edge connections, and faces of an object. You generally don’t want to try and use it for more than that, as other file formats will handle anything else much better.
Filmbox (.FBX)
The standard do-it-all file format. If you have models, animations, 2D or 3D data, or video files that are all needed for a specific object or character, then a .FBX file format is what you want to use.
Graphics Library Transmission File (.glTF / .glb)
FBX, but on steroids. glTF files are slowly becoming the norm for transferring complex objects with more in-depth needs than what a .FBX file can provide. I’m still pretty sparse on the strengths of these files, but they appear to be gaining popularity.
Universal Scene Descriptor
A container for all of these other file types. The driving principle behind the .USD file format is to create a file format that can be used in as many DCCs as possible and allow seamless simultaneous editing of it’s contents by entire teams. Implementation is still rolling out, and some DCCs are slower on the uptake than others. But it’s safe to say that unless something else comes out, .USD files are going to be a very large part of the future.
You also might run into these file types, however they’ve either begun to fall out of popular use or their use exceeds the scope of this write up.
Alembic (.abc)
COLLADA (.dae)
Scene Layouts
There aren’t many divisive topics in the 3D world, but whether a program uses Y+ Up or Z+ Up (which dimension is the Up direction) is one of them. While in practice this amounts to just making sure your export settings are set correctly, knowing that Blender is a Z+ Up program can help solve a lot of headaches when working with Unreal Engine, which is a Y+ Up program.
The other thing to keep in mind is that the default scene units within Blender are Meters, so if for whatever reason you need to use the Imperial system, or even just different Metric measurement, be sure to switch away from Meters in the Scene properties.
Modifiers
When working within Blender, it’s incredibly hard to avoid working with Modifiers at some point. While other programs might have a destructive workflow that sees any set of actions directly change an object, Blender works non-destructively. However, this also applies to exporting objects. Unless you specifically check the “Apply Modifiers” button in the export menu, any modifiers you’ve been working with in Blender will not get applied.
On a similar topic, even if you apply your modifiers before exporting, you might find that their effects don’t carry across. Most modifiers within Blender do not carry across to other DCCs, as the way they’ve been implemented is specific to Blender and .blend files. Geometry Nodes are the perfect example of this, in most cases if you do not add a “Realize Instances” node to your setup, it’s likely you won’t be able to properly export your Geometry Nodes setup.
Beware of Origins & Transformations
Finally, keep in mind that if you are exporting objects, most file types will not apply any transformations to the object base. Your object might be 50 units in the X dimension, but their origin point will still be at 0,0,0. Make sure that you zero out the object transformations before exporting.
Tools, Tips, and Tutorials
To send us off, I’ve compiled a small list of resources to use in case you ever find yourself having issues dealing with exporting from Blender into any given program. While I’ll do my best to cover all of the possible programs, my knowledge only extends so far, and the depth of any available resources can only go so much farther.
Blender To Unreal Engine (.FBX)
Blender To Unreal Engine (.USDc)
Blender To glTF (.glTF)
Blender To Godot (.blend)
Blender To Unity (.FBX)
Outro
Of course, there is still so much more to discuss when we’re talking about the ways of utilizing Blender. Next week’s edition will focus on the principles of polygon modeling, including a brief section of UVing and Geometry Nodes, while the next couple of weeks will continue to go over animation, texturing, and rigging all within Blender.
Until then, stay blended!
- Adam