Thread by @delaneykingrox

Today's #gamedev #gameart lesson is about setting up your base import/export workflow.

The first thing you need to do before you do anything else is set up a working environment between your applications that allow you yo import and export back and forth as smoothly and easily as possible.

For most new artists that starts with scale.

Each 3D application, file format and game engine vary in a few basic foundational things- scale, orientation, axis and (more complicated but also Uv and normal tangent space).

You would think we would have unified all this a long time ago, but one thing I can tell you...

..about programmers is they love to do things differently to other programmers.

Thus, everything is a bullshit mess that makes the VHS/Betamax video format wars seem like a lovers spat.

So to untangle all this mess, artists have to convert data back and forth with just the right settings, or shit gets weird.

*sigh* thanks programmers.

Fortunately, once you have done this a few dozen times it becomes second nature to set up your 'environment' in presets.

Scale is the first challenge, and it isn't trivial. This is because of two absolutely fucking stupid decisions that applications make. I shall call these 'ZFuckery' and '.001, license to scale"

So, in general you start with setting up the export scale to and from your 3d app to your game engine.

Ask yourself..

In Unity, 1 'unit' represents...?
In Unreal 1 'unit' represents... ?

1 meter? 1 cm? 1 km? 5 feet?

In general, you want to use the prescribed engine scale, as all the physics stuff will default to that.

Tricky when your game is a space battle simulation with 5km long ships. Or you are a microscopic nanobot fighting viruses.

Once you know what that side is, you want your 3D app set up to spit out files with the matching scale AND set up your engine to import at that scale.

Not always trivial, especially because of ".001, license to scale' which is what some importers do by default on some format.

This is due to an older cad app using mm by default, whereas the game wanted it in meters.

So if your models come in at 0.001- that fuckery is at play.

This all goes swimmingly once you finally get a 1 unit object in your 3D app into your engine as a 1 unit model.

And your transform is

Position (translation): 0,0,0
Rotation: 0,0,0
Scale: 1,1,1

Which is absolutely the only result you want on an import.

Buuuuut enter the ZFuckery.

You see, Zbrush is based on some assumptions. Really nasty ones.

One of these is object pivots based on their bounding box. Uhg.

However the main one is that it wants your model to be a specific scale, because the tools are designed to only...

...work within that limited scale.

Oh shit.

Yes.

Oh shit indeed.

So when you import a model into zbrush, it forcibly scales the object to its tools don't blow up. This is called the scale factor, a number you can find buried in the tool settings.

When you export, your model is scaled, and requires unscaling by applying that scale factor. If you lose this number, well, fuck you.

To work around this, I use a script called Styx, which pulls in and out geo in the exact scale and place.

So, what this means is you may have to have a game mesh, a high res zbrush mesh and a low poly bake mesh that is a totally different scale and position to your game mesh.

That's okay but it means tweaking the bake mesh doesn't update the game mesh and vice versa

There is another fucking dumb programmer decision in zbrush which has been patched over with sticky tape.

Z brush natively has the UV coordinates upside down to absolutely everyone else. This is hidden in the export settings now, but for years it was agony for us.

As we had to flip stuff upside down and invert normals etc.

Uhg.

I had an arguement with the developer over it and it was clear that he wanted "mathematically correct" over "not a fucking nightmare to use".

The issue comes from a basic problem with cartesian coordinates. That is, are we talking left hand or right handed?

Or when you point forward with your index finger, thumb up, which direction does your middle finger point? Left or right?

Okay gotta fly nowz airplane mode on. Finish later x

The next problem this causes is axis.
3d apps started as CAD programs, which focused on extruding plans upwards therefore X and Y are horizonal along the ground plane, and Z would be height.

3dsmax comes from this field, so is a "Z UP" program.

Maya is a "Y UP"

Y up comes from animation- where your curves make more sense if you think about a ball bouncing along. X is horizontal, Y is up.

It is animation shot based.

Most things are Y up now, which makes things confusing for level editing, but better for animators.

So when we export, we have to convert not only which way is up, which handedness our coordinate system is, and what we mean by saying something is 1 unit big.

Its a three step process:

3dapp > file format > game engine

File formats for importing are usually FBX now.

Allembic, Collada, Obj etc etc all tried to unify export file formats to make things easy.

Aaaand it didn't really take off as Autodesk had a monopoly and wanted us to use filmbox FBX.

