Project Bug Hunt #7: It Works! (Kinda.)

By Shamus Posted Tuesday Nov 10, 2020

Filed under: Programming 61 comments

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?

A Lot

Let me count the ways…

1. It can’t handle multiple textures on a single model.

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.
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.

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:

  1. Take Blender’s Z value and assign it to Unity’s Y.
  2. Take Blender’s Y value, multiply by -1, and assign it to Unity’s Z.
  3. 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.

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.
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.

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 tried making sleeping pods like you'd see in Prey / Deus Ex Human Revolution. So far nobody was able to recognize them as such.
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.

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?

Code Reuse

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.



[1] 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.

[2] 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.

From The Archives:

61 thoughts on “Project Bug Hunt #7: It Works! (Kinda.)

  1. Vertette says:

    Unity’s importer should absolutely be able to handle models using multiple textures. How weird that it doesn’t work for you.

    Those models look good either how.

    1. Richard says:

      Unity’s FBX importer handled both multi-texture and normals Just Fine (TM) for my last project.

      Perhaps that’s a specific limitation of Unity’s importer for the Blender format? I know Blender have changed their format several times over the years, so perhaps Unity hasn’t properly kept up.

      (Of course, having done that I then ripped out nearly all of the prefabs because I realised that I actually needed to load them at runtime for easier and better modding.)

    2. Liam says:

      My projects have had no issue with multiple textures coming from 3dsmax. Sounds like it’s an issue with blender’s implementation of FBX.

      There’s a variety of options when importing models to do with texture handling, perhaps the wrong option is selected there.

      1. Shamus says:

        For the record: FBX files are not involved in my project.

        These days Unity reads .blend files directly. (Aside from the shortcomings I complained about.) According to forums / threads / randos, this is the preferred way of doing things these days.

        1. Liam says:

          That would explain why my anecdotal evidence doesn’t apply here then!

          I haven’t tried blender for many years (I absolutely hated the UI when I did)- perhaps I should try it again

  2. Knut says:

    The models look good, but I think your sleeping pods should be longer (or less tall). The ratio seems wrong. The photocopier is on point though.

    1. John says:

      Honestly, the sleeping pods look more like a big TV to me. I think it’s that there are two stacked on top of each other and that the door on the top one is closed and looks a bit like a blank screen. If I look for more than split second I can tell that it’s not, but my first impression remains “that’s somebody’s entertainment center”.

      1. ContribuTor says:

        I think the problem of the sleeping pods is more context than content.

        In the one screenshot of them, the open one (at least) is somewhat recognizable as a bed. If it read better, I might even assume the upper one was a bed too (though I don’t see how someone would get up there…)

        But it’s sitting here in the corner of a big metal room. A tall room. Why would people be sleeping here? Why only two people, on a big empty wall between two random ferns? Did someone design this as a sleeping space? If so, why is the ceiling too tall, the wall too wide, and why are there only 2 bunks? If this isn’t a main sleeping space, why do we need two people to sleep here? Do we not have proper bunk rooms? If not why not? Do people need to nap while on duty in this space? Why have people sleep in a space that’s presumably used for other, possibly noisy things, when you could design a purposeful space for sleeping?

        That’s not necessarily a rhetorical question. A submarine has space so at a premium that people sleep wherever there’s unused space. There could be a world where people sleep wherever. But that’s clearly not what’s going on in this room.

        In a different room with more reasonable dimensions and better density I think this would look fine. Admittedly, that’s sort of at odds with Shamus’ procedural world goal.

        The related issue here is that these don’t look remotely “lived in.” There’s nothing that indicates this is someone’s personal space. That this space is used frequently. That someone has some gear/clothes/personal effects that are nearby. Again, to me, this is the sleeping pods being out of context.

        1. evileeyore says:

          Exactly. I recognized the bottom pod as a sleep pod immediately, but the context of the scene keeps making me want to reject it.

        2. Echo Tango says:

          There’s a ladder on the side, to get to the top. Usually, I think those ladders are in front of the lower pod, not completely to the side of it. You could still make pods like this, but it would be a lot more hassle, trying to lean to the side that much off of a ladder.

    2. Steve C says:

      Sleeping pods? Do you mean the man-sized double oven?

      1. Benderson says:

        I also saw a huge double oven! I think the 70s kitchen linoleum on the wall helps.

    3. Paul Spooner says:

      Agreed that the proportions and size seems off. If the camera is at eye height, then those beds are toddler sized. Maybe this is the Space Creche room?

    4. The Wind King says:

      Agreed, they’re either far too short, or far too tall, otherwise I’d be trying to squeeze another pod into that “space”.

      Also one of my main questions, as a pre-sleep reader, do sleep-pods come with a connected tablet / screen mount that allows their occupants to lay in “bed” and entertain themselves?

      1. Paul Spooner says:

        When I want to watch media lying down, I usually borrow one of the kids’ lower bunks and wedge my phone in the support slats of the upper bunk.
        But when I stayed in a real sleep pod in Singapore, it didn’t have anchoring features on the upper surface. Hopefully these sci-fi designers will get their A-game on.

    5. Decius says:

      The ratio is definitely wrong, none of the dimensions of the sleeping space jive with the potted plant, and the idea of having a maximally compact sleeping space in that room doesn’t work.

      Submarine racks are about 2.5 feet wide, about six feet long, and have about three feet of vertical space above the mattress: Not enough room to stretch out, curl up, or roll over.

      Presumably sleeping pods would be slightly larger, but they need to be about four feet wide and four feet ‘tall’ to allow a person and bedding to lie down and roll over (more if it is more than just a sleeping space), and any room that they are in needs to use all of the space in it for practical purposes.

      That particular design makes me remember Prey or maybe Mooncrash; The sleeping pods from Deus Ex had the smaller profile pointing into the hallway IIRC, which is probably slightly more space-efficient in that there is less hallway space per pod and the pod can have the same volume. Putting the beds in longways makes sense if the area in front of them is being used as a room, and not just a hallway, which is what I remember from both art and life.

  3. kikito says:

    > The proper solution would be to have Unity break the object apart on the way in

    Alternative: Unity could combine all the textures onto a single one, and remap the coords (with some sort of warning).

    > Sometimes I really miss the power and speed of C++, but ultimately I think my own laziness is stronger than my desire for perfection.

    I would never equate C++ with “perfection”, on any scale, ever. Laziness is a good programmer trait.

    1. pseudonym says:

      Yes, laziness is the best. At my work we have one software package that was made by someone who loved coding. He was also very intelligent and able to understand complex intrerconnected structures. He also had a healthy work ethic. The result was a complex piece of software with many interconnected parts. Nobody fully understands it and maintaining is no fun. (The original author left).
      The nicest software always has developers that want the code to work for them and not the other way round.

      1. Echo Tango says:

        I’ve experienced situations like this a few times; Oof.

      2. King Marth says:

        It’s programming when ‘clever’ is a compliment. It’s software engineering when ‘clever’ is an insult.

        You can do marvelous things with code under unreasonable constraints, but the level of context and assumptions you have to make means that those ‘clever’ solutions are terribly brittle. If the code needs to last longer than a month, then don’t write something unless not only you but also anyone else can look back at it later and figure out what’s going wrong when conditions change. Alternatively, if you want both, join NASA; all the fun of ridiculous workarounds to squeeze functionality out of ancient hardware with all the rigor of code that absolutely must not break no matter what, both driven by how the computer you’re working on was shot into space years or decades ago and is expected to keep running for more years or decades without anyone turning it off and back on.

        The three great virtues are Laziness, Impatience, and Hubris. Laziness, to do the minimum amount of work over time for a given result. Impatience, to write programs that don’t waste your time. Hubris, the pride-offending-the-gods driving you to not only do great things but do them well enough to boast.

        1. pseudonym says:

          Well said! I am going to share this with my colleagues.

  4. John says:

    In Unity, the X axis is left/right, the Y axis is up/down, and the Z axis is forward/back. In Unity, the X is still left/right, but the Y axis is forward/back and Z is up/down.

    I assume that you meant Blender in one of these instances, but for all I know this could be a trenchant statement about just how screwed up Unity is.

    1. Ziusudra says:

      Based on the next paragraph, the second one is Blender.

      1. Richard says:

        There’s basically four options in general use for position coordinate systems:
        Y or Z Up, Left or Right-handed

        Blender is right-handed, Z up, while Unity is left-handed Y up.

        Converting position is pretty easy.

        But then there’s rotation.
        Rotation is simple enough if the format stores orientations as quaternions or the whole thing as an affine transformation matrix.

        But those formats aren’t very people-friendly. People quite like Euler (or more usually Tait-Bryan) angles – rotate around X, Y, Z.

        And then it becomes very, very messy:
        – Are these angles clockwise (right-handed) or anti-clockwise (left-handed)?
        (Point your thumb towards positive direction, fingers are positive rotation)
        – Which order? You can get very different results if you do them X, Y, Z or Z, X, Y. (Unity is ZXY)
        – Are the rotations from the POV of the object begine rotated, (‘flying a plane’, Intrinsic/Tait-Bryan) or from its parent (Extrinsic)?

        Pretty much everything uses Intrinsic (Tait-Bryan), but some… well some things don’t.

        1. Decius says:

          The format that the rotation is stored in need not be the format that people interact with- computers are really good at math, and can do matrix multiplication on floating point numbers in less time than it takes to display the results.

          1. Richard says:

            Sadly several 3D formats genuinely do store as Translation, Rotation, Scale with Rotation as eulers.

            The reason is usually animations, as it’s easier to define a spnning animation in terms of degrees (or radians) per second.

  5. Geebs says:

    Unity then covers up this crime by taking this newly-created model and manually rotating it forward 90 degrees on the X axis.

    This is exactly the sort of thing that seems innocuous to the layman, but to anybody who has ever written a 3D model importer or has experience of the bizarre and unintuitive effects of sequential rotational transformations*, this particular decision falls into the category of horrifyingly irresponsible design choices which can only be attributed either to extreme incompetence or extreme malice.

    * anything which makes learning quaternions seem like a reasonable solution is basically the geometric equivalent of the Devil.

  6. Mezentine says:

    “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.”

    I’m really really interested in this code. Is it a seperate script that you just run whenever you want to regenerate the binaries, or does it run every time you launch the main executable. Did you have to use the Blender documentation to understand all of the Blender file format info for conversion into your binaries, and was there corresponding good documentation in Unity for how to turn your binaries into Unity models, or is it much more basic then that, and the fundamentals are so “baked in” that you could just run model-generation code in Unity and have it work?

    1. Shamus says:

      It’s possible to make scripts with run within the unity editor. This is SUPER helpful.

      Like, I have the code that generates the level and places all the crap in it. Sure, I could launch the game and wait for the 2-3 second start-up time to get the “game” going, but I can just have Unity run that same code and dump the contents in the editor window.

      Or in the case of my atlas / model library, I hit a button to rebuild these when I add a new model / texture.

      In this case, that means I can wait those 1.4 seconds on MY end, so the end user (if there ever was one) wouldn’t need to wait for it when launching the program.

      1. MaxEd says:

        Did you try to profile the script? Did you call AssetDatabase.StartAssetEditing() before starting the work? If you didn’t, this helps very much in some cases.

        BTW, I can’t plug JetBrains dotTrace profiler enough – it’s an awesome tool for finding CPU usage problems in Unity. Yes, it costs quite a bit, but it so far superior to Unity’s own Profiler. Unfortunately, dotMemory doesn’t work with Unity, but I’m working on my own solution to analyse memory usage in Unity and hope to release it in a month or two.

  7. GoStu says:

    What I think is happening with the “sleeping pods” and nobody recognizing them as such is that it’s a bit of a confusing perspective.

    Assuming the camera is taking a picture from about eye level (~5 foot something up for most people), and mentally defaulting to thinking that this room the pods are in has a typical-ish ceiling height of about 10 feet, then those beds look like they’re about three feet long.

    If I work backwards and take the beds as “a little over six feet long” and scale from there, then this ceiling looks like it’s very tall, more like ~24 feet. The camera is placed rather high to convey the scale of this room. Taking the shot from about eye level and looking up might help it click better.

    1. Erik says:

      I think you’re right about the false perspective, but I think another culprit is the potted plants on either side. The width of the pot is approximately the width of the bed, and the bed is 3x as long as it is wide. My brain assumes a potted plant (NOT a tree, it’s just leaves) is about a foot-ish across, which means the beds are 1×3, which means they aren’t beds. If the pots had trees in them, or were half the width, the bed would look more like a bed.

      But the fact that a double bunk only goes halfway to the ceiling also violates our assumptions that a room is sized to be about 8-10 feet tall (2.5-3 meters). The lower mattress is also very low; beds try to be at least normal knee height to make it easier to stand up when arising.

  8. Dude Guyman says:

    For what it’s worth, you can change the coordinate system when exporting a model from within blender. It’s on the right side of the export window, underneath ‘transform’.

    1. Ultrapotassium says:

      Shamus explained in another comment that Unity can now read .blend files directly and that is the “preferred” way. But you’re definitely right that if you’re exporting from blender to some intermediate format, there are ways to fix the problems with importing to unity.

      1. Pink says:

        I believe that that is not actually the preferred way, but rather an unsupported feature left in for compatibility reasons. Unity recommends import from blender via fbx.

  9. Zach Hixson says:

    Shamus, I really think you should try Godot at some point. I’m not saying that just because it’s free or open source, but because as a programmer myself, I felt that it was the most “Programmer friendly,” engine that exists.

    – It’s small and lightweight
    – The way the program and projects are structured feels more like how you would structure source code. Instead of being “Made for game designers,” it feels more like “Made by programmers for programmers.” You have both high and low level access to a lot of things.
    – Open source and very easy to compile your own builds. Compiled it myself from scratch in around 5 minutes (not counting the 5-10 minute build process) with no dependency hunts.
    – Supports C#, C native modules, as well as it’s own Python-esque language.
    – It’s similar enough to Unity where you should be able to pick it up in no-time, but different enough where it’s not a clone.

    For an actual game, I’d be torn between Unity and Godot, but for random-ass programing projects/experiment things Godot is my goto

    1. Rob says:

      Speaking of Godot, they put up a perfectly timed blog post a few days ago about rewriting their model importer because the existing open-source libraries were so terrible and non-compliant.

      1. Richard says:

        That does explain why they suddenly vanished from the Assimp project last year.

        Shame, they’d put forward a lot of very useful corrections to FBX.

      2. Zach Hixson says:

        Oh cool, I missed that post somehow. Happy to see more projects taking a crack at FBX since it’s been kind of a PITA to OSS for so long.

    2. Zach Hixson says:

      EDIT: I meant to say C++ Native modules, not C

  10. Eric Fletcher says:

    Re: sleeping tubes
    Reminds me of that song “If you like sleeping in microwave ovens”

  11. Paul Spooner says:

    Shamus you’re such a tease! Little snippets of corners of rooms and pieces of pipes. You’ve got it all working now, don’t you? Are you just drawing it out now?

    Also, I really hope those access panels in the wall are operational.

  12. Kenny says:

    From note [2]:

    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.

    This is the actual policy but, because of the particularly extreme Eternal September with which SO is cursed, almost no one actually knows any of the policies except for those brave enough to descend into the Meta SO underworld.

    ‘SO sucks’ is such an interesting topic, especially because so many different kinds of people think it’s true but for very different reasons!

    1. Echo Tango says:

      Yeah, there’s lots of different problems you can run into on StackOverflow (or the sister sites), depending on which question you’re looking at. Poorly-phrased questions or answers; questions so specific that they’re useless to most other people[1]; questions that only include one line, or only a partial line of error-text, without the rest of the error dump; answers that are marked correct but are actually hack-jobs that only work on specific version of libs/software/etc, and there’s a better answer that’s been upvoted a tonne, but the original asker has moved on already. Then there’s the stories I hear about the social/political drama, with bully users who happen to have a lot of credit from older answers> I even had my answer not accepted for a question initially, since someone else with higher credit answered first. Luckily, they were one of the good ones, and later requested that my answer be accepted, because it was more detailed and they had only dashed out a short reply in their initial answer. :)

      [1] I’ve got library X (version vX), framework Y (version vY), and am writing in language Z (version vZ). That’s technically useful to someone else, but it’s very unlikely.

  13. Jamie Pate says:

    godot supports c# !
    you could probably re-use (some of) your stuff
    … just saying

    Also atlas is built in?

    And it allows multi-material meshes.

    Contributing to the open source engine, the ultimate code reuse :D

    Also GLTF2 is the best format so far for importing to godot, does unity support that? It seems like a decent standard..
    hey here’s one that’s open source :D

    but it seems like it’s a WIP

  14. Olivier FAURE says:

    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:

    [List of annoying problems when using C++ libraries

    This is one of those situations where I have to recommend Rust again. The dependency management is really good.

    First because the language comes with an official repository and package manager, like all modern languages. Which means you don’t need to worry about complicated installation procedures, or breaking your project after two months because you wanted to update a dependency.

    Second because the language is memory-safe, which means crashes are extremely rare, and when they do, package maintainers are usually pretty quick to fix them.

    The ecosystem is still immature, so a lot of packages might be missing, but the ones that exist are usually pretty well documented, have active participation, etc.

    (but it’s still going to be harder than using a ready-made engine like Unity or Godot)

    1. Echo Tango says:

      Seems promising. There’s at least this one 3D engine, plus another website dedicated to listing libraries for all kinds of things needed in game development. :)

      1. Philadelphus says:

        There’s also the Bevy Engine, though it explicitly notes that it’s still in active development and not quite ready for serious use yet.

        I’ve been idly teaching myself Rust lately—wrote my first program in it over the weekend—and have been musing about playing around with some game development at some point, so I may check out Amethyst in the future.

    2. Leeward says:

      I think rust is going to catch on in a big way, and look forward to being able to use it for work. That said, I would not recommend it for hobbyists. While it’s better in a lot of ways than C++, it’s still at least as complicated.

      The borrow checker solves a problem that, for many people, is pretty far down their priority list, and does it by being very needy. Learning rust is an exercise in frustration, particularly for people who haven’t been exposed to a lot of modern cs concepts from fp.

  15. JT says:

    Unity rots, too, especially if you rely on third party assets from the asset store.

    1. tmtvl says:

      Pillars of Eternity cloaks. PoE2 and Pathfinder: Kingmaker sound. P:K, Gone Home, After Reset,… input. There’s a litany of never-gonna-be-fixed Unity bugs.

  16. il says:

    What format were you using to save models before? Unity support for any model format that isn’t FBX is patchy at best. If you’re using OBJ, it won’t import anything aside from the base geometry reliably. That would explain why the normals are vanishing. (To be fair, this can be partially explained by there being so many random extensions that aren’t part of the standard.) If you’re using DAE, it has a good chance to crash and burn as the importer is somehow even flakier than OBJ. If you have .blend files saved out of Blender, it will actually open Blender in the background and export them to FBX, which adds a lot to the export time.

    This kind of knowledge that shouldn’t be obscure (but somehow is) is a huge problem with Unity. Combined with the mounds of outdated and irrelevant information – forum posts from 2010 with hopelessly out of date info, people who never get told “xyz is built into the engine, you don’t need to make your own system for that”, and things that just don’t get written down…

    And I don’t really see things getting better. It sucks.

  17. Khizan says:

    The sleeping pods look off because the proportions look off. They’re not long enough for their height. I’d expect a sleeping pod to roughly correspond to the size of an adult human. A Japanese capsule hotel has capsules that are roughly 1m x 1.2m x 2m, which is a good rough measurement to go by. Call it a 2:1 length/height ratio. Doing a bit of quick and dirty measuring in paint and ignoring the perspective changes, the pod that you made has a ratio of about 2:1.5, which makes it look strange. If it’s tall enough for a 6 foot man to sleep in, it’s about 4’6″ tall. If it’s a more reasonable 3 feet tall, it’s only about 4 feet long. The proportions just don’t say “bed”.

    The potted plants also affect this, because people tend to think of potted plants as being relatively small, but if that bed is tall enough to sleep an adult, then that plant would have to be about 5 feet tall and it doesn’t look like a 5 foot tall plant.

    TL;DR: Make them shorter and stretch them out a bit and I think they’ll be way more recognizable as sleeping pods because the proportions will be more suited to the human body.

    1. Falling says:

      I think it’s the potted plants, plus the high ceiling. Both combined together makes it look about big screen TV size. When you realize that it’s a bed, then you realize that the plants are human height, and THEN you realize just how tall the room is. I’m probably off in my estimate, but it must be about 20 feet high.

  18. Radkatsu says:

    “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.”

    As others have mentioned, the perspective and dimensions are off. I saw those potted plants and the bunks between them and immediately thought ‘oh cool, he’s got a vending machine in the hall, maybe that’d be a good upgrade dealie for the player…’

    Then I read the caption ;p

  19. Thore says:

    Hi everyone. I know this is kind of not related to the topic, but i thought id ask here, since the forum is down.

    Does anyone know, if Mrbtongue is still active somewhere? I always enjoyed reading his stuff/watching his Videos.

    1. Paul Spooner says:

      I don’t know, but figured I’d respond anyway. I have no evidence that he is actively inactive. That is, his activity, even when active, has been sporadic at best.
      My best guess is his cyberpunk video landed him a beta copy of CP2077 and that’s keeping him busy.

  20. Noumenon72 says:

    You’re complaining about 1.4 seconds? My `ng serve` started giving me 20-second pauses and I didn’t go looking for help until they started happening every five minutes.

  21. Smith says:

    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.

    It’s a reployer from Prey 2017.

  22. Pink says:

    Unity has officially suggested using FBX to export from blender for years now, and I believe as of 2019 LTS have even removed direct support of .blend files from the docs.

  23. Rohan says:

    Why model the pipes by hand? That seems like the sort of detail that should be getting built by a procedural system. Not to mention the procedural system could be made more flexible than using a bunch of hand-made models. Hell, with the right constraints, it could come up with some wonderfully convoluted workarounds to annoying situations like misaligned holes on the floor and ceiling.

    Imagine some frustrated colonists having to put in a pipe from floor to ceiling, only to find the ceiling hole is 10cm to the left of the floor hole and all their right-angle joints result in putting the end 20cm off to the side. They’d end up with this crazy loop of right-angle joints and a 10cm length of pipe in the middle just getting that working. A human designer wouldn’t waste time on that, just making the holes line up and using a straight length of pipe, but with a procedural system that works with pipe widths, joint constraints, and areas it’s not allowed to place pipes, it could make that in a fraction of a second.

    Could be the subject of an annoyed log. “Those idiots at Planetcorp bungled the alignment of the floor and ceiling holes for the wastewater pipe in Section D4. We don’t have any suitable joints to get them connected neatly, and cutting the ends of the pipe at an off-angle would result in leaks, so Rick cobbled together this mass of spaghetti from half a dozen elbow joints. It’s one hell of an eye-sore, but at least it seals correctly.”

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply

Your email address will not be published. Required fields are marked *