Games Ghost Knight Victis - Heroic Dark Urban Fantasy - Action RPG

I fixed the bugs with the new attack input system. Charge animations now fade in at a consistent manner, and the character no longer gets stuck in the charge animation if the user button-mashed the attack buttons.



What I did was put all charge animations on a new layer on top of the base layer. When an attack animation is played, the charge animation for it is also played at the same time so they are synchronized. But even though the charge animation is played, it won’t really be seen yet (weight of Charging Layer is set to 0 at the start).

When a charge is requested (user held the attack button long enough), the only thing that’s really done is just smoothly move the Charging Layer’s weight towards 1.0 to effectively blend in the charge animation that was already being played.

This is kind of similar to a blend tree, but I want to play the charge animation regardless of what state the base layer is currently in.

I also fixed the bug when the player gets hit and can’t move for a while even though the hurt animation has finished already.

 

Looks good

 

Testing out the in-progress spear impale attack. You impale enemies with your spear, plant the spear on the ground, then conjure another spear for yourself.

It’s missing some visual effects, I’ll need to fix that awkward choppy animation as the player thrusts the spear, and the behaviour isn’t fully implemented yet (impaled enemies can’t get free yet).

The idea here is that this will temporarily put impaled enemies out of the fight. They’ll be able to break the spear once their stamina is full, so you’ll want to tire them out first before attempting to impale. That way, they'll be out of the fight as long as possible (their stamina regain will be slower while impaled).

You can continue to hit them while impaled, but this will also damage the impaling spear. If the impaling spear breaks due to your own attacks, the enemy will get free immediately.

So this is a question of whether you use the impale attack defensively or aggressively: you can impale some annoying ranged attackers, then leave them alone while you deal with other enemies (this will keep the impaled enemies disabled long enough for you to finish your other fight before going back to them), or you can impale the enemy you’re fighting in front of you to interrupt their attacks and hit them more while they’re helpless.

Naturally, not all enemies can be impaled like shown in the video, and I’ll probably make it that you can only impale maybe 2 or 3 max at any given moment, and maybe have upgrades to increase that limit.​

________________​

@Ironmax: Thanks!​

 

Working on particle effects for the Spear Impale, testing it on a non-hostile enemy. There’s a few more things I want to add here: an appropriate hurt animation when the enemy gets impaled (it doesn’t have any right now), dripping blood on enemy while impaled, some more effects when the spear is planted on the ground, and some effects when an impaling spear shatters.

____________________________​

I fixed the odd framerate hiccup when you impale an enemy (you could see that in my previous video). Surprisingly it had nothing to do with the impale code. I thought my act of parenting a whole enemy into a weapon was causing a slowdown. But it was actually Unity loading things needed for the hit particle effects (the shaders and textures they use).





I was already preloading the hit particle effects by manually placing them on the scene so they’d get loaded, when the scene gets loaded. But turns out that stopped working as intended.

At one point, I placed them deep below the ground (50 meters below) so they wouldn’t be seen when the game starts. Because that would have looked weird, the player seeing some hit effects at the start of the game. But I guess placing them far away made Unity decide not to load them at all.

So the fix was, I moved them closer (2 meters below the ground). Seems that was enough, since doing that got rid of the framerate hiccups.

 

I like how your light and skill fx works. really great. When can i buy this game ?

 

Fully implemented the spear impale behaviour: enemies break free once their stamina is full, but the spear will break earlier if you attack the impaled enemy too much. While impaled, the enemy’s stamina regain is slower by half.

I also added more particle effects and blue light on the impaling spear itself.

I decided it'd be better if I add blue light on charging attacks as well.

_____________________________​

@Ironmax: Thanks! No plans yet! This is only a protoype of the combat part of the game for now.

 

yeah it looks cooler.

 

Spent the day fixing some animations. As I realized, lot of my animations end up a little distorted. I suspect it’s my asinine way of setting up the rig in Blender (I use Rigify but I ended up editing it a bit, but I can’t remember why) and how I set it up for Mecanim.

I was always annoyed that the character wasn’t holding the warhammer properly when I do the charged attack. It’s as if the warhammer was moved up, outside his grip. When I checked it in Blender, he was holding it properly, so I suspect there was something wrong with the way I set it up for Mecanim.



The way I set up my animations, I separated them into many .blend files, because import time when I change an animation is so slow in Unity. It gets even slower the more animation clips are inside one .blend file. Which is why I ended up separating them in the first place.



I ended up with the habit of separating them per weapon, and per groups of related animations, so rapier attack animations are in one file, rapier movement animations are in another, spear attack animations in another, etc.

The trouble was getting them all to work the same way. Like in the image below: left is the 3d model I use for the game, right is from the .blend file of the warhammer attack animations.



Somehow, the animations weren’t getting retargeted properly. I ended up copying avatar definitions from the warhammer attack animations, and that fixed it.





It’s weird though, their rigs are set up the exact same way (they all started as copies of the same file) so there shouldn’t have been a problem in the first place.

_____________________​

For the forearm, I had to edit some animations because for some reason, Unity is showing them with some really weird rotations.





Left side is in Unity, right side is how it is in Blender. Notice the cowter (elbow armor) pointing the wrong way in Unity.

Again, I suspect I set up the rig wrong somehow. Then again, I may be positioning the arm too awkwardly and Unity’s way of doing wrist rotation is having a hard time keeping up? I don’t know, but if I relax the arm’s pose a little bit, the effect is lessened.

 

Testing torso leaning up and down. I will be using this for the times when the enemy you targeted is either above or below you.

Right now if you play my latest demo day build, your attacks simply won’t hit if your targeted enemy was somehow crouching down (the enemy’s third attack ends up doing this), even if you were standing right in front of them. The arc of your rapier’s slashes simply doesn’t reach them.

So I experimented with adding torso leaning via code (and yes, it does indeed give you the reach to hit crouched enemies).

It works surprisingly well as the added lean angle is applied regardless of what animation the player is doing. It works while you’re moving, and even while doing a charged attack.

I just need to give it sensible upper and lower limits to prevent the torso from rotating too much (as you can see in the video!).

I’m surprised at how easy it is to add. The bulk of it is really just calls to Transform.RotateAround on the bones you want affected by the leaning motion.

For skinned mesh renderers, bones become empty GameObjects with Transforms that can be manipulated. And the nice thing is that if you move the Transform of those bones in code, the skinned mesh will follow.

As long as you do so in LateUpdate, it will work. This is because character animation is applied after Update. If you had moved the bones in Update, their values would just get overwritten by the animation being played.