So we have an industry that doesn't agree what way is up. Literally. And that does for normal maps too as Direct X and Open GL disagree on if the green channel should be 0 = down and 1 = up or... weirdly, 1 equals down and 0 equals up.

So, you see, every application you must be set up for the correct method, otherwise models come in flipped sideways, upside down, inside up with their face on upside down and inverted.

Because programmers like to do shit their own way and nobody agrees.

So, taking a deep breath, the very first thing you want to do is get a 1 meter cube to do a full round trip.

3d app -> export -> engine -> export -> 3d app.

Simple right? Well, it should be. But see all the above.

Fortunately one thing IS consistent these days... nearly... and that is tangent and binormal spaces.

What does this mean? Well, in simple terms, normal maps look funny if you calculate these differently.

Which all programs, of course, did.

Thus normal maps baked in 3dsmax looked funny in maya, or unreal or Ids doom engine or whatever.

MiKKT space is basically a standardised format for binormals and tangents and most apps use this now.

Substance painter, Unreal and Unity, for example.

Again, it is rare that programmers agree on doing things someone else's way. They are special butterflies.

*sigh*

Artists lose a lot of sleep because of this. A lot.

So its nice that we don't have to even know what a tangent or binormal is...

Uh... unless you do, because the file format you are saving to doesn't support mikkt space or you set something wrong.

Okay, so you have your cube round tripping. Nice. Scale of 1 all the way around? Great.

Now you need a human model to set your scale.

I usually make my first character 2m high. This isn't normal human sizes, but it makes the maths easy, and ensures that doorways are...

Always clear... but you do you on this one.

Make a posed scale model of a typical character or ship and get that in. This will be used to test and tune everything. A braindead way to check your import is the right scale is to whack it next to this character.

Having a facing character now throws you into yet another orientation issue.

Is "front" looking at a characters face in your 3d app, or the way they are facing?

Epic uses X forward for facing of characters, for example. Others use -Z.

Is anyone else exhausted just reading this?

Yeah, game artists aren't just about making pretty things. We do have to actually have a level of technical brain... er... braining stuffs, thingies to do our job.

*glares at programmers*

So in conclusion, up is not up, forward may be sideways, nobody agrees what green means and if you don't get all your settings right the world is topsey turvey and your characters glove is fifteen kilometers big (and upside down).

Yay.

And both all apps keep forgetting your defaults so you have to keep setting them.

So checklist:

Agree on what 1 unit means in engine.

Agree on what 1 unit means in 3d app.

Check zbrush doesn't lose it's precious shit over this scale.

Set up your units in the 3d app to match this, so if 1 unit = 1 meter, your sliders should all be in meters or centimeters.

Set up your grid scale to match.

Export both ways, so ensure that any geo you make or arrange in your game can be spat out into the 3d app.

This is called a "round trip", and ensures you can build things in either app and then finish them in the other.

For example, a level designer places lots of grey boxes for a fallen temple wall in a scene, you want to be able to bring those into your 3d app to make the asset

Having a 1 to 1 all the way around means you can back and forth without introducing errors in scale and placement.

Next check your game engine for direct x or open GL. This will determine your normal map Y orientation, and that needs to go into substance, substance designer and whatever you use to bake maps (marmoset, substance, crazybump, xnormal etc).

And finally you need to sort out what your UP and FORWARD vectors are, and which way your engine winds (left hand or right hand).

This is usually set in the exporter, so the FBX points the way the engine wants it. I haven't seen many importers with orientation options.

So now let's talk about exporting materials.

Uh, look, basically? Don't.

You can pretty much guarantee that the way your model looks in your 3d app will be sod all like your game engine. It will use completely different lighting models, color standards and shader languages

Any time you spend setting up clever materials in your 3d app will have to be doubled up by recreating it in your game engine.

In my experience, getting your asset into the engine and working on the material there is always the fastest method.

You can make a simpler version so that animators can get a feel for the character, but any real time sunk in here on refining the look and feel of a material will be wasted.

Substance painter also uses a different lighting model to most game engines, so again, the quicker you get the asset in place in engine, the better you will understand what your end result will be.

Trying to recreate the look in all 3 is great, but nothing beats the end result

I am Delaney King, and I am not overweight, I was just imported into this world at the wrong scale.

Support my tutorials by importing money into my account via the koffee format.

I am upside down.

ko-fi.com/dellak