CINE1102 2017-18 Animation Studio: Research

CINE1102 2017-18 Animation Studio: Research

Introduction:

For this project, I would like to create an interactive animated experience. Instead of simply being an animated video that viewers view from a controlled perspective, viewers have control of how the animation is viewed and could potentially interact with it. There are three fields I have been researching and testing; augmented reality for mobile devices, Virtual reality using devices like the HTC Vive or the Oculus Rift and finally gyroscope technology in mobile devices. The aim of this project is to produce an animated experience that is immersive and provides an experience just watching an animation could not.

Ideas:

What are my interests?

When thinking of ideas I'd like to pursue and develop, I considered what my interests are and how they could translate into this project. My main interests are video games and their development, animation and technology; conceptualising ideas that involve these interests was relatively simple as I have experience with both AR and VR and a project developed for those platforms

Is it interesting?

Secondly, I need to consider whether the ideas are interesting and if it's something I feel would challenge me and develop me skill-set. While I could have decided just to create a 3D animation using Autodesk Maya, I decided to challenge myself and learn by developing for VR or AR.

Is it achievable?

Finally, when pursuing ideas that are outside my area of experience, I must contemplate whether I can realistically and successfully see the idea to completion. If I decide to work in a group, any idea becomes significantly more achievable due to working with people with various skill-sets.

Initial Ideas:

Augmented/Virtual Reality

My first idea was a project that involves augmented reality or virtual reality. For augmented reality a lot of concepts were considered, such as what platform and augmented reality system I would use, and the complications involved with them. As mentioned above, Google's augmented reality platform, ARCore, has not been released for my mobile device, meaning developing for it will not be possible at the time of writing. Developing for Apple's ARKit would be possible if working in a group due to possible members owning an iPhone.

Originally, I sought to use augmented reality to develop a simple application that could be used to view an animated scene from any perspective the user desires. As my only experience with animation was with scenes where I am in control of the camera, I wanted to explore animation ideas that could make immersive use of the user being in control of their perspective, viewing it from any angle, while still involving my focus, animation. This scene could have involved anything, from just a simple fight scene, to anything I'd find interesting.

For virtual reality the concept of the user being in control of their perspective is the same, except the virtual reality user would have a more immersive experience if they were inside the scene, instead of viewing it from the outside. Making use of video game engines, interactive elements could be possible using controllers, conventional console controllers or VR motion controllers like the Oculus Touch or the HTC Vive controllers. Interactive elements could include moving objects or throwing them at characters who would react to them in an immersive way. This would be a challenging concept that tests my animation skillset and as such I would ideally prefer to use virtual reality.


Complex Character modelling, rigging and animation project

As an animator, working with character rigs is an essential part of the animation process. To further develop my skill-set, I considered going through the entire character creation process to challenge myself. While I do have experience modelling characters with a low polygon count and limited texture work, I've never tried to model, rig, and animate a photorealistic character who could be used in a video game. While modelling isn't my focus as an animator, rigging and creating a control rig for the character is the main focus of this project.

Character animation project

Finally, a more conventional animation project that involves animating a voiced scene with characters. Most of my animation experience revolves around animating for video games or animating dialogue of single characters; as such I would use this idea as a change to focus entirely on animating a full scene involving interaction between characters.

Initial background research:

Augmented reality:

- Google hasn't released ARKit for every device yet - end of next year release planned.

- Allows viewer to view from the outside.

Augmented reality is a field that has grown increasingly popular in a short amount of time, seeing use in hugely successful apps like Pokemon GO and Snapchat. These apps use augmented reality to display characters on surfaces that the user can interact with. Pokemon GO, developed by Niantic and released on the 6th of July 2016 smashed expectations by reaching the top of the iOS and Android app stores and earning $1.6 million dollars a day on iTunes within it's first week. Not only did Pokemon GO's success expose the world to augmented reality, it demonstrated how powerful even a basic implementation of augmented reality can be in improving the user's experience and immersion. The app's integration of augmented reality is little more than positioning characters in the real world via the camera, but this paired with the player's position being tracked at all times provided a  experience that had never been seen before.