(this is from the Execution Order page in the manual)



Update is executed first, then animation is applied on the bones, and LateUpdate is executed last (you can ignore those “yield” statements in the middle for what I’m discussing here).

This means LateUpdate is the perfect place to apply added motions on top of character animations.

As for the code, a simple call to Transform.RotateAround on the bone's Transform does the trick:

point is where the rotation will start from. For this, I use the position of the character’s pelvis.

axis is what direction the rotation will revolve around. Imagine it being a can of Pringles, and how the can would roll around will be the direction of your rotation. Since I needed the torso to lean downwards or upwards (and not sideways, or a twisting motion), I use a can of Pringles that’s laid out horizontally to the character. In code, this is easy: I just use the direction pointing to the character’s right (Transform.right).

angle is, obviously, by how much to rotate the bone’s Transform. This value is in degrees, so it’s easy to visualize.



In addition, I don’t rotate just one bone, I rotate the whole spine, but each bone gets bent lesser and lesser as you go up the spine, giving the whole thing a more natural looking bend.

I added an additional “percent” property for each bone to specify how much lesser it gets bent. And when each bone is rotated, the angle it uses is the lean angle, but multiplied by its percent property.

Essentially, I’m controlling the influence of the leaning motion for each bone.

To help explain, here’s a simple demo of it using spheres parented to each other.

 

you be supprise how bad handgrip are made in RPG games, i love this types of detaile and spend allot of time with bone placment with animation. Even blizzard and wow have horrible handgrip placemen

 

Attacks now properly use torso-lean-to-target. I've made it that some attacks only lean up (spear thrusts), some allow leaning both up and down (rapier normal attacks), and others don't use it at all (spear impale, warhammer pound, rapier dash attack, basically, all of the charged attacks).

Mostly, when the attack is a vertical motion (spear thrusts), then it doesn't need it too much, but when the attack is a horizontal motion (warhammer swings), then it needs to adjust the torso a lot.

Had a terrible headache so I had to take a break for the rest of the weekend.

 

Started working on the first “spell” in the game: “Impaler’s Sanctuary”. A spell of create spear wall (in a circular formation). It doesn’t have the appropriate visual effects yet, and the spear wall is supposed to get damaged when hit, and would break when hit enough times.

It can be used defensively, to give yourself space when surrounded (as they rise up, they’re supposed to deal damage to any nearby enemies and push them back), or offensively, to trap enemies inside until they destroy the spear wall with their attacks.

I’m not yet sure how spells will cost you. Whether they have a “mana cost” and you having mana points, or if instead you have a limited number of times to use it that recharge when you rest, or something else entirely.

I’m also not yet sure about the controls for this. There will be many of these weapon-based spells that you can cast. I’m thinking the D-pad on the controller will let you select the active spell, and something like R1 or R2 to cast it. On the keyboard, I’d just have them on the number keys, like in MMO controls.

No, they’re besieging my little castle!!! After a day, I've implemented destructibility on the spear walls. The spears now also deal some damage while they’re rising up.

While this was easy to implement, the code is getting a little bit convoluted here, since those spears in the spear wall act as damage-dealers (which can destroy objects), but they’re also destroyable objects themselves (obviously, damage-dealers are prevented from damaging themselves). It works nicely, but I suspect I’ll need to refactor that part of the code in the future.

 

As much as I love using Hacknplan, my Internet connection has been getting flaky as of late, and cloud apps lose their usefulness. So I’m transitioning my todo list in this offline software called Portable Kanban.

I’ve been suggesting to the hacknplan devs to make a desktop client that can work offline and would just sync (I’d be willing to pay for their subscription plans for that), but I never got a reply. Guess that’s too much of a tall order.

In Portable Kanban, everything is in one screen, and it doesn’t have the cool “game design model” organization feature of hacknplan, but it works offline, which was what I needed.

At least the cool thing with it is it allows me to add custom fields for the tasks, which I use for this neat trick: you rate each task by importance and difficulty. Importance is how much business value it adds to the product, Difficulty is the amount of risk, uncertainty, and technical complexity to pull off completing the task.

You’ll want to focus on prioritizing tasks that have high importance but low difficulty (and at the lowest in the list are low importance, high difficulty tasks). The rationale being you’d want a lot of important things done as early as possible.



This shouldn’t be your only metric for deciding what to do next, as it’s also easy if you do tasks that are similar. This only counts if you have multiple hats in development: if you decided to do a task involving programming a new feature, then do some new attack animations, then to bug-fixing player input, then to a task improving an existing old feature, it’s a lot of hassle to re-orient your mind to the task at hand, especially when the tasks have little to do with each other.

Sometimes it’s easier if you batch together work that are similar. Perhaps work on tasks regarding the GUI first, then do the programming tasks in one go. Or if you have programming task regarding attack animations, maybe you’d want to group that together with the tasks for creating attack animations.

 

Started implementing camera shake after putting it off for so long.

I accidentally left camera shake values too high while fixing a bug and that happened.

So I decided to play around with it more. Clearly there's a point where I should stop goofing off with the camera shake, but I don't think I passed that yet.

 

Testing functionality for preventing hitting through walls. I still need to make it that your attack animation is disrupted when you hit a wall, but for now, I’m just making sure damage-dealing is prevented if there’s a wall in-between you and the enemy.

 

Your attacks are now interrupted if you hit a wall/obstacle. The “got interrupted” animations probably need some tweaking, but the functionality is now working nicely.

This now makes the wide swings of the Warhammer useless in narrow passageways, as it will most certainly just collide with the walls. But it makes the Rapier’s charged attack more useful since that does a phase dash (bypasses walls/obstacles).

While I’m already making it that the attack animation is disrupted when you hit a wall, sometimes the hit detection still manages to detect the enemies (if the hit detection found enemies before the attack got disrupted).

So here’s another test to make sure you can’t damage through walls/barriers, but still hit enemies on the same side as you are. This doesn’t happen all the time though, so it took me a lot of tries to even get to show this in recording.

The cyan lines indicate hit detection on enemies (a raycast from your torso to theirs), but the purple X on the left one indicates it found a barrier at that spot, so damaging didn’t proceed.

 

Ported my game to Unity 2017.2. Pretty ok for the most part. The editor itself hasn’t crashed yet, despite what I hear about other people’s experience with 2017.x.

But I did need to change quite a bit of stuff to keep the framerate the same as before.

_____________________​

Horizontal Layout Group and Vertical Layout Group is slow

