Question Coders: how do I prepare meshes, armatures and animations for you from Blender?

I don't think I'm going to become a 5-star programmer any time soon, so instead, I think I'm going to focus more on the stuff I actually excel at professionally, which is design.

I like building and animating in Blender, and I have very little experience with Unity.

If I want to design a character that can jump and cling to walls, or a snake-like NPC that can respond to player inputs, how should I structure the armature and animation components in Blender so that you can easily work with the models and animations and get to implementing the player controls after importing the .blend file into Unity using C# for a mobile game?

These characters/creatures could have any number of features, like a walking/crawling animation, a picking-up-items animation, eating-stuff animation and so on.

In Blender I'll often animate with IK controls for an armature, and also have a singular root bone that controls all subsequent IK components too. Are these relevant to Unity coding?

 

Search this guys back playlists... he makes and exports tons of animated characters from various versions of Blender to Unity...

Imphenzia: How Did I Learn To Make Games:

 

Thanks for the info. I see a lot of "Let's make <insert> in 10 minutes!" videos on their profile, is there perhaps something more specific you had in mind?

 

As i said above, SEARCH his playlists based on what you mean by this:

Remember I have ABSOLUTELY NO IDEA what you know or where you are starting. Go search.

 

I spent several hours watching tutorials on constructing a level in Unity. They didn't help answer this question. So "go search" unfortunately isn't a viable answer when you have something specific in mind. I think someone with a lot of experience in using imported meshes could answer a question like this though.

 

When you have something specific in mind, you're always gonna have a hard time finding someone who knows what you need.

The other problem is that YOU don't even know what you need. You have only barely described it here.

Just... barely:

Defining it will come as you implement.

That is the actual WORK you have to do

It's like insisting I explain to you how to make an aircraft carrier. No.

 

Okay, I'm going to stop responding to you since I've both described what I'm looking for and know what I need, and you seem to have this weird hostile attitude for no actual reason.

An experienced programmer wouldn't struggle to tell what they need from a designer/modeler and animator to control a walking rigged humanoid character. They may want IK controls, they may not. They may want disjoint bones, or parented bones. Either way I'm prepared to work with what they're looking for, but unless someone defines what they're looking for, no game is ever gunna get made.

 

The last time I worked with animated models, you just make them the normal way, except: it's nice to import it to Unity, slice up the animations in Unity, possibly fix the scale, set up materials, and then (this came after my time) humanoids should maybe be set up how Mechanim (a GUI tool, which is not code) wants them.

