Week 9: Skeletal Meshes, Bug Fixes, and Polish

GitHub

Last week I talked about how I was basically content complete and won’t be adding any new features. So, this week, I worked on polish and bug fixing. There were a number of things that I wanted to accomplish this week including:

• Anchoring UI

• Implementing Wind’s UI Y Axis

• Having a debug arrow point in the direction that the wind is facing

• Fixing the Traffic; Traffic not disappearing from the panel

• Switching out the Static jet Mesh for the Skeletal one

• General Code Cleanup

The first four were pretty easy to implement, here are some short clips/images displaying each.

Anchoring the UI was done really just to make sure that it looked consistent no matter what size the screen was.

Implementing the Wind’s UI Y Axis was done to give it more of a 3D type look when displaying the wind direction

Having the Debug arrows for the wind was more a quality of life thing, to make it easier for me to tell which direction the wind would be facing at any given moment, and to be able to see changes made to it at runtime.

The Traffic; Traffic warning would display even after you were clear of conflict, but that was a super easy fix.

What took up the longest amount of time would have to be the implementation of the Skeletal Mesh. I took a good amount of time doing some research to try and find the best way to implement this, but didn’t get many good results. So, I decided to convert my Static Mesh using FlightPawn class into one that used a Skeletal Mesh instead. After converting all the code and having it all compile, I started to face the first of my many issues with this endeavor.

When the code was trying to load in the Skeletal Mesh, it would fail, and then crash the entire editor. After troubleshooting this for a while, I decided to revert my code and try to find another way to get the Skeletal Mesh working. But my editor was still crashing even though my plane was now a Static Mesh. After troubleshooting this issue for a while, I finally found what was causing the issue. Apparently, there is a bug that will result in the function CreateSubObject returning a nullptr after you change its template type from one to another and then back to the original, if you don’t change the name of the variable that the pointer will be sitting in.

After solving that error, I decided to write a Skeletal Mesh implementation in its own file. Thankfully I didn’t get any crashes due to the previous bug, but I ran into a whole other set of issues. Because of the way a Skeletal Mesh works in Unreal you can’t simulate physics on the whole object.

So, I thought, “Why don’t I just make a simple cube the root of the object and apply the physics to that, while having the Skeletal Mesh be a child and just handle all of the animations?” Here’s an example of how that object layout would look like:

But doing so caused a lot of issues with the physics system, which I think is due to the size of the cube. I tried changing the scale of the cube, but doing this causes the scale to change for all of the child objects as well:

Here are some video(s) showing off the physics issues:

After looking at the UnrealC++ API I realized that I could change the visibly of a parent object, but have that visibly change not affect the children of that object. So, I decided to go back to my original Static Mesh object, and add a Skeletal Mesh to it. This is what the object hierarchy looks like now:

After a bit of work, I was able to get the Skeletal Mesh animations working as shown below:

And then I just hid the Static Mesh and now everything works as intended!!

That’s all for this week’s update!! I know it was a lot of just troubleshooting, but I think the result was well worth it. Since I have access to a model with a Skeletal Mesh, I might as well try to take advantage of it. Next week, I’ll continue with the polish and bug fixing, as I have a few more things I could do/fix to really improve this.