Google have been publicly interested in augmented reality for many years now with their 2014 augmented reality computing platform, Tango, that saw a small release on select devices for researchers and software developers and have begun focusing on a consumer implementation of the technology in the form of ARCore to complete with Apple's ARKit. Google's ARCore has seen a small scale release on select Android devices, those being the Google Pixel and Samsung Galaxy S8, with expectations that 100 million Android devices will be AR ready by the end of 2017, and hundreds of mllions by the end of 2018.

Virtual reality:

- Allows viewer to watch from within the scene.

- HTC Vive and Oculus Rift are expensive and would be difficult to develop for.

- The most immersive option.

Virtual reality is a concept that has existed for many years in many different forms, with the most recent and most popular being the consumer releases of the Oculus Rift and the HTC Vive, the two biggest kits on the virtual reality market. 2014 was a landmark year for virtual reality and saw the purchase of Oculus VR by Facebook, the announcement of Google Cardboard and even the announcement of Sony's virtual reality project that would eventually become PlayStation VR.

Gyroscope/360-degree video:

360-degree videos have become increasingly popular recently with Facebook and Youtube integration on mobile devices and any hardware that has gyroscope technology. It allows viewer to watch from within the scene with limited immersion but with the same appeal of being able to view a video how you want. 360-degree videos are not just limited to mobile devices but also VR headsets and mobile VR kits, making this option the most available and cheapest option. With the release of Google Cardboard immersion can still be achieved without needing an expensive VR headset, however this option lacks any interactivity, at least if it is just a video and, if Google Cardboard is used, means that interaction will be awkward due to the mobile device always being mounted on the user's face.

- Safest option with least risk, options include simple playing a 360 degree video or setting up an unreal engine animation that allows for gyroscopic camera control

Documentation Research:

In order to efficiently learn how to work on these projects, I will have to rely on documentation on the software I will be using; as such, it is very important that I see how extensive documentation is as this will be a significant influence on what project I pursue. Epic Games have an extensive library of VR documentation available on their site, making pursuing a project in VR far more realistic.

Further consideration:

Can the software run on my device?

As with all experimental technologies, there comes issues of incompatibilities with certain devices. Mentioned earlier, Google's ARCore is at a stage in development where it is only designed to work on the latest Android mobile devices, which excludes my mobile device. Apple's ARKit currently works on a far larger range of Apple devices and would be the preferable option to ARCore at the time of writing.

Virtual reality on PC is usually a very demanding task, as the computer will need to render two screens in the headset, and the computer's monitor, at a frame rate of at least 90 consistently. This means less powerful computers will have an even harder time of providing an immersive VR experience than if they were just used for conventional games on a single screen at 60 frames per second. This means that if I pursue the VR game project I will need to use a powerful PC for development and be mindful of the performance of the game if I want it to work on less powerful PCs.

Do I have alternatives?

Apple's ARKit currently works on a far larger range of Apple devices and would be the preferable option to ARCore at the time of writing, however, as mentioned before I do not own any Apple devices that run ARKit. After forming a group with multiple other students we now have an iPhone we can develop an AR app for using ARKit.

Currently, I do not own my own HTC Vive anymore and as such I will have to rely on the Oculus Rift at the University for developing the VR game project, however there are no motion controllers, limiting our interactivity to the keyboard and mouse or controllers. Unfortunately this means that the room-scale VR I was hoping to develop for on the HTC Vive will not be used, and the player's immersion in the VR game will be limited to looking around and moving with their control scheme.

Is it realistic?

With no experience developing for augmented reality, and relatively little for developing a virtual reality game, achieving my AR/VR idea seemed very unrealistic; However, I have now joined a group with several other classmates of various skills whose strengths will be an immense help in seeing the idea of a augmented reality or virtual reality project come to fruition. As others can focus on their respective fields, I will have more time to focus on developing using Unreal Engine 4 and animating, while improving my ability to work with a team.

Conclusion:

At the time of writing, I have decided to pursue a project relating to virtual reality, with augmented reality being an alternative if virtual reality does not seem realistic. While my concepts for the projects were relatively simple, due to my limited experience with augmented reality and virtual reality, our team can concentrate on developing more interesting ideas that hopefully challenge all of us equally and develop out skill-sets.

References:

Kharpal, A. (2017). Google says augmented reality will be on 'hundreds of millions' of Android devices next year. [online] CNBC. Available at: https://www.cnbc.com/2017/11/07/google-augmented-reality-will-be-on-hundreds-of-millions-of-android-devices.html [Accessed 6 Nov. 2017].