There were at least, no cryptic compile errors. But testing the game, first thing I noticed was a big decrease in framerate. I was getting about less than 20 fps whereas I got around 30-50 fps back in Unity 5.5.5.

Take note this is the fps inside the Unity Editor though. Standalone builds always have higher framerate values, regardless if it was done in Unity 5.5.5 or 2017.2.



But having less than 20 fps inside the Unity Editor was too much. So I suspect something was wrong.

Firing up the profiler showed me the problem:



A lot of calculations being made with rebuilding the GUI layout. I’m not entirely sure why, in Unity 5.5.5, I was not having this problem.

Using process of elimination (disabling GameObjects until the framerate gets high enough), I pinpointed the problem to the enemy healthbars. I had about 20 enemies in my test scene, so that was 20 enemy healthbars.

In this healthbar I had number values of their health and stamina, positioned using Horizontal Layout Group.



I had those numbers disabled (their GameObjects were disabled) because I decided it made the GUI too “noisy” to show a bunch of numbers on-screen anyway. So I was wondering why Unity 2017.2 was calculating them even though they were not visible.

Furthermore, not all 20 healthbars were being displayed at the same time. Most of the time, only the healthbar of the enemy you targeted will show up.

I’m not inclined to wonder too much about this. So for now, I simply disabled the Horizontal Layout Group component itself.


That pretty much fixed the framerate problem during gameplay.

_____________________​

Alpha Channel not importing

When I went to the in-game menu, I got this:



I don’t know why I was getting white squares there. Looking at the sprites involved, I found out Unity 2017.2 is not able to import the alpha channel of some .psd files properly anymore.

In Unity, the image looked like this, (see the preview, showing it completely white):



In Photoshop, it looks like this (see the checkered background indicating transparency):



Not all of the .psd files were having this problem. So I just worked around it for now by exporting the affected .psd files into .png files and using those.

However, this should probably not be happening in the first place, so I’m guessing it’s a regression bug.

_____________________​

Unity UI Text

My other problem was a big slowdown in framerate whenever I enter the in-game menu.

The profiler again, pinpointed the problem:



About 9 MB was incidentally being allocated per-frame by this NicerOutline script I was using. This was from the Unity UI Extensions I was using, to give some outlining effect to the Unity UI Text.

I had them in all of my UI Text, so going to a screen with a lot of text slowed down the game (like the Graphics Settings Screen).

This is how text effects (drop shadow, outline, gradient, etc.) are done in the standard Unity UI Text component. They are individual scripts. NicerOutline is one of them.




I’ll just clarify that I’m using an old version of Unity UI Extensions that I haven’t bothered updating, so maybe they have fixed that now.

However, the thing is I’ve since upgraded to using TextMesh Pro (ever since it became free), and TextMesh Pro doesn’t have this problem. It also has a bunch of other features that make it superior to the standard UI Text (crispier looking font, built-in letter spacing, etc.)

Text effects in TextMesh Pro are done in a dedicated shader, specifically built for it. It’s fast since effects are done entirely in the GPU, instead of C# scripts.



But since replacing all of my UI Text into TextMesh Pro was a very boring thing to do (I had a lot of Text in many screens), I hadn’t done it yet, and I kept holding off that task since it didn’t seem to affect the game that badly (until now).

So for a long time, only some parts of the GUI was using TextMesh Pro, while the rest was still doing it the old way, with the standard Unity UI Text plus the NicerOutline script.

Obviously I can’t keep using that; it was slowing down the game. I decided it was better to go ahead and finally go with TextMesh Pro all the way.

_____________________​

Cloth Simulation and AI

And with that, the game’s framerate was generally better. I still get spikes in the profiler, but they’re spikes that do not affect the framerate badly.

The cloth simulation takes a big chunk (the highlighted orange part), since all characters in the test scene are using cloth.




And occasionally, my AI system. Every now and then, all enemies do some raycasts, overlap sphere checks, etc to detect if the player or some obstacle is nearby.



But again, both of those are not affecting the framerate that badly, compared to the other problems I mentioned. So I decided not to do anything about them.

Just note that those screenshots of the profiler indicate an average of 30 fps because the profiler itself can slow things down a little. When I close the profiler, the Unity Editor can get something like 40 fps on average (and something like 50+ fps if the camera is not showing any enemy on-screen).

And again, like I mentioned earlier, a standalone build of the game will get an even higher amount of framerate.

_____________________​

3rd-party Plugins

Updating from Unity 5.5.5 to 2017.2 was quite a big jump, so I naturally expected I have to update a lot of the plugins I use (TextMesh Pro included): Editor Console Pro (better console log window), Rainbow Folders (customizable folder icons in Unity’s project window), InControl (customizable control bindings for the game), Shader Forge (visual shader editor).

If you’re doing an upgrade like that, just be sure to check the plugin’s readme in case you need to do something extra to make sure it updates properly. Usually you need to completely delete the plugin’s folder and import the new version, to ensure no undesired files remain. Just don’t accidentally delete your user preferences for those plugins, if they have any.

In TextMesh Pro for example, I made a separate folder called “TMP User” and moved the TMP Settings file, all the color gradient presets, etc. into that. Those are files that I’ve already edited to suit my tastes, so I don’t want them to get overwritten whenever I update TextMesh Pro.

_____________________​

All in all, upgrading to Unity 2017.1 went smoothly. I think I’ll keep using this unless I see some showstopper bug (i.e. the Unity Editor crashing).

 

I’ve modified the texture on Desparo’s cape, adding tattered edges and dirtied up the texture a bit.

Technically, I’m done with version 1 of the combat demo so I’m doing these minor tasks I’ve been holding off on, before I move on to making the next part of the combat demo.

 

Finally updated the look of the player’s health and stamina bar. The old ones were actually free art from opengameart.org that I used as placeholders.

I’ve also added a purple glow on the stamina bar to indicate that you’re starting to deplete your stamina. I’m guessing it’s usefulness will vary from person to person. I personally have a habit of occasionally glancing at my health/stamina when fighting.

 

Here’s a compilation of all the work-in-progress video clips I made for 2017.

As a recap, here's last year's summary:

 

Improved the analog stick target switching controls, it’s now based on the closest target inside a cone.

Used to be, I’m simply searching for the enemy closest to a line starting from the center of the screen. It didn’t really work very well, but at the time I couldn’t figure out a better way to do it.

I have no idea how games do these things. So drumming up my head to invent some good algorithm for this, I realized target switching shouldn’t be using a line at all, but a cone area. It should search all enemies inside the cone that is closest to the tip (of that cone). If it can’t find one, only then would it look for the closest enemy outside the cone.

 