Things not to worry about: bones in a modelling program are usually made with parent/child relationships -- for example the hand is a child of the forearm is a child of the upper arm. Importing into Unity will keep those same relationships, which is what it expects (Unity was made to handle normal models made the normal way). IK can't be exported. If someone wanted that in Unity they'd use the one mechanim provides (which I think merely assumes it's set up the mechanim way) or they get a package (which probably also takes any "standard" model). So worrying about IK isn't a thing. I think most models in modelling programs are made with an extra empty parent (on the ground in the middle). Unity uses that same trick, so no changes there.

The changes I mentioned: Unity will take FBX files. This lets you use models that weren't made specially for Unity. But it it's for Unity, may as well import it. Animations are often made in one big piece, where frames 1-30 are walk, 31-70 are run, and so on. Unity likes these manually entered into animation slots (entries such as ["walk",1,30]). Those numbers aren't exported and it's a pain playing the models and figuring them out, then tweaking them to get a nice cycle; so making and testing that is what I called "slicing up the animations in Unity". Next, modelling programs often use 100 units = 1 meter, which is 100 times to big for Unity. Anyone can fix it, but it's nice to enter 0.01, or whatever, for the import scale (when you import it to Unity).

But really, I'd imagine that's all a minor consideration. For hiring a modeller I'd think people would mainly care about modelling skills, style, reliability ... and "will they export it into Unity?" would be merely a tie-breaker.

 

There is a chasm filled with crocodiles, the blood of their victims and all the tears and fears of both between the mindsets of developers and designers.

This is probably the wrong place to ask about ways to cross the chasm because it's all about one side, filled with developers that have long since lost their passion for content and design processes, and creativity.

And, more generally speaking, the Unity "community" such as it is, is hopeless at creating shoulders upon their giants, preferring to wet the slide so each new user falls to a hundred deaths before finding their footing or moving on.

 

Thank you for your info, I think if IK controls aren't an option for Unity, I'll have to "fake" the animations in blender using IK to create animations but not contain them in the export, and instead keyframe the various movements directly.

As for putting everything onto one sheet, what I've typically done in the past is the opposite of that, breaking down complex animations into multiple separate actions and also with additional parameterized deformations that I can keyframe.

In Unity, can you effectively "blend" animations together via coding, creating smoother transitions automatically, using the put-all-animations-on-one-timeline method? I have not blended animations using only one single sheet before, so I'd like to know if it's still possible to do that with this mono-sheet method.

 

I don't think that's true, I think a programmer could say "animate stuff this way..." and then I could do that. Or they could say "use no more than 'x' vertices for this mesh" and I could work with that as well.

 

That's the normal thing. But I should be clear, everyone knows you can't export IK into anything. Asking about whether a game engine takes IK imports doesn't make any sense. All it does is make people think you're not a serious 3D modeller. Don't mention IK in that context.

I'm just saying that most people use one big track. I'm sure Unity can handle multiple animation tracks. My point is, you can save users work if you import your models into Unity for them. Then you can connect Unity's animation settings to your models, and so on. Try it and take a look. It's not complicated, but it can be time consuming.

There are no restrictions on this. If you can get Unity to play the animations from your model, the "blend the end of a1 into the start of a2" will always work. Unity can also combine half-of-the-model animations. Like it can play "run" on just the legs and "clap" on the upper body. But you don't have to know anything special to allow that -- Uniters can take your "run" and "clap" and just do it (as long as you set up the bones in the normal way).

 

Huh?

 

I can't tell you how/what to do in Blender because I don't use Blender. I'm an engineer, not a 3d artist.

Things that I care about though:

1) Consistency - I don't care how big you model things, only that all things are modeled to the same reference size, orientation, etc. Which leads to #2

2) Orientation - make sure you're exporting your model from your modeling software in the correct orientation. If your models are on their sides, or rotated randomly... super annoying. At the very least though... be consistent with said orientation. But Unity prefers a left handed z-forward/y-up system. Note your modeling software may or may not match that, I believe blender is a right handed z up system. You're going to have to account for this. (i believe the exporter you use will have configuration options to facilitate you)

3) Skinning/Bones - do it correctly. Not everything needs to be skinned, but if it is something (keyframe animated things), just make sure it was done correctly. For bipeds use the correct bone layout, make sure you've attached the mesh in the correct places. Import them into Unity, drop them in a scene, and test your animations to make sure they look the way they looked in your modeling software. I can't tell you HOW to do this... cause I don't know HOW Blender works... I'm not an animator.

4) Performance - make sure you model is optimally drawn. Make sure you've welded what needs to be, make sure the poly count is appropriate, make sure your animations aren't bloated. Again... I'm not a modeler, I don't know exactly how you do these things, go ask a modeler for specifics. I just care that your model doesn't drag down my framerate when only a handful are in the scene.

5) Export in the correct format - yeah, we're not taking your '.blend' files. Export them as .fbx or some other portable format.

6) IK - if you're creating bespoke animations using IK in blender, but you then just export them as keyframed animations... I honestly don't care that you used IK. Again, I just play the animation. If we need IK in the game to dynamically animate things... Unity has IK. In this situation though we're using Unity's system, you need to make sure your model's skeleton is setup correct and skinned correctly.

...

In the end I just tell animations to play, that's what I do. This thing happened? I say "play". May this be through mecanim parameters, may this be through the legacy Animation.Play.