Robertson, A. (2017). Google ARCore gives Android users augmented reality without Tango. [online] The Verge. Available at: https://www.theverge.com/2017/8/29/16219696/google-arcore-augmented-reality-platform-announce-release-pixel-samsung [Accessed 7 Nov. 2017].

Szymczyk, M. (2017). Pokemon Go Is Driving Augmented Reality And Geolocation Adoption. [online] Zugara. Available at: http://zugara.com/pokemon-go-is-driving-augmented-reality-and-geolocation-adoption [Accessed 7 Nov. 2017].

Docs.unrealengine.com. (2017). Virtual Reality Development. [online] Available at: https://docs.unrealengine.com/latest/INT/Platforms/VR/ [Accessed 18 Nov. 2017].

Design Research Project: Sketchbook

Game Design Documentation

Early Development

This coursework tasked us with choosing a game genre or type and designing and developing a video game prototype. While my game was originally based off the traditional multiplayer shooter genre, it eventually evolved into a game that mixes the timed goals of racing with elements from shooting games, such as a third/first-person perspective and a weapon that can be used to attack other players.

The original concept for my game prototype was a multiplayer 1 vs 1 first person shooter that took heavy inspiration from arena shooters like Unreal Tournament and Quake. After a few concepts around this idea, I decided to try something that isn’t just a shooting game, something I thought would be fun. Taking from my time playing Team Fortress 2, a game notorious for the player’s ability to launch themselves high into the air using the game’s rocket launcher being fired at their feet, I decided to explore ideas of a game prototype based around that gameplay.

For a while in development, this game was about reaching the top of the level, with falling platforms too, hence the height counter on the FPS UI, eventually this idea was dropped and I opted to go for a more traditional approach to rocket-jumping level design.

Taking from its inspirations, my project, simply titled ‘Missile Arena’ was played from a First-Person perspective for quite some time during its initial development. Once I began work on the third person animations I make the default perspective third person for testing, with the intention of letting the player swap between the two perspectives via a key press. This was never fully implemented and the first person and third person methods of playing the game exist in the game as two separate character blueprints, with only the third person player character being accessible normally.

Online networking was always planned since the first concepts of the game, and a large amount of coding was required to get it working. Online services for the game are provided by the Steamworks SDK Unreal Engine 4 plugin, and work flawlessly in the game provided you have a Steam account logged in on the computer you are using. Another stipulation with this being an unpublished Steam game is that only people in the same continent as you can play with you, meaning I was unable to test the connection with players from other continents.

Initial Concepts

Originally, I wanted to put a lot more emphasis on player movement with air-dashing, wall jump and ledge climbing mechanics. When I implemented the first version of air-dashing I had not learned how to properly code for multiplayer, as such the way I coded the mechanic wasn’t functional in a multiplayer environment. I decided to cut this mechanic and to fully focus on ensuring multiplayer was coded properly. With the shift from a simple 1 vs 1 arena game to a rocket-jumping multiplayer game, I decided not to use development time on implementing wall-jumping and ledge climbing as the player’s missiles can be used for the exact same purpose.

The page also features the only concept art of a character model that didn’t make it into the prototype as I decided to focus on gameplay and networking systems instead of visual assets. The UI on the launcher was implemented before the game switched to a third person perspective. Also visible are two ideas for power ups which, again, are remnants of the original concept of the game.

Concept art for a test map when the focus of the game was still a 1 on 1 arena FPS.

Blueprints

This prototype is the product of hundreds of nodes of coding, as such I will show the most important blueprints.

GameInfoInstance – Contains the logic behind managing the multiple menus of the game, checking for save data and starting servers and joining them.

PlayerInfo – Contains all the variables for the player which is used for various parts of the game.

GameplayGM – Handles respawning and connecting and disconnecting players.

GameplayPC – Handles the players lap and time data and also loads player info to Serverside Player Controller.

Animation

Despite the game originally starting off as a first-person game, it was always intended to be a multiplayer game, so representing players over a network correctly was important. My initial work on animation started with the basic player movement animations such as the idle, running and jumping animations. Animated .gifs of most of these animations can be found in the Animation folder.