Starting to work on the 3d model for the player’s 2nd armor, tentatively named “Dementero”. I think the name's too long. Feel free to suggest a better name: this armor’s about rage and brute strength.



I tend to want to give them Latin/European sounding words (doesn’t have to be a real word). The purple armor for example, is named “Desparo”, because it’s about despair.

 

Some more progress:

 

Almost finished, just need to add the loincloth and something to cover his butt!

 

Settled for something simple to cover his butt. Will work on a test rig next.

 

Very interesting find. I have to take a look at your links when I am home

 

Finished making a test rig. Looking good so far.

I did an experiment to see if Unity can pick up constraint-based animations from Blender. Surprised to see it actually works.

Here I’m testing the opening/closing of the character’s visor via bone constraints (as shown in the Blender window). Instead of doing rotation on the visor bone, the open/close motion is created using constraints. This is really just more for convenience. Having them this way is easier for me, since now whenever I want to open/close the visor, all I need to do is drag a slider (i.e. the constraints’ influence percent), then keyframe that.

In Unity, I play this test visor animation from an additive layer in Mecanim. This means I can play the open/close visor animation independently, regardless of what the character is doing at the moment.

This means (via keyframing the constraint influences) I can do animations like weapon attacks wherein it starts with the character holding the weapon with both hands, lets go of his grip on one hand during the attack, punch the enemy with his free hand, then hold the weapon with both hands again afterwards.

The face I have there is just temporary, it’s part of an old 3d model I made.
I did an experiment to see if Unity can pick up constraint-based animations from Blender. Surprised to see it actually works.

Here I’m testing the opening/closing of the character’s visor via bone constraints (as shown in the Blender window). Instead of doing rotation on the visor bone, the open/close motion is created using constraints. This is really just more for convenience. Having them this way is easier for me, since now whenever I want to open/close the visor, all I need to do is drag a slider (i.e. the constraints’ influence percent), then keyframe that.

In Unity, I play this test visor animation from an additive layer in Mecanim. This means I can play the open/close visor animation independently, regardless of what the character is doing at the moment.

This means (via keyframing the constraint influences) I can do animations like weapon attacks wherein it starts with the character holding the weapon with both hands, lets go of his grip on one hand during the attack, punch the enemy with his free hand, then hold the weapon with both hands again afterwards.

The face I have there is just temporary, it’s part of an old 3d model I made.

 

It’s so difficult to get back into things once you lost momentum, but I’m trying slowly to inch my way back to regular progress posts.

I hadn’t realized in one of my sketches, I made some detail on Demento’s back, so I went back to the 3d model and added it.




Long story short, I started living in an apartment unit that I rented. With all the hassle I had to go to, to get this place livable, I just ended up wanting to relax every weekend, so I wasn’t able to work on Ghost Knight Victis for a while.



The place was unfurnished, so I started buying stuff (via online), some of which ended up with a wrong delivery address (including the refrigerator). The store refunded me and I just ordered a 2nd time, but I just can’t relax until I’m sure I’m really gonna get it this time.

It’s just canned goods and fried eggs until I get my fridge (I finally did get it, though the refunding process for my original order is still not complete).



Since I was going on a shopping spree with my hard-earned savings, I thought I might as well buy some stuff I always wanted, like this full mount arm setup I did for my laptop and monitor:



(Horrible cable management there behind the laptop, but I’m too lazy to fix it.)

I also started work on his broken greatsword.



I have this idea for a power-up called "Lustre" which, when activated, will bring your weapons and armor back to their original, brand-new, shiny selves for a limited time, dealing double-damage. So this greatsword will appear whole when that's used.

To use it, a meter would fill up a bit every time you hit an enemy. It will reset to zero if you get hit, but once it's full, it can't drop to zero anymore, and you can then activate Lustre.

The idea with Lustre is that, due to your flawlessness in combat, you're able to have a glimpse of how things used to be.

 

I'm actually really curious as to why your monitor is rotated?
Also, I like the redesign to the armor!

 

Thanks. Portrait orientation on monitors make it easier to read source code or when looking at web pages. Having a mount arm makes it easy to switch between portrait and landscape.

 

Finished a base mesh for the broken greatsword. I will probably sculpt in better details for the wear and tear on the blade.





I know this design doesn't technically classify as a greatsword, if we're talking about real-life, as the center of balance would not be correct (as most fantasy swords go).

