hypertensiongamedev

[hypertensiongamedev]

So before reverting to the old way of adding torso lean, I read about the Animation Rigging package and it looked really cool. I had to update the project to 2019.1 just to try it out since it only works there.

I had my doubts that it would work. I did not expect that it would actually crash Unity. Even trying to send the bug report didn’t work at first.

It seems to me any kind of real-time IK or bone manipulation really won’t work well if you turn on Optimize Game Object in the model’s import settings.

So I guess I have to give that one up. I anticipated I’d have to recreate my character prefabs all over again after changing the import settings, but thanks to having them set up as prefab variants, it was actually effortless turning off  Optimize Game Object.

At this point though, I had the option to stay in 2019.1 or go back to 2018.4. Once I turned off Optimize Game Object, I found that I could make Animation Rigging work, and I gotta admit it was pretty nifty. But in the end I decided to go back to 2018.4. There’s too many annoying bugs in 2019. I mean, what is up with this:

I really shouldn’t have bothered with all of this though. I should be concentrating on implementing gameplay mechanics, even if I’m using unoptimized settings or old features, instead of wrestling with new but broken API.

[hypertensiongamedev]

I managed to make the lean up-down animation as a base layer with everything else as an additive layer. It works fine for the Idle animation, but in certain attacks, the animation really seems like it doesn’t want to work correctly.

I don’t know what’s going on with his right hand there.

So looks like I really will have to turn off “Optimize Game Object” for the 3d model.

The reason why this is such a problem is that Optimize Game Object improves performance, and I’m gonna have to sacrifice that.

This was how I was doing it back then: https://hypertensiongamedev.tumblr.com/post/166411467798/testing-torso-leaning-up-and-down-i-will-be-using

[hypertensiongamedev]

Since I turned on “Optimize Game Object” on my 3d models, I can’t do the usual way of manipulating bone transforms in Unity to make the torso lean up/down for angling attacks above or below.

My initial thought was to create an additive Animator Controller layer with a simple looking up-to-down animation paused on the angle I want it to. Since it’s on an additive layer, the angle is applied on the idle and attack animations when I want it to.

Unfortunately, it doesn’t work well with my custom weapon bone:

I’m not sure if it’s the weapon or if it’s the hand that’s in the wrong position here.

So I decided to try manipulating the bones from script. Animator has a SetBoneLocalRotation() method. The problem is, it overrides the bone’s rotation. I can’t seem to figure out how to apply an additional rotation to it, on top of the currently playing animation.

Using localRotation of the transform you get from Animator.GetBoneTransform() as the initial value doesn’t work. It just ends up in a wrong value.

It seems the “local” referred to in SetBoneLocalRotation isn’t what I think it is.

Even then, SetBoneLocalRotation can only manipulate the designated human bones. There’s no way for me to rotate the weapon bone with that.

I was about to give up and turn off “Optimize Game Object” when I thought of applying the lean animation as a base (instead of it being additively applied), and then the idle animation will be the one additively on top of it.

Somehow, it works that way instead.

My problem now is to adjust my Animator Controller state machine so that the Lean animation is applied first, then the idle or attack animations are applied additively to that as necessary.

Unfortunately, I can’t even drag-and-drop Animator layers around due to a bug in Unity (thanks, Unity). I may try reordering layers around from the Editor API instead for now. I’ll try again next time.

[hypertensiongamedev]

Finally done transitioning the project to Unity 2018.3′s new Prefab format so I can focus on progress again, here's fire effects on the 2nd armor.

[hypertensiongamedev]

I made a free PropertyDrawer prevent labels in the Unity Inspector from getting cut off, and make better use of that available space.

https://github.com/AnomalousUnderdog/UnityCompactFieldAttribute

[hypertensiongamedev]

I tried my hand again at creating description PropertyDrawers.

At first I just made them simple labels that show below the property. I realized it made the Inspector GUI too “noisy” since there’s so many words on-screen now. I figured I could do better.

My problem with Unity’s default tooltip behaviour is that it doesn’t always show up. Notice how the 2nd time I bring my mouse to the “Bounce Threshold” property here, the tooltip refuses to show up. I had to shake the mouse before it recognized:

I wanted an icon to clearly indicate that a property had a tooltip. This was also something that annoyed me a bit with Unity in that you’re not sure if a property actually had a tooltip that isn’t showing up because you moved your mouse too much, or maybe it doesn’t really have a tooltip in the first place. So sometimes I end up leaving my mouse on the property label, waiting for a tooltip that I’m not sure will come out or not.

I would have preferred to move the icon to the right of the label (in between the label and the field) but I doubt there’s an easy way to do that.

Making PropertyDrawers draw on top of the other GUI proved to be difficult. I have no control over the rendering order of the properties so this would happen:

So instead I created an EditorWindow and used the internal method ShowTooltip() to make it look borderless and not steal window focus when it shows up. I had to use reflection to make it work.

I also had to get the Inspector’s current scrollbar value via reflection since I position the tooltip manually, and it doesn’t automatically take that into account.

[hypertensiongamedev]

I’m still converting my characters to use the new nested prefabs format. It’s taking a while, as I essentially have to recreate them, ensure that the properties on each component is set properly.

I took the time to also switch from UnityEvent to just plain C# event/delegates. I found UnityEvent to be problematic for a time now and have always wanted to stop using it. It is very convenient, but the convenience is also what makes it easy for me to mess it up.

For example, if I accidentally deleted the object assigned to the UnityEvent, or if I renamed the method it was supposed to call (which means it can’t find the method to call anymore), it doesn’t count as a compile error (compared to if I subscribed to an event in C# code), so I won’t notice it easily. I’ve experienced a couple of bugs because of this, and took me a while to pinpoint the cause.

So when I get something like this:

I end up wondering why I have an empty listener there in the Death Event. I’d rack my brain figuring out what the value there used to be. Then I end up cloning my project’s git repository, checkout an old commit to see what it was. It’s quite a hassle, considering the git repo has grown to about 9+ GB in size.

[hypertensiongamedev]

kzantezuken said:

So you suggest to use Variants only? Will it still function if you delete original base prefab afterwards?

I suppose it's still up to you, if you have a different method that works better for your project, then go ahead.

If you delete the base prefab that a variant uses, you probably could still salvage the data somehow, but naturally, the connection will be lost.

Back then, before the new Prefab workflow was around, the common way I deal with Prefabs is to have the 3d model parented under an empty Game Object first. This empty would contain all the script components and whatever I need to make it work in the game. The 3d model is under that as a child Game Object, so I could easily replace it, if need be.

I made it a habit not to put script components on the 3d model's Game Objects (i.e. the bones), since, as I explained in my previous post, the moment the rig is edited from Blender, the Skinned Mesh Renderers in a regular Prefab stop working.

If I added colliders onto the 3d model's bones in Unity (for ragdoll functionality, for example), then once I edit the rig from Blender (say for example, I decided to add wings to the character), I had to recreate those colliders from a new copy of the 3d model instance.

[hypertensiongamedev]

Editing the rig of a Blender file breaks regular prefabs that use it (this was a long-standing issue that was never fixed). As far as I know, this problem only happens in Blender since its FBX exporter is limited compared to Autodesk products like Maya and 3dsmax.

The new Prefab Variant feature in Unity 2018.3 effectively solves this issue because variants keep the "connection" to the blend/fbx file intact. This works because Unity treats blend/fbx files as prefabs themselves.

[hypertensiongamedev]

Converting my prefabs to take advantage of Unity 2018.3's nested prefab and prefab variants, one-by-one, it's taking time but it's getting there.

Nested prefabs are so useful especially for GUI. Frequently reused widgets like dropdown boxes and checkboxes are much more manageable.

I’m just a little bumbed out that I can’t reorder components around in a prefab variant. And these are components defined in the variant (not the base prefab). There’s probably a technical hurdle behind this decision, but it’s a little annoying cause I like to move up components that I consider to be high-level, and move down components that I consider low-level.

[hypertensiongamedev]

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

[hypertensiongamedev]

Finished texturing the sword.

[hypertensiongamedev]

Working on the textures for the Greatsword.

[hypertensiongamedev]

Going to texture this one next.

Had to convert some quads to triangles to get rid of some ugly shading. Their normals aren’t flipped or anything like that.

Link to full image

I don’t actually know why this happens. All I know is that converting them to triangles help.

EDIT: I just realized, the moment I drop materials/filters/generators onto the model, those parts are gonna be covered anyway so I probably just wasted my time doing this.

Link to full image

[hypertensiongamedev]

theonian said:

That's true, but that has to do with the wrapping of the patterns included in the material, not the initial normals you bake (afaik)

Right, I think I get what you mean now. It was wrong of me to say it was coming from the baked normals. I want to say that it's ultimately coming from bad placement of seams when laying out the UV.

If I try removing all initially baked maps from the model and start with a clean slate, I get this:

But once I start painting on a regular layer (no procedural materials), with a high-roughness brush on the area where the seam is, it shows up:

[hypertensiongamedev]

theonian said:

The seams don't come from the inital bake of the normal map, they come from the materials you apply in SP. One solution is to go through ALL materials and ALL generators and set the texture wrapping to "triplanar". Hiding the seams well is a better solution, though :p

I’m already aware of that. It's not that simple. Even with a single Metal Edge Wear Generator for example, it takes a lot of fiddling to hide seams, even with triplanar turned on, because the underlying issue of poor seam positioning in the UV layout isn’t fixed.

[hypertensiongamedev]

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.