In the previous entry, I talked about all the models I made in Blender. However, in that entry I kinda skipped over a step. Before I could import those models into my… game… demo… experiment… thing, I had to make my own importer, because the built-in Unity importer is a hot mess.
It’s frustrating, because the existing system is 95% of the way there. But if you want that last 5%, then you need a lot of extra code. Fixing this within the Unity source code would be pretty easy, but for indie beggars that can’t pay for source access, the importer is locked inside of a black box. Take it or leave it.
Hey, it’s been ages since the last Terrible Car Analogy, so let’s do one of those:
You have a muscle car. You want to make it way more powerful by giving all those extra parts that gearheads like to add to increase the engine’s horsepower. However, you’re not able to add things under the hood. Anything you add needs to be stuck outside the car somewhere. Your improvements are going to be ugly as hell, and not nearly as effective as they would be if you could edit the stuff under the hood.
So what’s wrong with Unity’s code to import Blender models?
Let me count the ways…
1. It can’t handle multiple textures on a single model.
Let’s say you’ve made a model of a car. The body uses the texture RedPaint1.png. The bumpers use DirtyChrome.png. The tires use DeepTread5.png. The interior uses FineCorinthianLeather.png. And so on.
The Unity importer doesn’t like this, so it will throw away all but one of the textures and apply the remaining texture to the entire vehicle. So you end up with (say) an entire car mode of solid chrome, or whatever. If you complain about this on the forums, people will tell you that this half-assed system is “helping” you because you’re not supposed to put too many textures on a single object because that keeps Unity from rendering objects in batches, which in turn might slow down your game. That’s true in some cases, but these things are highly situational. If this is the big fancy central set-piece object of the scene, then you don’t need to worry about batching because you’ll only have one of these things in the scene at the time.
To fix this, you need to jump over to Unity and break the object into many sub-objects. That fixes the problem, but maybe you don’t WANT your Unity object to be fragmented like this because that will make it harder to work on. The proper solution would be to have Unity break the object apart on the way in. That might still have downsides, but this would be far more sensible than applying a single texture to the whole object, because the latter renders the object useless.
2. It doesn’t properly translate coordinate systems.
In Unity, the X axis is left/right, the Y axis is up/down, and the Z axis is forward/back. In Blender, the X is still left/right, but the Y axis is forward/back and Z is up/down.
These are both valid coord systems and each one has its own benefits. I prefer the Blender system because That’s how I structured my engines back in the day when I used to make my own. I like this because you can throw away Z (up/down) and use the X+Y for an overhead map.
In Unity, the priority was to make the same engine useful for 2D and 3D projects at the same time. In Unity, if you throw away Z (forward/backward) then you’re essentially working with a side-scrolling style game like a platformer. The Y coord is still up-down, so the physics engine can still do its thing without needing to care if you’re making a 2D or 3D game.
The point is that these coordinate systems are very different, which means that it takes a lot of advanced big-brain math to convert between these different systems. Check it out:
- Take Blender’s Z value and assign it to Unity’s Y.
- Take Blender’s Y value, multiply by -1, and assign it to Unity’s Z.
- That’s it. You’re done.
So I lied. It’s trivial. Literally one line of code:
unity_vert = Vector3 (blender.x, blender.z, -blender.y);
But for whatever reason, Unity’s importer takes the Blender model through a complex conversion process and then stops one step short of the finish line by skipping the most trivial step. If you’re importing (say) a refrigerator, it will appear in Unity on its back, with the door facing up.
But wait! It’s worse!
Unity then covers up this crime by taking this newly-created model and manually rotating it forward 90 degrees on the X axis. This means the fridge will appear to be standing up in the world as you expect. However, if you start rotating the fridge – or if you ever tell it to return to default rotation – then it’s going to end up in an unexpected position and you’ll probably assume you’ve got a bug in your code, because why would you suspect a model importer of treachery?
3. It messes up the surface normals.
The surface normals tell the rendering system which way a polygon is facing. If you mess it up, then you’ll have a wall that faces (say) west, but it reacts to light as if it was (say) facing forward. Or whatever. The result is confusing nonsensical lighting.
I’m not 100% sure what causes this, but as far as I can tell, Unity hates when you have a model that isn’t an enclosed solid. Like, let’s say you make a cylinder. It has the polygons for the round outer wall, more polygons for the top, and finally some to make the bottom. Like a soda can, this is an enclosed solid. But then you delete the top and bottom because you won’t need them. This object is a vertical pipe that runs floor-to-ceiling, so the player will never see the ends.
But without the ends, the object is now a hollow tube, like an empty toilet paper roll. For whatever reason, Unity won’t / can’t use the perfectly good normals you had in Blender, and you wind up with nonsense garbage normals.
So don’t cut the ends off of the pipe, right? That works, unless you run into problem #1 above and you MUST tear the object into pieces to keep Unity from forgetting your texture info. All of those pieces will be non-solid, and thus it’s random what Unity will do to the normals. I’ve had two pipes in the same model. One was an exact clone of the other. They were lit properly in Blender, but after Unity got done importing it, one pipe was correct and the other was inside-out, and nothing I did on the Blender side could fix thisBlender lets you flip the normals, turning the object inside-out. But this doesn’t fix it. It’s like no matter which way the polygons face, Unity insists on making them backwards..
4. The Unity importer is shamefully slow.
I have no idea what the deal is, but I suspect this is a contributing factor in why Unity games are notorious for unreasonable load times. Unity makes this sad, half-converted object and stores it as a “prefab”. A prefab is like an original blueprint for an object, or collection of objects. So when you want to place those pipes in the world, you have to make a clone of this prefab.
I wrote some code to go through all the Blender models, create an instance of each one, do the trivial math to get it properly converted to the local coordinate system, and then save it in my own homebrew binary file format. That process takes about 1.4 seconds to process my entire library.
Then when it’s time to run the game, it loads in all of those binary files. That part takes 0.004 seconds.
That’s bonkers. I realize the first thing is doing a lot more than the second thing, but it’s not doing three orders of magnitude more. As far as I can tell, there’s something absurd with the code to make a copy of a prefab that makes it take bloody ages.
So here I am, bitching about Unity again. If I hate it so much, why don’t I embrace one of the many alternatives?
I know this topic is a bit of a re-run for some of you. I’m compelled to complain about this at least once in every programming series. This is mostly for new-ish readers that haven’t heard it before.
The good news is that a lot of this work was already done for me. Two years ago I made a thing in Unity. It was a sort of Minecraft clone, and the point of the project was to experiment with some alternate ways of generating caves. A wrote my Blender model importer back then, along with the atlas texture code I talked about back in part 4. I was able to drop both of these complex systems into this project and make use of them with only minor changes.
Loots of programmers will jump in and say, “Duh, Shamus. That’s what code reuse is all about. You shouldn’t need to re-write everything all the time.”
My problem is that code reuse is really hard when you’re trying to do graphics within barebones C++. In C++ you often find yourself in situations like this:
- The library I wanted to use for this project depends on this other, far larger library that I really don’t want to use.
- The library is incompatible with another library I’m trying to use.
- The library is very old, and on modern compilers it generates hundreds of annoying warning messages. I don’t want to suppress those warnings because suppressing warnings is like taking the batteries out of your smoke detector because it’s too sensitive and goes off when you make toast. At the same time, I don’t want to make hundreds of small edits to clean up these harmless warnings.
- The library is no longer available. The project fell apart, the website vanished, I don’t have the source, and the binaries I downloaded years ago are for 32 bit applications and I’m working in 64 bit now.
- The documentation for this library has always been a disaster, and I’m tired of trying to reverse-engineer everything just to figure out how to do something simple.
- This library is enormous and I really just need a few tiny features from it.
- This project was originally targeted at linux. A few years ago I somehow managed to get it to compile on Windows, but on the current version of Visual Studio it won’t, and I have no idea what I’m going wrong. All the answers on Stack Overflow are short, condescending answers telling people to RTFM, which is now a dead linkSeriously, I think SO should adopt a policy of “If the answer is simple, then just answer it yourself rather than being a smartass and posting a link. Links die, and questions on this site do not..
- This library is now too old to be useful. Maybe it’s a rendering engine that can only access the pre-2004 OpenGL features. Maybe it’s an input library that supports old 90s flight sticks but not modern console controllers. Maybe it’s an ancient UI library that can’t handle resolutions above 1600×900. Whatever.
We can file all of these problems under the broad heading of “rotten”. It was good once. It would still be good now if you were still doing things the way you did them a decade ago. But time has passed and this library has been left to rot. We need something new.
As a result, everyone one of my homebrew projects would begin like this:
Okay, let me drop in my atlas texture code from the last project. Oh no. This one is linked to a PNG library to load the textures, but that’s rotten. I replaced it with this other library. Hang on, that one can read PNG images but not write them. I can fix that with this other library, but that’s linked to another rotten library.
So every project would begin with a day or so of trying to find a set of libraries that would play well together. It’s not fun.
But here in Unity land, it all just works. I can drop my atlas code into a new project and have it instantly begin working.
You can see where the love / hate relationship comes from. On one hand, I get access to the C# language of simplicity, code reuse, as well as the Unity ecosystem of types and tools. On the other hand, I have to struggle with the limitations of using a proprietary engine with frustrating holes in its documentation. Sometimes I really miss the power and speed of C++, but ultimately I think my own laziness is stronger than my desire for perfection.
 Blender lets you flip the normals, turning the object inside-out. But this doesn’t fix it. It’s like no matter which way the polygons face, Unity insists on making them backwards.
 Seriously, I think SO should adopt a policy of “If the answer is simple, then just answer it yourself rather than being a smartass and posting a link. Links die, and questions on this site do not.
Top 64 Videogames
Lists of 'best games ever' are dumb and annoying. But like a self-loathing hipster I made one anyway.
Mass Effect Retrospective
A novel-sized analysis of the Mass Effect series that explains where it all went wrong. Spoiler: It was long before the ending.
What is Vulkan?
What is this Vulkan stuff? A graphics engine? A game engine? A new flavor of breakfast cereal? And how is it supposed to make PC games better?
Please Help I Can’t Stop Playing Cities: Skylines
What makes this borderline indie title so much better than the AAA juggernauts that came before?
The Witch Watch
My first REAL published book, about a guy who comes back from the dead due to a misunderstanding.