Sometimes I might need specifics because maybe some gameplay is relevant to specific frames in the animation. Maybe the 'strike' box for an attack turns on and off at a certain time in the animation of a punch. But in those situations there's no real guidelines I could give you. That's a conversation that will be decided upon between the programmer and artist (or the production management who works to interface both teams).

Honestly... I'm a bit with @Kurt-Dekker here, I don't exactly know what you're asking for.

See I make games as part of a 2 man team. It's me and my partner who is a 3D artist. We've been in our professions for very long time. He cut his teeth working in AAA working on games like Guitar Hero series, Marvel Ultimate Alliance series, Skylanders series, Transformers. It sounds to me like you're asking for what his knowledge is. He is intimately knowledged in the pipeline between his modeling software and the game engine. It's what he has spent every waking moment learning since age 13 when we bootlegged 3DS Max with the dancing baby in the 90s. It's what he got 10's of thousands of dollars in college debt going to school for.

I could not tell you what he does.

A lot of us programmers probably couldn't unless we happen to be an artist AND coder at the same time. Which some of them do exist. But I've come to notice that even though they might be familiar with both wheelhouses, they often come at it from one side of the fence, and it's also likely not the way teams tend to work together. Again though, this could vary... but we're talking about diamonds in the rough at this point. You're on a programmer sub-forum... 99% of us aren't that diamond in the rough. We're all programmers.

And like... I don't know... you do the modeling stuff. Go do it artist. I'll take care of the engineering. If we need to discuss specifics... well lets schedule a meeting.

But if you're a newb at arting for the industry. I wouldn't think asking programmers how to art is going to be the best place to get that information. That's like asking the electrician how to plumb on the construction sight. Sure... the electrician needs to be AWARE of the plumbing and the 2 parties need to work around each other's requirements. But I'm the sparky... I do the zap zap. You're the piper, you do the wet wet. The best I can say is don't get your wet near my zap.

TLDR;

If you can import it into Unity, drop it in a scene, play the animation, and it looks like what you want it to look like. I'm happy. Cause that's basically what I'm going to be doing with your animation 99% of the time. But if you drop it in, and it's laying on its side, super big, and the mesh contorts when it plays... welp... go fix that.

 

OH... something else I'd suggest aside from just asking the modeler/animation community what their standards are.

Go onto the Unity Asset Store, start downloading various free models. The more popular/well rated the model/animation, the better. And take a look at how they set it up.

Sure, not everything will be the same. Some asset sellers just have their own way. But if you look at enough of them you should notice some common practices amongst them. Do that. Do those common practices.

...

As I tell my artist/partner over the years.

You're the creative here, I'm the engineer. I help you make your creative vision look the way you want it to. That's my job as an engineer... I engineer the things. I can work around what you need me to. Just as long as those things are consistent.

Consistency, standard, that's king to an engineer. I don't want to have to learn a new thing every new animation that gets thrown at me. I want to write my code once and get on my way. I've got way bigger fish to fry then telling your animation to play.

 

Blender is the same modelling as 3DSMax. The controls look completely different, but verts, polys, unwraps, bones, envelopes ... the same.

BUT, I've heard their game engine finally got decent years ago. So someone making a game in Blender using Blender-saved models might never know about exporting. They might use a spline as an IK target, or a model with Modifiers, and the Blender game engine will run it just fine since it's using the Blender modelling tools to do it. In fact, we used to get similar questions here from people working in 3DSMax who I assume had previously rendered out clips, also using the full suite of features. In the same way, they didn't realize you have to bake in the modifiers and bake animation down to simple FK keyframes before an export.

 

Oh, I don't know 3D Studio Max either... that's what my partner uses. When I said I don't use Blender... I mean... I'm not an animator/artist.

The most I know about 3d modeling software is when I need to go in and adjust some exporter's code because it's buggy, or write some batching script to streamline some workflow. The actual like STUFF that is done... I don't know. My artist says "I need it to do the thing" and I'm like "OK, that thing is this function here, so I call it."

