{"id":51107,"date":"2020-11-10T06:00:47","date_gmt":"2020-11-10T11:00:47","guid":{"rendered":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=51107"},"modified":"2020-11-10T07:05:40","modified_gmt":"2020-11-10T12:05:40","slug":"project-bug-hunt-7-it-works-kinda","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=51107","title":{"rendered":"Project Bug Hunt #7: It Works! (Kinda.)"},"content":{"rendered":"

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<\/b>, I had to make my own importer, because the built-in Unity importer is a hot mess.<\/p>\n

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.<\/p>\n

Hey, it’s been ages since the last Terrible Car Analogy, so let’s do one of those:<\/p>\n

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.<\/p><\/blockquote>\n

So what’s wrong with Unity’s code to import Blender models?<\/p>\n

<\/p>\n

A Lot<\/h3>\n

Let me count the ways…<\/p>\n

1. It can’t handle multiple textures on a single model.<\/b><\/p>\n

I guess this is supposed to be a space-photocopier? I don't know. I love 3D modeling, but I'm not particularly good at 3D design.<\/div>
I guess this is supposed to be a space-photocopier? I don't know. I love 3D modeling, but I'm not particularly good at 3D design.<\/div><\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

2. It doesn’t properly translate coordinate systems.<\/b><\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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:<\/p>\n

    \n
  1. Take Blender’s Z value and assign it to Unity’s Y.<\/li>\n
  2. Take Blender’s Y value, multiply by -1, and assign it to Unity’s Z.<\/li>\n
  3. That’s it. You’re done.<\/li>\n<\/ol>\n

    So I lied. It’s trivial. Literally one line of code:<\/p>\n

    unity_vert = Vector3 (blender.x, blender.z, -blender.y);<\/pre>\n
    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.<\/p>\n
    But wait! It’s worse!<\/p>\n
    Unity then covers up this crime by\u00a0 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?<\/p>\n
    3. It messes up the surface normals.<\/b><\/p>\n
    On the left and right, you see  the tubes are lit from the right, dark on the left. The tubes in the center have bad normals and thus their lighting doesn't match what's going on in the scene.<\/div>
    On the left and right, you see  the tubes are lit from the right, dark on the left. The tubes in the center have bad normals and thus their lighting doesn't match what's going on in the scene.<\/div><\/p>\n
    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.<\/p>\n
    I’m not 100% sure what causes this, but as far as I can tell, Unity hates<\/b> 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.<\/p>\n
    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.<\/p>\n
    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<\/b> on making them backwards.<\/span>.<\/p>\n
    4. The Unity importer is shamefully slow.\u00a0<\/b><\/p>\n
    I tried making sleeping pods like you'd see in Prey \/ Deus Ex Human Revolution. So far nobody was able to recognize them as such.<\/div>
    I tried making sleeping pods like you'd see in Prey \/ Deus Ex Human Revolution. So far nobody was able to recognize them as such.<\/div><\/p>\n
    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.<\/p>\n
    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.<\/p>\n
    Then when it’s time to run the game, it loads in all of those binary files. That part takes 0.004 seconds.<\/p>\n
    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<\/b> 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.<\/p>\n
    So here I am, bitching about Unity again. If I hate it so much, why don’t I embrace one of the many alternatives<\/a>?<\/p>\n
    Code Reuse<\/h3>\n
    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.<\/p>\n
    The good news is that a lot of this work was already done for me. Two years ago I made a thing<\/a> 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<\/a>. I was able to drop both of these complex systems into this project and make use of them with only minor changes.<\/p>\n
    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.”<\/p>\n
    My problem is that code reuse is really hard when you’re trying to do graphics within barebones C++.\u00a0 In C++ you often find yourself in situations like this:<\/p>\n