As you can see in videos at the bottom of this page, this process took quite some time as I tried multiple methods of simulating and replicating each player’s aim across a network. Originally the aim offset was handled in the character blueprint, but this didn’t replicate to other clients properly. After countless google searches I managed to find the solution I needed and instead handled aim offsets via the animation blueprint, an aimoffset asset and aimoffset poses.

In total 15 aim offset poses were created, making sure to closely match them to where the player’s missile should be shooting towards at that angle

The animations used by the player character and the character blueprint

The animation blueprint Event Graph, with nodes that are used to get the player’s aim direction and use it in the animation blueprint to apply an aimoffset to the animation. You can see unused nodes commented with ‘AimOffset180’, nodes which were used when I only had the first set aim offset poses finished that provided a total of 180 degrees of aim offset. Now there are poses for looking back, the player’s aim is represented at all angles.

The third person character’s animation blueprint, with aimoffset blending added to the basic movement to produce the end result.

Research

A lot of research was done during the course of this project, from countless Youtube videos, to Epic’s multi-hour video tutorials and crash courses on networking and animation systems. Many times, I would have to visit the Unreal forums, Unreal Documentation or Unreal Answers for small things such as properly implementing aimoffsets, and especially for high-importance problems like networking the various elements of the game. A lot of the things present in this game prototype are thanks to countless hours in total spent studying different ways people implement similar mechanics, and following Epic’s comprehensive documentation.

I spent a lot of time studying what made arena shooter games fun, from their movement mechanics to how weapons handled. While this comes mostly from the initial ideas of this project when it was a competitive shooter, things like enjoyable movement mechanics still apply. Numerous tweaks were made to things like the player character's max speed, acceleration and jump height to test out different ideas and see what felt good to play with. In the prototype the player moves a lot faster than they did at first, this is to make up for the removal of the dash mechanic and allow the player to traverse further horizontal distances.

As mentioned earlier, the biggest influences for these tweaks were Team Fortress 2, Unreal Tournament and Quake, games notorious for their use of rocket jumping. Rocket jumping is a great example of emergent gameplay, being that it was never an intentional aspect of Quake and Unreal Tournament, but it became so popular and useful that it changed the way Quake was played forever. Team Fortress originated as a Quake mod and rocket jumping was just as prevalent there as it is now. It's hard to recreate something like this for a prototype so the my implementation of rocket jumping is comparatively simple and streamlined, but it still allows for the vast range of movement it gives in the games that inspire it, such as launching yourself from wall to wall and climbing walls with explosions.

For this project I spent a lot of time playing ‘jump maps’ in Team Fortress 2 to see how level designers handled these mechanics, and common level design elements used in those maps. The maps varied greatly in difficulty, complexity and size, and showed how something as simple as firing an explosive at your feet to propel you can open up thousands of different challenges to overcome. While rocket jumping has always been a large part of games like Quake and Unreal Tournament, the sheer quantity of maps creating for such a simple yet fun mechanic shows that there is enjoyment to be had in the mechanical challenge maps such as these present. Numerous parts of the prototype map are based off various elements of these maps. An example of this is this area:

The 2nd wall requires multiple chained rocket jumps up the wall to advance. These are very common in Team Fortress 2 jump maps and test the player's timing and knowledge of where to aim to launch themselves up effectively. It's far more lenient in this game due to no ammunition restrictions and the wall being rather small, just serving as a tutorial to the concept of chaining jumps.

This tight-rope area is based off of 'obstacle course' maps that were very common in older games with publicly available level editors. Obstacle course maps were very common in the original Red Faction video game on PC, and I used my knowledge from spending a lot of time on them when I played it to bring elements from them into this map.

Media

Videos of the project at various stages of development.

Evaluation

This project had a focus on networking, gameplay systems and animation. Networking each players character properly and bringing their save data into matches was a very important and a lot of time was spent working on these networking features. Thankfully after a lot of time studying tutorials and Unreal Engine 4 Wiki pages, the networking features work without a problem as far as I know, and all the systems relating to networking and gameplay function and have room for expansion if I wanted to continue working on this prototype. An example of this are the player customisation options, which was created in a way that means I can easily flesh out the feature after this prototype.