Yet I could not draw a cube if my life depended on it.

And when I said we bootlegged 3dsmax when we were 13... I mean sure, I facilitated the bootlegging. But I didn't like use it... that program bored the crap out of me. Always have been and always will be the technical minded of the duo, he is the artsy fart. I tried getting into art... I could sketch a little. I'm not completely hopeless. But my creativity is more in analysis and theory. I'm that weird autistic guy who can off the cuff tell you the complete history of laserdisc in a 2 hour diatribe while drinking in the kitchen (an actual thing that happened to my wife and brother who got stuck in said 2 hour docufest).

 

@SoundStormLabs Here's someone that could probably answer your question:

https://forum.unity.com/threads/senior-lead-3d-artist-looking-for-new-opportunities.1447717/

@Thomas-Pasieka Have you got a moment to chat about the original question in this thread?

 

My advice would be to import your character model in to Unity and try it out with some sort game system or character controller.
For example:
https://assetstore.unity.com/packag...sets-third-person-character-controller-196526
or
https://assetstore.unity.com/packages/templates/tutorials/3d-game-kit-115747

Check-out how your character works in the editor.

Remember, the convention in Unity is that Y is up and Z is forward. Make sure your character is oriented this way. Make sure you can set-up a humanoid avatar without errors. Make sure that third party animations work the same on your character as the provided characters. stuff like that.

Theoretically, it should be easy for your users to take whatever game template and replace the default character with your character.

 

Oh, okay, I thought Unity couldn't process Blender's IK according to someone else. You're saying I can import Blender's IK parenting and such into Unity?

 

no, that's not what I'm saying there

 

As both coder and modeler on my projects, there are some guidelines that I been follow:

• Use FBX export.
  
• Keep separate the game rig with ik rig. Export only game rig. (I'm using cgdive gamerigtools plugin)
• You cant keep blender Ik to work on unity, You need the implement Ik system for your own needs, like animation rigging package or asset store plugins.
• Don't use blender specific transform options on game rig (like don't inherit parent bone x scale)
• Don't use non uniform scale bone animations, preferably do not use scale except root bone
• Make sure all bones transforms translates correctly from Blender space to unity's space
• Export Animations on separate fbx file that only consist rig and and placeholder mesh (just exporting rig not work)
• Make sure follow the same bone count per vertex weight between unity and blender.
• for each blend shape, even it just move one vertex slightly unity will hold data of meshVertexcount * float3 for position delta and if import blendshape normals option import or calculate that will cost vertexcount * float3 for normals plus vertexcount * float4 for tangents. So blend shapes are very costly on disk.

 

I think you'll just want to start exporting stuff from Blender into Unity to see what does and doesn't fly. You'll learn a lot quicker that way than asking questions here.

 

Okay, I guess what I'm wondering is if Unity can blend "run from 1-30" with "turn from 70 - 100" gradually. Like what is the setup to blend animations that are all put onto one timeline? What controls that in Unity?

 

If you want to specify that 1-30 is "run" or whatever, that's in import settings:
https://docs.unity3d.com/Manual/class-AnimationClip.html

Transitions between animations are done using a state machine. You can connect any animation to any other animation and configure the transition.
https://docs.unity3d.com/Manual/AnimationOverview.html

 

The important thing is that you can make the animations in whatever semi-standard way you want, and Unity can handle it just fine. That the includes all-in-one-track style. If it didn't, that would mean modellers have to do something special to make theirs work in Unity, which means Unity would suck and would have never gotten popular.

