Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411278 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 12:53:31 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsGhost Knight Victis - Heroic Dark Urban Fantasy - Action RPG
Pages: 1 ... 4 5 [6]
Print
Author Topic: Ghost Knight Victis - Heroic Dark Urban Fantasy - Action RPG  (Read 14523 times)
AnomalousUnderdog
Level 1
*



View Profile
« Reply #100 on: July 23, 2018, 04:22:42 AM »



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.
Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #101 on: July 29, 2018, 02:10:53 PM »





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.
Logged
Pixel Noise
Level 10
*****



View Profile WWW
« Reply #102 on: July 30, 2018, 10:22:40 AM »

Dude that transition looks awesome already, even knowing there's still work to be done with it!
Logged

Pixel Noise - professional composition/sound design studio.
 https://soundcloud.com/pixel-noise
 https://twitter.com/PixelNoiseMusic
 https://pixelnoisemusic.bandcamp.com/

Recently completed the ReallyGoodBattle OST!  https://www.youtube.com/watch?time_continue=2&v=vgf-4DjU5q
AnomalousUnderdog
Level 1
*



View Profile
« Reply #103 on: August 05, 2018, 07:47:04 PM »





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.





___________________________________



Dude that transition looks awesome already, even knowing there's still work to be done with it!

Thanks!
Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #104 on: August 05, 2018, 07:47:38 PM »

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.



Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #105 on: August 14, 2018, 07:19:03 PM »





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



View Profile
« Reply #106 on: August 28, 2018, 09:06:20 AM »





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.
Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #107 on: August 29, 2018, 08:41:44 AM »

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:
Quote
…Unity is updating the animation system with a delta time each frame … So since the turnLeft animation clip was never evaluated at 100% your root motion won’t get the full 90 degree rotation you would expect.



The only way to have a precise root motion is by script
https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnAnimatorMove.html

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.
« Last Edit: August 29, 2018, 10:33:43 AM by AnomalousUnderdog » Logged
LunaticDancer
Level 0
***

Unveil the curtains of sanity!


View Profile WWW
« Reply #108 on: August 29, 2018, 09:18:49 AM »

Man, what a legend! You sure are writing up a saga in here, great job.
I love how the armor changing looks.
Logged

AnomalousUnderdog
Level 1
*



View Profile
« Reply #109 on: January 01, 2019, 03:00:29 PM »

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.
Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #110 on: January 03, 2019, 05:50:20 AM »



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.
Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #111 on: January 06, 2019, 07:53:08 PM »

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.):
Logged
MegaTiny
Level 1
*


Wew lad


View Profile
« Reply #112 on: January 07, 2019, 05:03:11 AM »

That blender tip is genuinely life changing for me. Thank you!
Logged

AnomalousUnderdog
Level 1
*



View Profile
« Reply #113 on: January 13, 2019, 04:16:33 AM »



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



That blender tip is genuinely life changing for me. Thank you!
You're welcome!
Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #114 on: January 28, 2019, 05:16:13 AM »



I had to go and redo the UV because I left some holes in the model that I had to fix. That meant rebaking the normals, and I thought I might as well go and bake ambient occlusion. Now I got some nice self-shadows.

I only used procedural materials in Substance Painter so far, so it was easy to transfer my work to the updated model.

This is only smart materials right now, just with simple tweaks. Only after this will I start any manual painting, because I am a super lazy guy.



And man, I really wish you can hide thumbnails in the Layers window. It keeps on having to update them every time I switch to a different channel, and it’s slowing down the whole program.

Logged
agsoper
Level 0
*



View Profile WWW
« Reply #115 on: January 29, 2019, 03:42:41 PM »

Wow. Strong work. Keep it up.
Logged

Composer (ValeGuard)
AnomalousUnderdog
Level 1
*



View Profile
« Reply #116 on: March 19, 2019, 06:29:05 PM »

(sorry I forgot posting here, I'll slowly drip-feed my backlog of updates)





Done texturing this armor, here's how it is inside Unity (sword not textured yet).
Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #117 on: March 21, 2019, 03:25:35 AM »



I mistakenly thought that even if I did a bad job hiding the seams, that it wouldn’t matter thanks to Substance Painter. I mean, I could paint across the seams, can’t I?

These upper leg armor pieces for example, I put the seams at the back.



But it turns out it was really difficult the paint the seams away, because they’re coming from the seams in the UV layout. Here’s the baked normal map to show it more clearly:



I could try to edit this normal map and mirror one side to the other, but it isn’t so easy in Substance Painter.

In the end, I realized I was just making things harder for myself, so I redid the UVs for the affected areas. Now I hide the seams at the front, at a part where there’s naturally a sharp edge:



It’s hardly noticeable now:



Now the back part doesn’t have ugly seams:



So I guess, skillful judgement on where to put UV seams are still important.
Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #118 on: May 13, 2019, 05:37:31 PM »



Had a bit of a panic attack when I was checking the textures. There were these stretch marks on certain parts.

I thought there was something wrong with the way I exported the textures from Substance Painter. I kept re-exporting them over and over with different settings to see what I did wrong. I thought maybe I needed to re-do the entire texture from scratch.

Then I realized I had used this in Unity’s mesh import settings:


I was previously playing around with the settings and I set it to High cause I thought that was a good thing to do.

As it turns out, this Mesh Compression setting is lossy. The higher you set the compression ratio, the more artifacts you get.



Mesh Compression only compresses the way the vertex data is stored on file. Once the game is running, it still occupies the same amount of RAM as a non-compressed mesh. It doesn’t reduce the amount of polygons, and it doesn’t increase runtime performance.



So I just set it back to Off, and things went back to normal.

In all honesty, the high mesh compression looks horrendous. I can’t imagine where I might need such a thing. Maybe if I was making a game for web or mobile and needed to keep the build size low, I would try this for props and other static objects. Also, it’s probably more beneficial for a cartoon style shading where you might only be using solid colors for most parts of a texture. If so, then the artifacts from high mesh compression may end up not being too noticeable.
Logged
AnomalousUnderdog
Level 1
*



View Profile
« Reply #119 on: June 09, 2019, 07:35:14 AM »

Textured the Greatsword.





Here’s how the whole thing looks like in Unity. I will still be adding fire particle effects on the eyes and the chest.



Logged
Pages: 1 ... 4 5 [6]
Print
Jump to:  

Theme orange-lt created by panic