As this project was about creating a prototype, I made sure to implement everything that is crucial to the game, with most non-essential assets taking less priority. An example of this is how in the final prototype the level lacks polish and unique assets as these are less of a priority for my focus than ensuring the networking works flawlessly and the objective of the game functions. Despite this, some mechanics are implemented rather poorly to get them in the final prototype in time. An example of this is the timer and respawn systems. Instead of respawning being handled automatically, it is only done once the player is dead and they press the R key, and restarting the level/time can only be done once the final checkpoint is reached and the player kills their character. Situations like this are because of my poor time management and are featured in the prototype in the bare minimum way they needed to work. Had I more time I would have properly integrated these mechanics in a way that is a lot more user-friendly and makes sense.

Animation was the strongest focus of this project, I learned a lot about animating for Unreal Engine 4 and aim-offsets, and after becoming familiar with the workflow, creating animations for the game became immensely simple, effective and quick, especially when compared to older game engines like the Source Engine. The animations for both the first person and third person characters turned out how I hoped, with the exception of the new jump animation which, while more dynamic than the original, looks very awkward. I would like to come back to these animations and further improve them and ensure they show a consistent quality.

Had I more time or a second chance, I would have managed my time properly and ensured I met my original goals for the game, such as the use of more refined assets for the levels and an original character model. I would have also had more time to try and fix the bug that caused an issue with mouse problems when using the menus and starting the game. This problem came about too late into development and with little time left I was forced to package two executables of the game, one that starts the game from the main menu, and one that starts the game from the main level. With more time, I could create more levels with more interesting challenges of various difficulties instead of the one short level currently in the prototype.

Ultimately, I stand by my decision to fundamentally change the objective of the game and I feel that it was a good decision for making a more unique and interesting experience, instead of just another first-person arena shooter. I also feel like this really challenged me to think of how to design levels for such a different kind of gameplay style, and I learned a lot while trying to implement the many things that comprise this prototype, from networking, UI design, save data and player character mechanics, and using all these to communicate data that will be shared across them. I developed invaluable knowledge of Unreal Engine 4, and the methods of creating systems, networking and integrating animation from the various methods of research I conducted over the course of this project and I feel as though that despite the problems that appeared in the final moments of development, I produced a solid, but definitely open to improvement, prototype.

Animation Practice: Evaluation

For this project we were tasked with sculpting a character of our own design in ZBrush, from the concept stages up till rendering, documenting each step. The character we design should have a story and design that suggest they’re an anti-hero, a character who, while not a villain, exhibits negative or immoral traits or actions that makes them less heroic than a standard hero. We were also tasked for creating a prop for our characters that is relevant to their story or character.

I began by researching what an anti-hero is and using what I learned to factor into my designs for the character designs I created. Taking inspiration from numerous notable anti-hero characters in film and video games, I came up with a number of official concepts. Initially I spent more time than I would have liked trying to design a character that actually embodies the qualities of an anti-hero, so a lot of time was spent thinking of concepts that eventually would go unused.

 After designing a futuristic Sci-Fi smuggler, I decided to try other designs and eventually ended up with a character I believe to be far more interesting, a post-apocalyptic survivor. While I did like the concept of my original character, he was an anti-hero in his job only and in no other aspects, so I thought I should focus on creating a character who more closely exhibits those traits.

I made the choice to involve Autodesk Maya in the workflow, using it to create the base meshes for several parts of the sculpt. Using Maya for this purpose is considered industry-standard for hard surface modelling and game character creation and as such I saw this project as a chance to experiment and learn how to use both programs in the character sculpting workflow to increase efficiency and allow for the easier creation of hard-surface geometry.

This method would prove invaluable for modelling the character’s prop, a shotgun, and her numerous accessories such as belt buckle, boots, gloves and other items of clothing. Using this method was a learning experience and being able to use it and traditional ZBrush sculpting methods not only taught me how to use the program itself, but also gave me more experience modelling organic and hard-surface geometry and taught how the pipeline between Maya and ZBrush worked. I believe that ultimately this was a good decision as I learned a lot more through this process and learned how to overcome challenges that came about.