If you open up the model after bringing it into Unity (I think that's where), you'll see where you set up the animations. You can specify a track (I think) or some frames of a track. When you're done, you'll see it's just a list of animations. Then if you look at the blending rules, you'll see it simply uses animations from that list, like blend "run" with "idle". How they were made doesn't matter, or it would have said so. In fact, it even works with overlapping frames -- like mixing one animation looping around frames 1-40 and another looping around 5 to 90.

 

Context: I’m a programmer very interested in animation programming who knows Blender enough to have gone through the character creation process a few times. I’m still bad and slow at art, but I at least know a few things that can maybe help bridge the gap.

The most important thing is that every team and project is different, so make an effort to know the programmers and the tools they are using. Some programmers and tools and projects will be less picky than others. And some projects may require a special way of doing things that could be a big no-no in another project. Most people here will be using the Unity Animator, but there are other tools out there, and I will try to highlight some things to watch out for.

In general, try to minimize the amount of work it takes to embed a character into the game world. If the character moves on the ground or hovers over it, put the origin of the character on the ground under its center of mass. If the character is always flying freely in all axes, then put the origin at the center of the body. Make sure the character is scaled to world-scale and imports with the correct rotations and scaling. Polynook has a good tutorial on how to ensure rotations import correctly.

For bones, keep a hip-to-toe hierarchy for humans, as that is essential for IK. No puppet string control bones. In general, also try to do as much as you can with bones, and with as few bones as possible. Blend shapes are heavy. Don’t expect drivers or IK to transfer. If those are absolutely essential, then you will need to tell the programmer the exact details and formulas to recreate the logic. Humanoids have built-in support for twist bones in key places. Don’t use bendy bones.

Put empties where you expect in-game items to attach. Sometimes it may help to have empties where trigger colliders should be if there isn’t a bone at that position already. From Unity’s perspective, there is no difference between a bone and an empty.

Use a consistent naming convention for bones and other objects. That’s super helpful when programmers are debugging things and they see names that point them directly at the correct objects. Some projects may have strict naming conventions.

In Blender, you can separate animations into actions. Do this, as Unity understands this.

Sometimes you may need to export an animation without a mesh. Sometimes in these environments, a programmer may ask you to skin a plane to the rig so that they have valid bindposes when attaching new skinned meshes to the rig. Others may require all accessories be attached to the character in the object at once. For me, I only care that they share the same skeleton model with the same bone names, but each accessory can be its own file.

In classical Unity, having separate skinned meshes has a big performance cost. Some programmers may have tools to combine meshes. Others may ask you to do it. But if you were working with me, I would tell you to not bother because I have my own solution that doesn’t suffer from this issue.

Most programmers would tell you to avoid scaling, and if there is scaling, at the very least ensure child bones inherit parent bone scales in Blender, because that’s how Unity handles it. I’d tell you to do the opposite, because I have special tooling that assumes parent scaling is NOT inherited.

Some programmers will ask for very specific start and end poses for specific transitions. Though most will just rely on Unity’s transitions system. However, if they are using a system that has inertial blending, they might ask you instead to cut off animations mid-motion. Some will ask that walk/run cycles keep footsteps proportionally in-sync relative to the start and end of the clips, so that they can blend in-between them cleanly. Having very explicit foot planting with toe and heel touching the ground and a solid few frames where the foot is just slightly under the ground (due to floating point errors) and not moving will really help the automatic IK systems in Unity do better-looking things. Often for looping clips, the start and end frames have to match poses exactly. Time management is weirder in animation programming than you think.

Be wary of whether the programmer’s sense of locomotion speed. You might have to get very creative with how the character moves to match how the programmer wants the character to feel speed-wise as it navigates around the world. Some programmers will allow for root-motion to dictate speed. Others will rely heavily on their own code and will ask the motion to be matched to it.

Some programmers may want different body parts to be animated independently, such as upper body vs lower body so that they can combine actions and movement with Unity’s layering system. Some projects might have the character hooked up to an active ragdoll, in which case what is in the source animation and what actually happens on screen could be very different.

Be wary of the camera and what it needs to see (and not see), and also be wary that the programmers will change what it is doing a few times before they get it “right”.

And lastly, be wary of ego, both that you emit, and coming from the programmers. Stay open-minded to new tools and workflows, and try your best to understand the challenges the programmers face without getting in their way.

Hopefully that all helps!