This is more of an elongated cleaver with a sword hilt or something (I still call it greatsword because I don't know what else to call it). I just really wanted to have this type of weapon in my game.

It's not meant to be sheathed and has a very specific use (charging into tightly packed group of enemies). Outside of that situation, you are meant to switch to other weapons. In terms of gameplay, it's ability is Cleave, which makes all of its attacks hit multiple enemies.

 

Reminds me Gael's Greatsword from Darksouls, pretty cool

 

Oh, did a little google search for that just now. I actually don't have Dark Souls 3 yet. I promised myself I'd finish DS 2 first before going to 3.

 

Before I move on to making this look good, I wanted to make sure I can properly get root motion to work in Unity. My first few attempts reminded me of the problem I had with my custom weapon bone.

Even when I thought “screw this, I’ll make my own custom root motion functionality from code”, I realized why it wasn’t so straightforward.



I made my weapon bone move like an IK handle, because this makes it easier for me to animate it. The left/right hand IK bones then, have constraints that make them “stick” to the weapon bone. But unlike how an IK bone is normally handled, this weapon bone I made is also holding the weapon mesh, visually. So it also counts as a “deforming” bone. This kind of makes it a “floating” bone, independent of the rest of the rig.

To explain the problem, I need to explain what root motion is. Root motion eliminates that foot sliding phenomenon with 3d models who play a walk animation in-place, and is just moved in the game engine.

Foot sliding happens because most of the time, the programmer's code moves the character only by a constant speed, but due to how some walk/run animations work, in reality, the character speed shouldn’t really be constant.



If you study how your body moves while jogging or running, you may notice there’s tiny moments of acceleration and deceleration that happen on each step. This is especially evident if the character’s animation has a weird gait, like if they’re limping on one leg (or have poop in their pants).

Root motion works by having an animation that isn’t walking in-place. The animation is made to move the whole rig forward (enough for at least one walk cycle, so it can be properly looped). This is where the animator uses their skill to ensure that the forward movement looks natural with each step, that the feet don’t slide as the body moves forward. (Or if you're importing motion capture data that you created, this is the part where you'd be cleaning it up.)



When that move animation is played in-game, the game engine “extracts” that forward movement from the animation, negates it from happening to the 3d model, and instead puts that motion into the game object in the game.

You only need to negate the motion from the root of the rig (usually the pelvis/hips). This is because all the bones are ultimately parented to the root bone anyway. So when you move the root bone, everything else follows.

But I made this weapon bone to be independent of the skeleton structure, so it has to be its own root motion, even though it’s a child object of the rig. There’s probably some crazy math that can pull it off, but all my attempts haven’t worked so far, so I’ll try that again some other time.

____________________

EDIT: This silly trick with putting 3d models isn't needed anymore. I realized, if I parent the weapon bone to the root bone, and adjust the root bone's orientation to where Unity expects it, the weapon bone moves properly.

T̶h̶e̶ ̶t̶r̶i̶c̶k̶ ̶I̶ ̶e̶n̶d̶e̶d̶ ̶u̶p̶ ̶d̶o̶i̶n̶g̶ ̶t̶o̶ ̶m̶a̶k̶e̶ ̶i̶t̶ ̶w̶o̶r̶k̶ ̶i̶s̶ ̶a̶ ̶l̶i̶t̶t̶l̶e̶ ̶s̶i̶l̶l̶y̶:̶ ̶i̶t̶’̶s̶ ̶t̶w̶o̶ ̶3̶d̶ ̶m̶o̶d̶e̶l̶s̶ ̶p̶l̶a̶y̶i̶n̶g̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶ ̶a̶n̶i̶m̶a̶t̶i̶o̶n̶ ̶s̶i̶m̶u̶l̶t̶a̶n̶e̶o̶u̶s̶l̶y̶.̶ ̶O̶n̶e̶ ̶h̶a̶s̶ ̶r̶o̶o̶t̶ ̶m̶o̶t̶i̶o̶n̶,̶ ̶b̶u̶t̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶w̶e̶a̶p̶o̶n̶ ̶b̶o̶n̶e̶ ̶t̶u̶r̶n̶e̶d̶ ̶o̶f̶f̶ ̶(̶a̶l̶t̶h̶o̶u̶g̶h̶ ̶i̶t̶’̶s̶ ̶s̶t̶i̶l̶l̶ ̶b̶e̶i̶n̶g̶ ̶a̶n̶i̶m̶a̶t̶e̶d̶)̶.̶ ̶A̶n̶d̶ ̶I̶ ̶h̶a̶v̶e̶ ̶a̶n̶o̶t̶h̶e̶r̶ ̶d̶o̶i̶n̶g̶ ̶t̶h̶e̶ ̶e̶x̶a̶c̶t̶ ̶s̶a̶m̶e̶ ̶t̶h̶i̶n̶g̶,̶ ̶b̶u̶t̶ ̶w̶i̶t̶h̶ ̶r̶o̶o̶t̶ ̶m̶o̶t̶i̶o̶n̶ ̶u̶n̶c̶h̶e̶c̶k̶e̶d̶,̶ ̶a̶n̶d̶ ̶i̶s̶ ̶p̶a̶r̶e̶n̶t̶e̶d̶ ̶u̶n̶d̶e̶r̶ ̶t̶h̶e̶ ̶f̶i̶r̶s̶t̶ ̶3̶d̶ ̶m̶o̶d̶e̶l̶.̶

T̶h̶i̶s̶ ̶i̶s̶ ̶a̶l̶l̶ ̶j̶u̶s̶t̶ ̶t̶o̶ ̶h̶a̶v̶e̶ ̶t̶h̶e̶ ̶w̶e̶a̶p̶o̶n̶ ̶b̶o̶n̶e̶ ̶n̶o̶t̶ ̶b̶e̶ ̶s̶u̶b̶j̶e̶c̶t̶ ̶t̶o̶ ̶r̶o̶o̶t̶ ̶m̶o̶t̶i̶o̶n̶,̶ ̶b̶u̶t̶ ̶i̶s̶ ̶s̶t̶i̶l̶l̶ ̶p̶a̶r̶e̶n̶t̶e̶d̶ ̶t̶o̶ ̶t̶h̶e̶ ̶g̶a̶m̶e̶ ̶o̶b̶j̶e̶c̶t̶ ̶t̶h̶a̶t̶ ̶i̶s̶ ̶b̶e̶i̶n̶g̶ ̶m̶o̶v̶e̶d̶ ̶b̶y̶ ̶r̶o̶o̶t̶ ̶m̶o̶t̶i̶o̶n̶.̶



O̶n̶e̶ ̶o̶f̶ ̶t̶h̶e̶m̶ ̶i̶s̶ ̶d̶o̶w̶n̶ ̶o̶n̶ ̶t̶h̶e̶ ̶g̶r̶o̶u̶n̶d̶ ̶t̶h̶e̶r̶e̶ ̶b̶e̶c̶a̶u̶s̶e̶ ̶I̶’̶v̶e̶ ̶h̶a̶d̶ ̶t̶o̶ ̶r̶o̶t̶a̶t̶e̶ ̶t̶h̶e̶ ̶3̶d̶ ̶m̶o̶d̶e̶l̶s̶ ̶a̶ ̶b̶i̶t̶ ̶(̶w̶h̶e̶n̶ ̶y̶o̶u̶ ̶s̶t̶a̶r̶t̶ ̶t̶h̶e̶ ̶g̶a̶m̶e̶ ̶t̶h̶e̶y̶ ̶f̶i̶n̶a̶l̶l̶y̶ ̶a̶d̶j̶u̶s̶t̶ ̶t̶o̶ ̶t̶h̶e̶ ̶p̶r̶o̶p̶e̶r̶ ̶o̶r̶i̶e̶n̶t̶a̶t̶i̶o̶n̶)̶.̶ ̶I̶ ̶s̶u̶s̶p̶e̶c̶t̶ ̶i̶t̶’̶s̶ ̶b̶e̶c̶a̶u̶s̶e̶ ̶B̶l̶e̶n̶d̶e̶r̶ ̶m̶a̶k̶e̶s̶ ̶u̶s̶e̶ ̶o̶f̶ ̶t̶h̶e̶ ̶Z̶-̶a̶x̶i̶s̶ ̶a̶s̶ ̶i̶t̶s̶ ̶u̶p̶-̶t̶o̶-̶d̶o̶w̶n̶ ̶d̶i̶r̶e̶c̶t̶i̶o̶n̶,̶ ̶w̶h̶i̶l̶e̶ ̶U̶n̶i̶t̶y̶ ̶u̶s̶e̶s̶ ̶Y̶-̶a̶x̶i̶s̶ ̶f̶o̶r̶ ̶t̶h̶a̶t̶.̶

I also found that the root motion bone has the same problem. I think Unity expects it to be oriented such that the Y-axis of the bone is pointing upward. By default, Blender Rigify gives me a root bone with the Z-axis as the up. So when I use that as the Root Motion Node in Unity, it ends up flipping the whole 3d model:



It’s a little annoying because the Unity user manual neglects to mention these things.

I could edit the rig so it’s pointing at the right direction. But I usually just compensate for this by applying a rotation to the 3d model once it’s a game object in the scene.

Maybe next time I’ll try figuring out a better way to do all this.

 

First pass on a generic move animation. It’s been years since I last made run/walk cycles, and this is the first time I’m doing it with root motion in mind.

I’ll probably just use this as a template for future move animations.

There’s still a bit of foot sliding (see rightmost part) but I will try to fix that. I don’t know if Blender has some tool to temporarily anchor a foot IK in place while I move all the other bones.

This was my reference for the animation:

That reference video’s actually at half-speed but I think it works fine to show the heaviness of the armor.

 

Progress is slow, lots of trial and error, and lots of waiting whenever Unity reimports the 3d model each time I try a fix, but got my test root motion thing working. It’s been a pain getting a Rigify rig from Blender to work properly in Unity.

 

Damn, cloth weight painting went from bad to worse in 2017.4.6f1. I was even content with what they had in Unity 5.5, at least I didn’t have to work on it upside-down.

I was looking forward to the improvements like having an actual brush, but turns out it doesn’t have pressure sensitivity or even just a simple soft circle brush (with a falloff) or anything like that.

Sometimes I wish I could just make a vertex group from Blender since weight painting is easier there, and somehow import that to Unity’s cloth component.

I have a feeling this is because my 3d model is from Blender, where the Z-axis is used for the up-down direction (Unity uses Y-axis for that). Seems like Blender doesn’t really get enough love from the Unity guys. It’s all been Autodesk from what I noticed recently.

I eventually did get the cloth component working properly.

Sometimes Unity demands hand-eye coordination gymnastics.



Anyway, the whole reason I was working on this was since I was about to test integration of the 2nd armor into the game, I thought it was worth cleaning up the rig of the 1st armor, using the lessons I learned from how to best make a Blender Rigify rig work with Unity, when I was making the 2nd armor, and also optimizations (like the Rig’s Optimize Game Object trick, which I didn’t use before). I needed to make the rigs consistent anyway (some bone names were inconsistent) cause they need to blend animations to each other when the player swaps armor.

This was quite the undertaking, since any edit to the rig will require re-importing all the animations made with it (54 of them, so far). Re-importing one animation clip takes what feels like 5 minutes, so it'll take a long while with those 54 animations. Any mistake I make would mean I need to re-import all over again, so I needed to be careful about it.



Speaking of taking long, I actually started looking for alternatives from Evernote, since that program really lags bad. I got about hundreds of notes there now, and whenever I create a new note, the window just goes unresponsive for too long.

I’m currently trying out Laverna. It doesn’t have a WYSIWYG text editor (it uses markdown), and it doesn’t have the convenient web clip tool that Evernote has, so I’ll probably keep using Evernote for taking web pages.



I'm still looking if there's better alternatives out there.

 

Speaking of weird bugs, this was another one I encountered. The main Unity Editor window kept insisting there was some modal window that needed my attention but I can assure you there was no confirmation dialog box asking me for ok/cancel or anything like that.

This happens every now and then (not all the time, which makes it difficult to pin down the cause) whenever Unity finishes importing a 3d model, after I made changes to it.

The only way I could continue whenever this happened was to kill the Unity Editor from Task Manager and start it again.

That assert message in the console log also looked suspicious. It says: Assertion failed on expression: ‘s_AssetProgressBar.dialog’ The problem is that there are times when this bug happens but no assert messages show up. So I don’t think that assert was the cause.

 

More headaches with trying to get my 3d model from Blender (exported as fbx) to work properly with Unity.

The moment I assign the Root Motion Node with my root bone (the one provided by Rigify), it rotates the entire character 3d model through some weird values. What’s even weirder is that my weapon bone seems to be unaffected, even though it is parented to the rig's root bone.

Take note that if I assign no Root Motion Node though, everything works fine.

This is the root bone’s orientation: +Z is up, +Y is pointing backwards, +X is pointing to the character’s left side.



The problem is that I see no way of undoing that weird rotation that Unity gives to the 3d model. There’s no “Offset Rotation to Root Motion Node” property that I could just edit.

I tried a lot of things to fix it. None worked. As an experiment, if I rotated the root bone like this:



I now get the opposite in Unity: having no Root Motion Node gives the character a weird rotation, but assigning the root bone fixes it. Interestingly, the weapon bone still looks like it’s unaffected regardless of what situation.



Of course since I rotated the root bone of the rig, that made the whole animation move weird:


That's because all the IK bones are parented to the root bone. So when the root bone's position or rotation is adjusted, they all follow.

Whereas, this was how it originally moved:


If you look carefully, all the up-to-down motions of the IK bones were turned into forward-to-backward motions.

If I edit the motion curves of the animation I end up with how the original animation looked like.

So I thought I'll just go with this solution. That requires me editing all the existing animations I have (54 of them used, but there are a lot of others like attack variations I made but haven't used). But instead of doing it manually, I'll be making a Python script (I'm taking a break from all this stress first).



