Since the beginning of 3D animation, we are seeing 3D graphics in two forms. Offline rendering in animation movies and advertisement and realtime rendering in simulations and games. Each purpose has its own requirements and limitations, and that’s why the short answer to the title is no. Most of the time, any 3D character you find around may not be suitable for your specific game engine. So if you’re trying to purchase a stock 3D character like this one of mine, you should never assume it will be real-time friendly if that is not explicitly stated in the description. It must say something like: It’s real-time or game-ready, suitable for Unity, Unreal Engine or others.
The purpose of offline rendering (or software rendering) is to create images as beautiful as possible to produce still images or animation sequences for movies or advertisements. A classic example is Toy Story, one of the movies that started the revolution of animation on the big screen. In this case, you want to achieve the best quality and consistency in the image, no matter the hardware behind it. Most of the time, the computer CPU is responsible for making all the calculations and it may take several hours rendering a single image.
When your target is offline rendering, you are free to use most of the specific features of your animation software (3Ds Max, Maya, Blender, C4D). All special effects and complex material are acceptable; you decide where to put your own limits based on the requirements of your project. For a character, you could use high-quality hair and fur plugins, special materials to simulate the skin, complex skeleton systems, muscle dynamics simulations, high polygon counts and more. Just anything that the 3D software of your choice allows.
When modeling a character for general animation I focus not only on its appeal but also on how easy it is to customize, trying to keep all objects and material separated for later modification. Hidden parts would be modeled and textured in case we need to change the clothes, remove the shirt or shorten the pants.
In Real-time simulations and games, the objective is to present to the user some nice interactive 3D graphics experience (like GTA V or DOOM 2016) as quickly as 30 frames per second or more. Lower than 20 FPS begins to be uncomfortable for most people and recently, most gamers demand to play their games at least at 60 FPS. In these circumstances, your application needs to render the image in less than 30 milliseconds with the help of the user Graphics Card (GPU), and every user will have different hardware that you won’t be able to guess in advance.
Now you lose some freedom and are subject to a few limitations, many requirements, and suggestions. Game engines like Unity and UE4 will try to allow you to make anything you want but everything is now constrained by the performance of many different hardware and platforms. While you can prepare your character in 3Ds Max or Maya, you can’t use all the features that this software provides. Hair and clothes simulations may not be compatible with your game engine. The skeleton may have a limit of bones count affecting vertices. Procedural materials are no longer compatible. Textures that are too big and not squared will create issues and increase your application weight.
Optimization is a priority in games: if a character will be always wearing a shirt, avoid modeling the full body or delete hidden parts if present. Most times is recommended to have a whole character as a single object with a single texture, but is often useful to have the head and eyes as separated objects and materials for better details in closeups and implementing face morphing.
The Easiness of Solid Objects
Characters are more problematic here. If you want to import solid objects in a game engine, like props, weapons, rocks, crates, chairs… that would be straightforward – there are only a few general specifications to follow. If the 3D model is just a solid shape with textures, try to import it. If it looks right, just keep going.
I’m not going into specifics of each engine, but I’ll try to mention some that are common to any 3D game engine out there.
– Texture dimensions should be square and to the power of two (like 512×512, 1024×1024, 2048×2048). Even though modern hardware can support non-square textures, keeping them a power of two will be always a good thing.
– Polygon efficiency and economy. The right amount of polygons is hard to tell, but you should try to keep it as low as possible while the model looks still good on the screen.
– As few materials as possible for a single model. Ideally one object, one material.
– Mesh without holes or single 2-sided polygons. This is just a recommendation, the best is that you never see a polygon by its back face.
Character for Animation
Engines define a character as a mesh driven by a skeleton, and the skeleton can have several animations. Here I’ll mention common recommendations for Unity and UE4 characters imported as FBX format.
– The mesh should have a Skin modifier applied from 3Ds Max, Maya or Blender. Other systems like 3Ds Max physique will not work.
– The associated bones to the Skin must be standard bones or Dummy objects, not shapes or other strange objects.
– The hierarchy of bones must have a unique root.
– Stretching bones animation may not be compatible with most engines.
– All the visible mesh must have the Skin modifier applied. You can’t attach a mesh by linking directly to a bone, but you can create a similar behavior later inside the engine editor.
– Any special effects like hair, dynamics or SSS skin material should be studied particularly to each specific engine. Formats like FBX and OBJ can’t transfer anything that complex.
– Morph targets (or blend shapes) are allowed.
Purchasing a Character from the Marketplace
It would be safer to get a character from your engine marketplace, that way you’ll be pretty sure that it is ready for games, but not all of them will fit your specific game requirements. If you need your character to talk, be sure it contains morph targets for mouth and facial expressions. Is it for a high-end PC or low-end mobile? Look for the poly count and material complexity.
What about the biggest marketplace like TurboSquid? Here is where you need to be careful and know how to identify real-time game ready models versus off-line rendering models. A character like this looks nice but this is because it is intended for off-line rendering. If you try to import it into a game engine, first it will lose its mesh smoothing effect (TurboSmooth), and some 2-sided materials will make the mesh look weird; finally, the animation will not work at all, since it is using Physique system instead of the standard Skin modifier.
I have many characters published on TurboSquid, and a lot of requests from my clients has motivated me to write this article. They want to know if the characters are suitable for games in Unity or UE4, and unfortunately, I have prepared and tested only a few to be real-time game-ready.
This is my list:
(More are coming soon!)
The Ideal Scenario
The ideal situation for your game is to have someone on your team to prepare the characters with your specific requirements. A character for a fighting game will need different rig features than a character for a real-time strategy or a first-person shooter. In these circumstances, you could create your own model or purchase a non-rigged character like this one, then explain to your rigger or animator what do you want this character to do in your game, and what the requirements are for your game engine and target platform, having full control all times and ensuring a standardization between all your game assets.
High Complexity and High-Quality Characters
As you master a tool like Unreal Engine 4, the highest quality and complexity can be added to real-time characters that, rendered with a modern GPU, can achieve results as beautiful as offline rendering while pushing the limitations of real-time. But no matter how far real-time rendering could go, there will always be conflicts and differences between assets created for offline rendering and those intended for real-time. Still, we don’t have a universal format that could seamlessly translate 3D models between software without losing specific features.