Sunday, 4 December 2016

Animation Production 009

Ludum Dare 37 Preparation

Myself and Bradley Sandford have been doing games design and development together since 2011. Bradley deals with the programming while I cover the artistic aspects. Last year we created Vi. This year, now that I know much more about Maya, we'll be giving it a shot with a 3D game using Unity. We'll have to do a little preparation and testing before the event. for me, this mainly involves experimenting with how I can create a character model, rig & textures in a limited amount of time. as the event will be over a 72 hour period.

When creating the mesh I tried not to get caught up in tweaking each aspect too much as I wanted to get it done to start testing in Unity. I created the mesh in roughly an hour before I started rigging. This seems like a really good exercise to quickly establish problems and solutions to further improve my modelling ability.

Rigging the character did not take as long. however, I did not give him enough bones through his upper body. This was noticeable when I started trying to animate. As for the animation process, I believe I knew that the mesh wouldn't have the best deformation as I hadn't done any weight painting. He works sufficiently for this test though.

I started with a walk animation because that would be the nicest aspect to start with regarding the unity testing. Gives my programmer a basis to start making the character walk using the animations. The method used to import into Unity also gives me the freedom to easily update the animations without requiring any adjustments from the programmer.

After this I animated a simple idle pose. nothing too complicated and something that adds a little more life to the character when he's not moving.

Building and animating the character is the longest and most important part to creating a simple, satisfying game. Environment does not require rigs or animation and texturing can be fairly minimal. Working with such a short time frame I'll need to make sure I can pre-vis the game before worrying about refining any individual assets.

Next I had to look into how to get the assets from Maya to Unity. This was significantly less complicated than I had imaged. Maya does have a "Send to Unity" option, but that goes directly to the Unity file project. which I do not have. Instead I manually exported the animation, there's 2 main methods of doing this. The first method would be to export the mesh and textures with each animation file. This is not the best method as any updates to the mesh would need to be done to all files individually. Instead, we can make use of Unity's referencing system and use a method that I really like because its modular. To do this, I export the character, rig and texture as a base .fbx file. I then create the animations in a separate Maya scene, bake the animations and export just the baked rig itself as a .fbx file.

Baking was a term I previously didn't fully understand and had only seen tied to lighting when looking at job openings for various companies. After doing this process I fully understand the concepts of baking, although different for the various aspects of 3D. Baking the animation converts tangent interpolation into keys on the Maya timeline. This then becomes very difficult to work with so its best to save a separate file for baking so that you can still adjust the original animation. I've been further looking into baking of other aspects of Maya such as lighting and lighting maps.Though that is not currently necessary I will likely look into it further at a later date when I start doing environments for game.

Unity uses a naming convention to reference the files, this is done by "<reference>@<animation>". As shown here with the files for Broseph.

Here's a screenshot of the initial process of getting the model into Unity. Using Skype to easily see each others progress. Seeing something I've created, standing inside of a scene ready to be programmed to move get me excited.

Now that I've got a rig and some animations for my programmer, I went back to the base file, Broseph and started the UV unwrapping process. I initially found this difficult and wasn't sure how to approach it but once I started getting into it I found things fairly simple. I use a lot of cylindrical mapping for the legs, head, body. Capping off the top and bottom with a planar map. Before doing this, however, I was using just planar maps for the arms.
Something to keep in mind is having a centre slice through my mesh to serve as a place to cut the mesh. currently the mesh is sliced unevenly. I will likely attempt using mirror for the character next time. This is also nice as the mirror tool mirrors UV's. good for arms and legs, not so much for the head and body. there will still need to be some minor tweaks after mirroring.


Well, it seems I had made a mistake. I started moving the mesh and the UV's moved too. Hmm, that doesn't seem right. It clicked, I hadn't deleted the history. I deleted all non-deformer history. I had a lot still in the history as I didn't delete after the modelling process. Definitely something I'll have to remember. I also somehow accidentally pinned my UV's, took some unnecessary time to google and find out what I had done.

I then started experimenting with texturing. Though it seems easy in theory, it becomes really difficult to decide what kind of texture an object may have or deciding where creases are. Texturing is fun, but difficult and time consuming. Perhaps an easier process if I had created some sketches of the character first. Which I will be doing next week during the LudumDare 37.

I decided to smooth the mesh. What I forgot is that 3 is only a smooth mesh preview and doesn't actually smooth the mesh. So this didn't carry through to the export and into the game. But I know I can easily update the Broseph.fbx and everything else will pull from that and still be fine.

Finally, here's a clip of the character walking around inside the game.

No comments:

Post a Comment