In conclusion, I am mostly happy with how this coursework turned out. I believe I managed to create a model of high quality and learned an immense amount about ZBrush and sculpting in the process while also practicing Maya modelling techniques. Had I managed my time more effectively I believe I could have made a more impressive model and character that further embodies the qualities of an anti-hero, as I feel like my final model doesn’t represent the concept of an anti-hero as much as I had wished it would. I would have also spent more time learning some of the many useful features of ZBrush, such as polygroups, that ultimately made the process so much easier, but could have saved a significantly saved time if I was aware of them when I was initially modelling the character. I believe the model itself could still be improved significantly and I made numerous mistakes, such as modelling the character with arms at the side and legs straight down, instead of in an A-Pose or a T-Pose, that ultimately made the process harder and more time consuming than it needed to be.

If I could try this project again I would use my time more efficiently, document my work more often, and ensure I don’t make the same mistakes I made this time that hindered me. I would have also made sure to spend more time in ZBrush and experimenting with the many tools available, as I often relied on Maya for creating geometry I couldn’t create as effectively in ZBrush at my current level of knowledge of the software. I would ensure I spend as much time as suitable to learn the program and it’s many systems to ensure I don’t need to rely on Maya as much and consequently allow me to spend as much time as possible in ZBrush, sculpting, learning and gaining more experience with the software.

Animation Practice: Final Character Renders and Turntable

1. General Renders

2. A3 Renders

3. Turntable Animation

1. General Renders

2. A3 Renders - Featuring both the character and the prop

A3 - 300 DPI

A3 - 300 DPI

A3 - 72 DPI

A3 - 72 DPI

Prop - A3 - 300 DPI

Prop - A3 - 72 DPI

3. Turntable Animation

Animation Practice: Character Background

Character name: Red (Real name: Erica)
Age: 26
Birthplace: England

A wandering, silent and vengeful killer that roams the lands of post-apocalyptic England. Known only by the name 'Red' given to her for her iconic red scarf that she is never seen without. In a post-apocalyptic world where civilisation is only barely forming, the only people who knew her real name were her friends and family who were killed or tortured when raiders attacked her village. During the attack she and other were taken hostage and tortured at the raiders camp. The last 2 people to be tortured, she managed to attack her torturer and escape with her sister, taking his gun and any ammunition she could find. Before she could get away, the raiders caught up with her, attacked her, left her for dead, captured her sister and drove away. While she survived, her tongue was cut out and her lower-face scarred, as such she refuses to ever take off the scarf that conceals her face.

Scarred by the events that took place, she aimlessly wanders across the country, killing any bandit she comes across without hesitation, even willing to shoot through a hostage if it means killing the person on the other side. The experience has left her cold-hearted and almost emotionless as she moves place-to-place, searching for any information as to where her sister could be, or if she's even still alive.

Animation Practice: Character Concept Art

When designing the character I had various wildly different ideas originally but eventually narrowed down a character I thought would be interesting. Ultimately I took elements from each design and integrated them into the final character design.

Space Smuggler concept:

Originally I played around with the concept of a sci-fi smuggler character wearing a futuristic hard-surface outfit. I tried different ideas for his head after as I was happy with his outfit but ultimately I felt like I could do something a little more interesting.

After deciding to try other concepts, I sketched some various, wildly different ideas for a character to see if anything seemed interesting. With another sci-fi character at the top right, I decided to go in the opposite direction and try a film noir approach with a detective character. While I was considering going with this idea and putting an interesting spin on the design, such as a film noir cop in the future, I decided to keep trying other ideas. This eventually left to the bottom left concept which I didn't fully flesh out, but later served as the basis for the design of my final character.

Continuing from the design previous, I tried drawing what I thought an interesting post apocalyptic protagonist would look like, in the same vein as Mad Max and other silent protagonists. This quickly led to the initial concept of a leather jacket-clad, red scarf-wearing female post-apocalyptic character. While I eventually decided to not give the character a jacket or coat, I went through different ideas for the clothing. 

As mentioned previously multiple elements from experimenting with the previous character designs made their way into this character's design. The overall lower body appearance of combat boots and trousers from the last page's last design served as the inspiration for her current design, albeit with vintage motorcycle boots replacing them. The two belts in the sci-fi concept also made their way into this design, with the 2nd belt becoming a shotgun shell belt and the scarf from the original sci-fi smuggler being used and made more important to the overall design.

