Hey, I wrote an article for the official Codeflügel blog about “3D Model optimization for mobile devices”, which contains a lot of infos and advices on how to make your 3d models run smooth and with good performance on mobile devices such as smartphones or tablets.
3D model optimization for mobile devices
Interactive 3D content is the big thing in technology right now and it’s arriving on mobile devices. But since smartphones and tablets usually can’t keep up with the performance of an average desktop computer or gaming console, 3d models intended for mobile devices have to be carefully optimized to look good and perform well. In this blogpost, you’ll learn why, when and how these optimizations work.
While modern smartphones and tablets are pretty capable in terms of graphics performance, they’re not nearly as powerful as gaming consoles or desktop pcs. If your mobile application or game uses intricate models with complex surfaces or materials, then you’ll run into performance problems pretty quickly. Additionally, it’s probably not a wise idea to only support the very latest generation of devices with your app, but also make it available and perform well on older smartphones and tablets.
Heavy models
It’s not uncommon to already have existing 3D models made for another purpose (like CAD models for manufacturing or high quality models intended for product illustration). Now, usually these kinds of models perform very poorly (if at all!) in a realtime 3D app running on mobile devices, because they simply weren’t intended for this use. Most of the time they are “heavy”, meaning they have very detailed forms (and thus contain way too many polygons/triangles for the GPU of a mobile device to handle) or come with big textures (huge resolutions) and complex materials (lots of drawcalls/batches). However, re-creating those models from scratch for your mobile application would be a waste of resources, since it almost certainly would take longer than taking the existing model and optimizing it for mobile devices.
Other calculations (AR, physics, …)
How great would it be, if we could use all the processing power of our device for displaying neat 3D graphics? Nope, not going to happen. Unfortunately, there’s usually a lot more going on in the background and taking a big chunk of the performance power available. For example, in an Augmented Reality app there are a lot of calculations necessary to track the camera stream and then adjust the position/rotation/scale of your 3D content accordingly. All of this before any drawing of 3D models on screen is done. Add some 3D animations, realtime physics and maybe particle effects on top of that and you get the idea why we have to make sure our 3D models are as optimized as possible to perform well on mobile devices.
When?
Well, all the time of course, duh! Every model you use in your mobile application should be as performant as possible. However it does make a bit of a difference whether you create your models from scratch or you have to optimize some pre-existing models. In the first case, you “just” have to stick to the mobile optimization guidelines (just read on until the “How?” section for those) during the creation of your model. I put “just” in quotes because this can still be a very tedious creation process, depending on the level of quality you’re aiming for. It’s important to note that optimization for mobile devices is not an afterthought and something that can easily be done after the model is finished, but rather is something that should be kept in mind during the whole creation process for new models.
If you have to optimize already existing 3D models they probably fall into one of the following 3 categories:
CAD models
3D models created in CAD software usually consist of forms which are described parametrically (mathematically) rather than the polygon/triangle based models 3D (game) engines are able to display. So the very first necessary step to make them usable is converting them from a parametric file format (for example STEP, IGES, SLDPRT) to a triangle based file format like STL or FBX. The easiest way to do this is by checking whether your CAD software of choice is able to export to a triangle based file format. If not then you need to do the conversion yourself. As an example, I found Fusion360 or the open source FreeCAD work great for this purpose. During the export, you usually have some options to control the quality of the triangulation (that’s what the process of turning a parametric into a triangle based model is called). Pay attention and keep a balance between to not having an extremely high resulting triangle count as well as to not losing too many fine details.
Photogrammetry models
Photogrammetry is the process of automatically creating 3D models from photographs. While these resulting models can look great, they often have a very high polygon count and use very large textures. Unnecessary to mention, that’s kind of a worst case for performing well on mobile devices. Additionally they don’t perform well when deformed during animation and probably need their 3D structure rebuilt by hand (read below for how that is done).
Film/VFX/non-realtime models
Models created for TV movies, ads or product visualizations for print are very detailed, have high resolution textures and possibly also very complex skeleton rigs for animation. Because of this, they also can’t be used for mobile devices out of the box but need some optimization first.
How?
Long story short, here’s what you can actually do to make your models perform well on mobile devices. Of course, there are no hard and fast rules (ha, that would be too easy wouldn’t it?).
In general, there are three areas you have to pay attention to:
Polycount
Polycount (short for polygon-count) refers to the number of polygons (or triangles) your 3D model is made up of. The goal is to keep this number as low as possible, while still retaining interesting forms and details. A rule of thumb is to have every form that contributes to the silhouette of the model modeled in triangles while smaller details should be created with image textures. While there are some hard numbers (like Unitys manual stating that models for mobile games should range between 300-1500 triangles per model) the real answer is once more: “It depends!”. If you only have 2 models on screen at once without fancy graphic effects then you certainly could aim for a higher polygon count. If it’s lots of models running a physics simulation then it may be even necessary to have way beyond 300 triangles per model. A bit of experience and a lot of testing should lead to the optimal results, as is so often the case.
When starting a model from scratch, you can conveniently plan ahead and build it with the desired polycount. For existing models, there are a few ways to bring down the polygon count. Here are some of them:
Automated
Fortunately, there are automated algorithms which create models with the desired polygon count based on the forms of existing models. For most static models, these algorithms do a good enough job. Examples are the “Quadratic Edge Collapse Detection” Filter of the Software Meshlab (Open Source) or the “Decimate” Modifier of Blender (Open Source).
Manual
Since the automated methods listed above just bring down the triangle count without being aware of the mesh structure, they’re usually not feasible for animated/deforming models like characters. For this purpose, there are more sophisticated ways to bring down the polygon count: Semi-automated algorithms which let you create “guides” to have control over the final result. Examples include the Remesher by zBrush or the Autopo tool of 3DCoat.
The last method gives you the ultimate amount of control but also takes the most amount of time: Rebuilding the model with a lower polygon count, following the forms of the original model. This process is called “Retopology” and can either be done with most popular 3D suites like Maya or Blender, or using software only dedicated to this task like Topogun.
Materials/Textures
The goal here is to have as few drawcalls (or “batches”) as possible. This is closely related to materials/shaders of your models: If you have lots of models with different materials that’s a lot of drawcalls to display them on screen. It would be much better in terms of performance if all those models could be displayed within the same drawcall.
How can this be accomplished? Well if models share a similar shader and only use different textures, then consider assigning the same shader to all of them and combining their textures in one big texture sheet. Such a texture sheet is called a “Texture Atlas” and can save you a lot of drawcalls and thus earning some performance boost. Software examples for this task include the commercial TexturePacker, the open source packer of libGDX or the Sprite Packer included with Unity3d.
Animations
Unfortunately, for animations and skeleton rigs there’s no automated solution, you have to optimize the rig by hand. Some rules to follow include:
+ Use as few bones in your rig as possible. Try to get rid of every non-deforming bone you don’t necessarily need
after exporting to your game engine of choice.
+ Do not combine multiple meshes within one skeleton rig. Because of optimizations in the way animations are
displayed you can get much better performance if you combine all models of one animation into a single model
before binding it to the rig.
+ Don’t overuse keyframes. Only keyframe bones which have moved since the last keyframe to keep the animation
file small.
+ Bake down your animation for exporting to the game engine/mobile app, this way you can use constraints or
inverse kinematics for animation.
+ Protip: Keep your IK and FK chains separate so you can delete the IK bones once the animation is baked for
export.
Final Words
Whew, congrats, you made it to the end! With all this information, it should be possible to create great looking interactive 3D content which runs smoothly even on older mobile hardware. Just be aware that it depends on the specific situations which of these optimizations have the bigger impact, although none of these would ever have a negative impact on performance. ;)