Now that the character rigs were finished, and all the mocap footage was cleaned, I was able to work getting the captures on the character. Although I was pretty experienced in MotionBuilder, I had never edited mocap for a game before, and it is a very different process. Game animations are usually simple, clean and loop perfectly, which is not something that is inherently part of the motion capture process. The most important part is that is loops correctly, and that is what I focused on primarily, I did not modify the poses of the animation for exaggeration yet, and focused on getting as many loops made as possible, so they could be in the game. I made a quick video to demonstrate the entire process, starting on the mocap stage and ending with it in the game:
Also here is the same clip on sketchfab. Although I finished exporting 4 clips, this is the best one to demonstrate, since some of them are split up oddly in order to blend into different clips.
Pros:
Cons:
0 Comments
The past couple of weeks, I had been making different blueprints of buildings made using the modular assets Rob and I created. So far, I have seven different buildings created and plan on making even more once I create more complex modular assets. I did not make as many things over the past couple of weeks due to many things like the holiday break, many different assignments being due for other classes, and other serious issue.
Pros: We have a workable number of buildings in the game currently. Cons: Not nearly as many buildings as I had planned. The past 2 weeks had a good amount of progress on the coding side, although still not as much as we'd like. One big thing we tackled was the discovery of a major game breaking bug in our game, where client side controls were not being replicated over to the server, and the client could not function correctly. This took an entire weekend to solve, but we eventually discovered what the problem was, that basic Unreal Inputs on the client would not be read by the server, and that specific events must be called that would be replicated over to the server must be used. Once this was found, the fix was then applied to all existing dragon and and player functions. On my own programming work, I have gotten some more work done with the AI. While I have not set up AI behavior trees, I have found a work around using Unreal RVO collision avoidance, which after a good amount of time spent experimenting with, I was able to get it so the floating islands AI now see each other, no longer phase through one another, and actually try to move around other islands when they realize their path is blocked Some other minor edits have been done also been done, such as adding a round timer and making it so islands move to the correct position when captured, instead of only partially close to the correct position. I also attempted to implement the Alpha version of our dragon, but was unable to due to my unfamiliarity with Animation retargeting. Sally will try later
Pros: Lots of programming bug fires put out Islands now have smarter AI Can finally move onto more game programming such as Win States, vertical island movement, and Sudden death Cons: Unplanned bug fixing has put us back a few days even more Coding in general is still more behind than I'd like Art is also behind The past couple weeks, I have been working on expanding our list of modular assets to be used for creating the environment for the game. In a recent meeting with Dr. Wagner, it was decided that going forward it will be my sole responsibility to further develop these modular assets and implement them so that Rob can further focus on MoCap.
Pros: We are making steady progress towards having a full environment soon. Cons: I can't show my current progress since my computer with my work is currently imploding. Moving forward towards the Alpha, it was essential to start incorporating the models into the game. I spent these two weeks continuing work on our characters towards their final stage and importing the latest versions into unreal. Ricardo gave me a reference to rig the characters with the male model and I was able to rig the female model for mocap and import both into the game.
Pros The characters are in the game and the base models are finished with a final skeleton. This way I can constantly replace the models without having to re-rig the entire model and only have to worry about weight painting. I also UV-ed both base characters and since they are heavily armor based I can easily add on or replace existing armor to alter design changes. Cons While the female alpha is finished, I need to work on the male character some more to raise it to the same level, but I am sure I can get it finished before the next meeting with our advisor. The weight paintings are slightly rough in some areas and the texturing is still just base colors. Mocap work still isn’t finished yet and I’m anxious to see them in the game. This week was pretty productive for myself personally. Toggl helped increase my time spent on the game, so I can manage between class and work better. I’m looking forward to implementing texture work in the game. The last two weeks were pretty productive when it came to getting hours in on the project. Unfortunately, most of that didn't translate in to new features for the game. Two weeks ago, we discovered a game breaking bug in the networking. Client side players could run around and jump in the server, but anything else they did wouldn't carry over. For example, if the client were to grapple or try to fly, they would experience severe jittering without going anywhere. From the server player's point of view, they wouldn't be doing anything. Ruben, Kevin, and I spent almost all of our hours that week working on it, and finally figured out how to correctly communicate between the client and server in blueprint. Last week was more about actual features. Sally brought the first rider character in to Unreal and retargeted it to the default animations. My first job was reapplying old features to make sure they worked. After that, I got an aim feature working, as a step towards combat. The player can zoom in and look around. This bends the skeleton accordingly, and plays the aiming animation (a placeholder for now). Pros: A lot of work was done on the game Part of the weapon is done Cons: A lot of hours went in to fixing networking Spent a lot of time unsuccessfully learning IK in Unreal
The past two weeks for me has been a little slow. I have been working on environmental assets. I was able to create monoliths for our alpha. In addition to the monoliths, I made a rough terrain. I originally planned to make the terrain mostly rocks, indicating remnants of a castle with the charm of ruins. Unfortunately, as I built the scene, I realized that it looked a little too plain. To counter that, I decided to build ruins instead. I've created one of the several versions I wanted, but I do believe that in my last sprint, I will be able to have what I planned to finish. Rough animation and environmental alphas.
Ricardo almost finished an animatable rig for our game. The model and the rig will be subjected to change, thus the animation will change as well. pros: I can begin to animate. I am getting the ball rolling on my environmental side. After building rocks, I was able to push towards a better aesthetic. cons: I am a little slower than I would like to be. The animations I will make will most likely be scrapped. For this week of the course, I was just keep working on the menu. I wish I got all the menu by this point but I am stuck at some of the settings. Because lack of understanding in Unreal, the menu is taking longer than I expected. As of right now, I am studying about the engine and making blueprint at the same time. The menu is almost ready to go but there are some issue that scale bar is not working. I am heavily focusing on the menu but I have created some sound effects for our game. I have already created few vocal effect for dragon. For next two week should be completing implementing my menu over our game on the perforce and create at least 15 voice over for the dragon and the human characters. Pros:
The big challenge I've been working on for the past two weeks is the custom character controller. So far I've been able to create the simple stuff like walking, running, jumping, etc. However, there are more specialized movement states I'm having trouble with. The main one I've been sinking time in to is the wall grapple. It needs to have a moving towards grapple target state, and a state where it's attached to the wall. Both of these have been giving me trouble. Speaking of the grappling, I've been working with Ruben to figure out how best to implement my work in to the networked game, and discovered that the way I was previously doing grappling wouldn't work. Originally it worked by having a separate object in the world attach to the player, and that would be the grapple. Unfortunately, that won't work when all the players spawn in at once. Because of that, the grapple is defaulting to firing from the center of the character, rather than the wrist, which feels like a step backward. Right now I'm making it so that the grapple is a part of the character blueprint, which should fix the problem.
The biggest thing these past 2 weeks was our Motion Capture session,which gave me plenty to work on afterwards. Rob set up the studio, and I was not there until the second part of the session, so I missed everything Kevin acted for, but was present for the entirety of Aviva’s. We set up a Google Sheets doc, and took down notes for each take, which has been very helpful. Since I was not there for Kevin’s part of the session, I suggested Rob and I split up the work by who was actually in the studio. Kevin’s parts were more complicated, but there were a lot more takes for Aviva’s, so I thought it seemed fair, but Rob has been talking a lot about how what he has to clean up is harder than what I’m working on. I’m not sure if he’s bragging or complaining ¯\_(ツ)_/¯.
So far I have exported 18 shots, and have looked through a bunch more that I determined were not good to use. First I do the Blade post-processing pipeline, and I watch the capture clip several times from different angles. One thing I have found to be helpful is to hide everything except for the solving bone, since it is what gets exported, and it is easier to spot any jerky movements than on the labeling bone. Almost all of the shots I have worked on are fairly simple, and the actor remains upright the entire time. There were some mistakes in the session, the two biggest ones were that a hand marker was on Aviva’s thigh for 17 takes, but it’s not a huge issue since the hands usually don’t give fine data, and have more markers than truly needed. The second is that the boots seemed to be a little loose, and flopped a lot when they hit the floor, and the takes that have running lose the auto label on most steps. That has mostly just created more work for clean up, but may have made the data overly shaky. I am making good use of the spreadsheet though, and taking detailed notes on the specifics of each take. Other than that I modeled a tower, which I was intending to make a lighthouse, but I think I would rather use this design for a simple tower, and save the lighthouse for something more obvious. Tower V1 by ricardotnet on Sketchfab |
Write something about yourself. No need to be fancy, just an overview. Archives
January 2017
Categories
All
|