With the character's design almost finalised, I began thinking of the prop and pose for the character. I quickly decided on her having a Ithica 37 shotgun. The weapon is commonly used in post apocalyptic video games and movies and has essentially become what we think of when we hear 'shotgun'. For the pose I drew two ideas, one a confident yet cold firing stance, as if about to execute someone, and the other a more relaxed pose of her smoking while sitting. I eventually decided to use the first pose as I felt like it would show more of the character, without boxes obscuring her, and also because it shows more of the character's anti-hero personality.

The final pose

Animation Practice: Development and Experimentation

For this project I decided to model parts in Maya and then flesh them out in ZBrush to ensure everything would be proportional and, considering the amount of hard-surface elements, would look how they should. A majority of the project was done in ZBrush still, but Maya was invaluable for quickly and efficiently creating the low-poly, detail-lacking base meshes for various parts, especially the more complicated parts like the belt buckle.

I first began with the base mesh. This would be the underlying body mesh of the character that I would use to rough out the proportions, shapes and topology. While I originally planned on using ZSpheres, I decided to go with this approach as it would be more useful further on when I needed to make clothing and accessories.

Thanks to the GoZ tools included in ZBrush, moving the models between Maya and ZBrush is fast and efficient.

The first iteration of the mesh, while the image planes aren't visible, I made sure to follow reference images to ensure realistic proportions were achieved.

A majority of the time spent modeling was done with smooth mode on, to make sure the mesh would look fine in ZBrush and be an appropriate base for the rest of the clothing.

Once the base mesh was finished I began using it to create the mesh for clothing by duplicating the polygons from the base mesh. This ensures the topology is inherited from the base mesh and makes create of clothing far easier.

Basic mesh for the trousers, belt and top.

A screenshot of the first model sculpted in ZBrush, the top.

Initial model of the boot and it's various parts.

Thanks to using Maya in the pipeline, creating multiple elements suchs as the belts and zips on the boots was quick and easy and allowed ideas and concepts to be tested quickly with a rough representation of what it may look like in the final sculpt.

Boots and trousers imported into ZBrush.

The boots after having details sculpted on.

Folds sculpted onto trousers with leg bandage and belts added

For this project I decided to include a shotgun as the prop of the character, I chose to model the Ithica 37 and tried two different versions, one with a longer barrel and one with a shortened one. I eventually ended up using the shorter barrel one.

After modelling the head mesh and importing it, I used ZBrush to sculpt a thick scarf and Maya to model the goggles

For the hair, I hadn't made a final decision on whether to have her hair tied back like in the original concept or to have it down to her shoulders as seen in one of the concept drawings I did. To experiment I tried creating the long hair and seeing how it would look.

While I think the result was good, I also made another version of the hair but tied back, and compared.

I prefer the tied-back look and decided to use that in the final sculpt instead, but the original hair was helpful for experimenting with the tools I'd use for the final hair.

The final model, featuring the finished scarf and the additions of gloves and shotgun shells to the 2nd belt.

POSING

With the model finished, it was time to pose the model. Using the ZBrush Transpose Master plugin included with the software, I was able to pose the model without merging everything into one model.

The plug in temporarily merges the subtools to their lowest divisions and merges them, from there I seperated the different parts of the model I'd pose into their own polygroups and from there rotated them into position.

Once done with posing I had let the plug in automatically reflect the pose onto the original tool, all that was left was to clean up the stretched geometry and pose the fingers and the prop.

Before adjustments - Low Divisions

After adjustments - High Divisions

With the character posed and a few adjustments made, all that was left to do was render.

RENDERING

ZBrush features a robust renderer that gives the user an incredible amount of control over various rendering elements such as ambient occlusion, ZDepth and many more variables.

From the Render Properties menu elements can be turned on and off, allowing for more or less detailed and calculated renders.

The BPR RenderPass menu lists the various maps generated when the model is rendered. These maps are incredibly powerful for fine tuning things such as depth of field and shadow strength to the user's preference later on.

These maps can then be individually exported from this menu and used in programs such as Photoshop.

Importing these channels into Photoshop allows the user to alter elements such as Shadow strength and Depth of Field in real time, without having to re-render after every change, like if they were to make these changes in ZBrush itself. This workflow is an invaluable way to fine-tune renders and achieve the results with real-time feedback and not down-time between changes.