This is at least, the nice thing about Blender, and the advantage for me for being competent with both art and programming in that I can devise solutions like this on my own.

The Python script will flip the motions of the IK bones automatically for me, because it would be a nightmare to have to go and manually fix all the animations I made so far for the character (all the idle animations of the 3 weapon stances, attack animations, dash animations, hit animations, etc.), but I wish there was no problem to fix in the first place.

So momentum on the game’s progress is severely dampened while I had been fixing this. Is it Unity’s fault? Is it Blender’s? Is it the FBX file format? I honestly don’t know, and I’m too tired to think about it right now.

And yes I’m familiar with the configurable Up and Forward axes in Blender’s FBX exporter. Those settings work if the character has no Root Motion Node. But the moment the Root Motion Node is assigned, they are apparently ignored. No amount of changing them resulted in any change upon re-importing to Unity (and remember this is with a Root Motion Node assigned).





All of this headache, caused by this dichotomy:


Why the hell did people make use of different coordinate systems? I think Tim Sweeney explained it best:


(from https://forums.unrealengine.com/community/general-discussion/46691-z-up-vs-y-up-the-solution-to-the-debate-lies-within?p=467047#post467047)

I have no problem that we ended up with these coordinate systems, I just wish the export/import scripts did their job properly.

 

I finally finished with my Python scripts that fix the rig.

In my other experiments, I tried out the “@” notation that Unity has, like it mentions in the manual: https://docs.unity3d.com/Manual/Splittinganimations.html



I ended up with lots more files. But it turns out, even though there’s the extra step of exporting them to FBX files before importing to Unity, the whole time it takes is quicker than when I was using .blend files in the project.


Note: Unity seems to dislike having “.” in animation names. Names like “Rapier.Move.Forward” get renamed into “Rapier_Move_Forward” when imported to Unity, for some reason. This was the same with my rig’s bone names. Names like “ORG-forearm.L” in Blender turns into “ORG-forearm_L” in Unity, so I decided to just stick with it.

Originally, I was going with one .blend file per group of animations:



While it did feel convenient just having the .blend files themselves in the project, it had one big disadvantage: anytime I edit an animation, re-import times are extremely slow.

If I change even just 1 animation inside a .blend file, Unity has to completely re-import all animations inside it, because re-importing works on a per-file basis.

What’s worse is that each of them have their own copy of the character’s mesh (I need to see the character when animating). Which means even when I only edited 1 animation in it, Unity has to re-import not only the other animations, but also the mesh inside that .blend file.

That’s why re-importing (what I thought was only 1 animation) takes so long.



So while the idea that having the .blend file directly in the project might feel like you’re giving yourself quick iteration time, once you’re working with lots of animations, it really doesn’t.

____________________​

But the extra step of having to click on Export FBX is a hassle, right? This is why I made myself a Python script for quick exporting.

Initially, to convert all my existing animations from the .blend file into those FBX files, I made a script that calls the FBX exporter script to “batch” export all animations I want in one go, using the “character_name@animation_name.fbx” notation that Unity uses. This not only makes it convenient for me, it also assured me that each animation was exported consistently, with the same settings.

I don’t have a GUI for this (learning the Blender Python API was already quite a lot, so I hadn’t bothered learning to make custom Blender GUI, although at initial glance, it reminds me of Unity’s IMGUI), so it has to be run from Blender’s Text Editor.

For new animations, I’ll be making another Python script to export only that animation. The idea with this script is that it should have minimal GUI, and fast. Same as the experience you get when you press Ctrl + S to save.



So something like Shift + Alt + S to export the currently viewed animation into an FBX file, again using the “character_name@animation_name.fbx” notation. The script would be exporting it with the settings I know will work in Unity (FBX 6.1 ASCII version, with only the selected armature and action exported, and nothing else).

I’ll probably release these Python scripts as open-source, later on.

____________________​

On the Unity side of things, configuring the import settings for each of these animation FBX files is a hassle, because normally it would work like this:

1. copy the file into your project’s Assets folder
   
2. Alt+Tab into the Unity Editor
   
3. before you can react, Unity imports the file, since it detects the file as new (or changed)
   
4. you go to the file and configure its import settings
   
5. you click on Apply and Unity imports it again

This means for each file, Unity has to import it twice. It’s also a chore to go and click the proper checkboxes for the import settings you want for all of these FBX files, assigning the proper Avatar definition file, the Avatar Mask file, setting the animation’s loop to true if it needs to, etc.

So I made an AssetPostprocessor script to do it for me. I also made a ScriptableObject to store my settings for these, that I named CharacterImportSettings. I could have several of these CharacterImportSettings, so I have one for the Desparo character, another for the Demento character, etc.



I know Unity 2018 has this new feature called Presets which works the same (I only use Unity 2017.4 since that is the “long-term stable” release). Some reading into it shows that, using an AssetPostprocessor, you can effectively apply a default import settings to all assets in a given folder. Very similar to the script that I ended up making.

The script I made works based on filename matching. I guess the only advantage with mine that I can think of is that it can automatically mark an animation to loop based on the animation name.



So an animation from the file “Desparo@Spear_Standing.fbx” will be automatically set to loop, while something like “Desparo@Spear_Attack_Thrust_1.fbx” won’t be.

____________________​

I’m also happy with this since now I don’t have to use the cumbersome controls for adding Extra Transforms to Expose (who in Unity thought this was good enough?!?):



Adding an Extra Transform to Expose meant having to click through menus on top of menus to get to the bone you want, each time starting from your rig’s root. And these menus can instantly vanish if you accidentally clicked outside, requiring you to do the whole thing all over again.

What I have doesn’t really fix this problem, it’s just a workaround so I don’t have to use those controls. I have a string array storing the values (which I had to type), and they’re applied using the AssetPostprocessor script I have.

I reuse the same type of rig for all the biped characters I make in Blender, so this is a huge time-saver.



The reason I have so many of these Extra Transforms is because I add colliders to the body parts. Those colliders are needed by the cloth simulation so that the cloth doesn’t pass through the character, and they’re also used by the combat system to detect hits. I also attach particle effects and lights on certain body parts.



I’ve also edited my Mecanim state machines to make use of the new animations, so everything’s now good to go.

The lesson here: just export to the goddamn FBX files, Unity does that anyway under the hood when you place .blend files into the project. You’ll see a “Unity-BlenderToFBX.py” inside your installation folder for Unity, normally under the “Editor/Data/Tools” subfolder. It’s a small script that finds and calls Blender’s FBX exporter script.

And make scripts to automate repetitive chores.

 

Awesome progression you have here.

 

After weeks of fixing the rigs of these 2 guys, the test for armor swapping finally works. Will obviously still need to add effects, and the other armor isn’t textured yet.
This is one of the first few ideas I ever had for the game, 4 years ago, when it was all still just a thought in my head.

@Darrkbeast: Thanks!

 

Testing the movement with root motion.

I decided to make use of the same Animator Controller that the first armor uses, which doesn’t use root motion. So far, that doesn’t seem to be a problem.

I just made an additional bool parameter “HasMoveStop”, so that whenever the player stops moving, it will use the new “Move_Stop” state I made, before it goes back to “Standing”. Whereas Desparo (the first armor) has its “HasMoveStop” set to false, so it will just move straight to “Standing”.

This is purely cosmetic, you’ll be able to attack even when the “Move_Stop“ animation is still being played. The game will consider you to be already in Idle state at that time.

It can get annoying when you just want to quickly turn around, so I think I’ll make a shortened, more subtle kind of Move_Stop animation when the character hasn’t moved too far, maybe a “turning around in-place” kind of animation, or maybe both, blended together if it makes sense.

I found it highly useful to create a mock third-person camera view in Blender while I’m animating so I can see how the animations look like before I put them in Unity.

 

Fixed the foot sliding in the move forward animation. Having that UV grid test as a floor was useful for checking.

 

It’s badly rough but I’m slowly starting to get this “turning in place” animation working. This is based on the Unity Mecanim Locomotion Starter Kit. My old non-root-motion-aware rotation code is interfering with the whole thing, and overall, I think the animations I made are too slow, so I’ll be fixing this next time.

 

So I realized I was making things more complicated than needed. The per-45 degree rotations really just made the whole movement more sluggish.

I suppose you could think of control tightness as a scale, with responsiveness on one end and realism on the other.



For games like Dark Souls 1 and Nioh, they lean more on the responsive side. If you flail your left analog stick around wildly, the game will happily oblige and move/rotate the character in a similar manner. And in those games, if the rotation is less than 180 degrees, there is no special turn animation, and the rotation is most likely just done via code. Though I should note that you won’t just see the 3d model rotating, because it’ll actually end up blending from the idle animation to the movement animation for a little bit.

For 180 degree turns, there’s a special animation.

And I should note that that is for rotations being done coming from a “standing still” position. For other situations like turning while in a run animation, there’s an appropriate “turning while running” animation, but still, it’s only for 180 degree turns (at least for Dark Souls 1 and Nioh).

I guess it makes sense since tight controls are needed for the kind of combat system they have, where it’s about precise movements.

About them having a special animation for 180 degree turns, it makes attacks from behind a viable option. You need to be mindful of any threats coming from your back, so that bit of slowness for turning 180 degrees (because of the turn animation) I guess helps make it more important. On the other hand, it’s also something you can exploit from your enemies. It takes them a little bit more time since they have to turn towards you, so encircling your enemy and attacking from behind can work (not all the time obviously, but it can for certain enemies and/or situations).

(For something like an Assassin’s Creed game, the parkour element is pretty major, so it made sense for them to go for movement controls that people describe as “loose” or “floaty”. As a side note, because of those loose movement controls, it also makes sense that they made the combat far more simple in exchange: a single attack button press will also automatically make your character move/lunge in the appropriate distance to hit a targeted opponent from afar.)

So I prepared a 180 degree turn animation that was faster (compared to the ones I made earlier):



It does look awkward. The animation is too fast compared to what a person might sensibly do in reality, anything slower tends to just slow down the character as a whole in-game. Also, the turn animation needs to put the character in the exact same idle pose as before (left foot forward, right foot at the rear).

However, it doesn’t really work well in-game. It’s supposed to be a 180 degree turn, but it ends up turning about 90 degrees only:



As it turns out, rotation from root-motion won’t be accurate.

From https://forum.unity.com/threads/apply-root-motion-rotating-object-not-accurate.439476/#post-2845764:

The important bit is:

As was explained there, you kinda end up having to do rotations from code if you want them exact.

Now, to make sure the code-driven rotation is sync’ed to the animation, I added a curve to the animation that represents the part of the animation where the rotation happens:



So that curve moves from 0.0 to 1.0 to represent the rotation. 0.5 means it’s halfway through, 0.75 means 75% complete, etc.

Then I use Quaternion.Lerp to rotate the character. And I’m using the current value of that “RotationPercent” to blend from the starting rotation to the final value.

Though it doesn’t look quite right compared to the original animation:



Here’s the original animation in comparison:



It seems that in-game, the rotation is not pivoting from the right spot. This animation’s root-motion also has a bit of movement in it, and it seems to me that it’s not getting applied properly in-game. So I’ll be trying to improve my code later on. Maybe I’ll also need to lerp the position change as well.

 

Sorry about the lack of updates. I have been posting updates in my devblog, but I've neglected sharing them here for a long time, so I'll start reposting them bit-by-bit.

This is from 2018 Nov. 20:

It’s difficult to get back into the groove when you take a break, so my progress is dampened right now.

Anyway, here’s the progress for the weekend.

Since I removed most of the special turn animations, I went back to the regular way of turning the character: it’s just rotated in code. The problem was that the run animation gave it forward movement, which was still happening while in the middle of turning.

The fix is simple: I minimize any position change while the 180 degree turn was occurring.

It detects a 180 degree turn by checking a threshold, so this doesn’t matter if the user input is forward-to-backward, left-to-right, or even diagonals. It should work the same.

It does look odd for such a top-heavy looking character to be able to turn that easily. I have a few simple ideas to fix that, but I’ll save that for later on, because I really need to focus on more feature implementations instead of polish.

 

Just a minor progress post for now. I’m making the UV layout for the 3d model now since I think I’m ok with the way it animates (no parts of the armor clipping through each other when he runs).

The one on the left is the first step in texturing, where I use a test grid image to see if there’s any undesired stretching to the texture once the 3d model is posed.

You usually have to watch out for the joints: shoulders, knees, armpits (when the arms are animated to stretch out), even the butt. You can’t completely eliminate the texture stretching in those areas. They naturally happen when the limbs move around (due to animations). But it makes sense to minimize it as reasonably possible, because it does look ugly when the stretching goes too far.

I can see the area on the scarf does stretch pretty bad, so I think I need to revisit the skinning on that part.



It’s something I wouldn’t have realized until I see the 3d model with the test grid texture.

 

Today in Blender, I learned you could do gradients for skinning weights.

There’s two types of gradients. Linear (Alt+LMB):


and Radial (Ctrl+Alt+LMB):


It may not work if you have Emulate 3 Button Mouse turned on, since that uses Alt+LMB, and Ctrl+Alt+LMB too. So you may want to reassign the hotkeys for Weight Gradients (I changed mine to use middle mouse button instead).

You can also apply the gradient subtractively, to remove weights. (Just switch to the subtract brush before using it. Basically, it will use whatever brush you’re currently using.):

 

Finally finished with the UV maps.

I bought Blender add-on UVPackmaster cause it really helped out here. It adjusts the UV islands way better than the default Pack Islands command. It’s got a demo version you can try out if you're curious.

For a high-poly version to make normal maps from, I just duplicated the model and added the subsurf modifier (I could sculpt on it for further details, but I’m really lazy, I just add more detail later in Substance Painter).

The only way I add detail to the subsurf’d model is the lazy way, by adding creases to create sharp edges/corners:


Even though it’s cheap, it does give a decent (starting) normal map when baked:


I’ll be putting this into Substance Painter next, to further refine the normals, and create the rest of the textures (albedo, metallic/roughness, ambient occlusion, etc.)