
Problem Solving
Problem 1: Figuring Out How To Format A "Problem Solving" Section. When It Arose: 21/2/22. When I Solved It: 1/3/22.
To be honest, at first I didn't really know about how I would even format this section because a lot of problem solving usually happens throughout the project instead of being contained into one solitary section, but I think I've figured out a way that may actually work.
​
Basically, the gist here is that I'm going to be taking whatever problems that crop up during the production of this project and using this selection as a big compilation of them all (think of it as an easy access point for my problems, the text here will be all new reflection about each problem with a link to the section said problem occurred in embedded into it, with dates that correspond with when the problem arose and when I solve them (be it by myself or with a little bit of help from others), that way I can simply continue doing what I usually do while also technically working on the problem solving section at the same time.

​
​
Well then, today was rather eventful indeed, as I ended up running into a problem I haven't had to deal with since trying to make that defunct Super Sheep game back in 2020 (the one with all the crossover elements), as when I tried to make the animation for Super Sheep choppy by putting more frames in that are so close together there'd be no room for any tweening between frames and even then, keyframe tweening is something you have to turn on in the first place, so I also just left it off. Despite this however, there still seemed to be a bit of smoothing going on anyway (which isn't really what you want when replicating the movements of anime as authentically as you can)
​
With that being said, during the first experiment I couldn't quite suss out what was causing this, and the one potential solution I did decide to try (that being turning off all the dynamic physics) ended up breaking Super Sheep's model, so I decided to nix it and just finish the experiment there, much to my own disappointment. Not helping things was the fact there was also a football match going on at 12:15PM, so I had to get off the TV by then so that my dad could watch the match.
​
With that being said, what I didn't expect was that after the match was over, I would be allowed back on the TV again, so after a few rounds of Smash Bros I decided to try again but this time with a fresh blank puppet so that I'd have an easier time disabling the physics without breaking the model in the process, but when I did that, nothing seemed to change, as there was still that slight bit of smoothing going on.
​
With this in mind, I decided to fiddle around with the settings of the puppet itself to see if there was anything that would fix this. I tried disabling collisions, making all the body parts weigh 0 killograms and even deleting much of the rig via a section of the menu I didn't know the purpose of until recently, but the one solution that ended up fixing everything actually had something to do with the puppet's "Springiness" slider, which as it turns out is also the reason my characters suddenly gained a spring in their step whenever I'd start the flow of time (thus completely invalidating a lot of my work in the process)
I know this particular problem seems kind of moot considering that conventional wisdom would lead to college being the place to do practical experiments, what with all their camera equipment and their studio spaces where I could theoretically go do a few experiments and call it a day. However, as those of you that have followed me before will know, I've been doing 3D animation in a video game called Dreams (which I've been calling Dreams PS4/5 in order to further denote that I'm referring to the game and not the general concept of dreaming as a whole), so a lot of that live action stuff is more or less out of the question for me, and because the college still don't have any PlayStation 4s or PlayStation 5s after all this time, whenever I'm actually in college I can't actually do any animated experimentation until I get home, and because I'm in college 3 days a week, I'm going to have to solve this problem thrice in ways that don't involve disappearing from college for the week to go do some animating because then I may end up running out of things to experiment with, and then I'll really be in the gutter, so I'll just have to wing it and come up with solutions on the fly.
​
The solution I ended up coming to on Monday was to go ahead and see whether or not people would even want to see a colourized version of my character from last year's final major project, Ruff Bup. The reason for this is because I'm thinking about colourizing Ruff Bup for this project and I wanted to get feedback as to whether or not it would even be worth doing, and given the fact that half of the people I asked seem to like the idea, I decided to just do both since then I can establish a bit of world building visually rather than with pointless exposition that brings the story to a screeching halt, which considering how I want this story to be around five to seven minutes, I can't really afford to let that happen. (especially since I think the setting I've chosen has a lot of potential)
​
UPDATE: after asking my tutor about what I could do for further experimentation, he ended up saying that I'd already done enough in the research department to move onto the pre-production phase, so I'll be doing that instead. To be honest, I wasn't expecting this to be the outcome I would get but hey, any excuse to start working on the project itself is a plus in my book. (plus it gives me chance to actually design the main character beforehand)
​
​
Hopefully I can figure out a good solution as I continue writing the script, so I'll be sure to keep you posted on that particular matter.
​
Update: I solved the problem by deciding to have Ruff Bup come in, throw Kyoto a mirror which she then uses to deflect Super Sheep's laser back at him, thus knocking him out and allowing her to take the final blow when she breaks Super Sheep's back
​
Luckily I actually have two perfectly good solutions I could use here, one involves me pulling the camera far enough away from the characters to allow all their faces to appear in the shot which I'll try not to do too often since distance can make objects and faces more difficult to discern, while the other, and quite frankly much better solution would involve me simply having Kyoto lower her body so that here head is more level with both Super Sheep and Ruff Bup (the reverse would apply to Ruff Bup and Super Sheep since they'd need to raise themselves up slightly)
​
As such, I think a good solution to this problem might be to have Kyoto running towards the camera rather than away from it, which does mean that Super Sheep may end up being the one to chase her down rather than the other way around if I want the audience to be able to see both characters.
​
Due to the very nature of this problem involving me animating the characters, I'll have to solve this one over the course of the animation phase and update this section as and when I come up with the solutions.
​
18/4/22 Update: I think I may have finally solved the problem of having a choppy character and a smooth character interact with each other, as when I animated Ruff Bup shaking hands with Kyoto Kasuma, I decided to have Ruff Bup's arm briefly take on Kyoto's animation style while things like his tail would still wag as normal. Of course, other interactions such as Super Sheep and Kyoto punching and kicking each other are probably going to be easier to figure out so I'll work on that as I go, but for now I can consider this problem solved.
Ok, did not think I would end up needing to think about this so soon into the animation phase but here we go. When I was animating today, I ended up finding that so far the animation takes up about thirty percent of the "wires and animation" part of the gameplay thermometer (and that's after I did all the optimisation where I took out features of certain models because they won't be needed in this scene), and I know two areas where most of this percentage is actually spent. One of them is on Kyoto herself, as her choppier movements are naturally going to require that I give her more keyframes than everyone else, and the other area is more than likely going to be doing the lip syncing for both Super Sheep and Ruff Bup. (and come to think of it, the mouths in general), since that also requires a metric truckload of keyframes in order to change their mouth poses (not to mention the imperial truckload of keyframes that'll also be needed for their expressions too) Luckily, I've managed to catch this all now while the animation is still incomplete, so I can think about how I'll optimise the other sequences more carefully once I get there.
​
Another thing that's particularly lucky, I actually managed to come up with a way to optimise the lip syncing which I'll get to put in place tomorrow. (hence the two dates for the "When I Solved It" part this time around) This'll involve me effectively reducing the quality of the lip syncing down to mere lip flaps, that way I can simply create an animation cycle in order to save myself from using nine million key frames whenever the characters need to talk. Another plus side to this is that by doing this, I'm technically being more authentic to the medium of anime, as a lot of characters there tend to just flap their lips most of the time when they're talking anyway.
​
The only thing I will say is that I may need to be a little bit clever about it since I never actually designed the models for these characters with this kind of thing in mind due to this problem only cropping up now and not in 2020.
​
The Easter Update: So after beginning to employ the new lip sync method, I'm starting to quite like the results since it allows cheap hacks like me to quickly get the characters to appear as if they're talking while avoiding the part where I do a proper job at it, all the meanwhile I'm able to fall back on the excuse that it make the short more authentic to the medium of anime despite knowing that my work will never be considered true anime by the international definition in a million years. Of course, I could also use it in my more western inspired shorts as a temporary approach until I reach the clean up phase, where I'll then replace the lip flapping with proper lip syncing.
​
Luckily, the game actually does have a gadget called the "Head/Camera Tracker" (which was added in the VR update) which I can scope into and add a smaller version of the speed background asset and the mirror model that'll stay attached to the screen, thus allowing me to create a faux split screen shot, since the Head/Camera Tracker automatically snaps itself to the same position as the camera. The only thing I believe will be difficult is making sure I position every element correctly, since I won't know until I go into play mode (meaning I'll need to take a start and stop approach with this but hopefully this doesn't take too long to put together)
​
24/4/22 Update: Well, that was a whole lot easier than I initially thought, as I was able to make the split-screen effect as a separate asset before I began actually doing any animating, so that saved me a ton of potential headache (and since I did this during one of my days off, I didn't have to worry about getting hounded for not doing work), not to mention the "look through head" feature of the head/camera tracker gadget allowed me to get said asset done quite quickly. Once I put the new asset into the scene, it was just a matter of turning it on with a keyframe at the right time and adjusting the effect slightly so that Kyoto's hair doesn't exist above the black line and I was all set, so we can consider this problem solved.
So How Was Tackling The Problem Solving?
Well, I'll be honest, it did feel a little bit weird that this section even needed to exist at first, but once I found a format I felt would work, I was able to get my head around this. At first, I originally wanted to make it so that the parts where I describe the problems themselves and how I solved them to just be copied and pasted directly from the other sections of this very website, thus making it a compilation of all the major problems I came across throughout the project, but as I continued further along with writing original text for the first few problems and the nightmare that was copying and pasting my unit 12 research into this website, I decided against this idea and just moved on with writing original text for all of them instead. (with links to the sections each problem corresponds with as a means of easy access of course)
​
In a way, taking this approach actually allowed me to reflect on each problem on an individual basis, which is something I probably wouldn't have had time to do throughout the entire project as a whole, and it made me think more about how I would be able to solve them all, not to mention having the date I came across the problem and the date I ended up solving it was quite a nice touch, as now you'll know exactly when each problem came up and what day I solved all the problems.
​
The reason I'm writing this reflective piece now instead of the day the final problem was solved is that I didn't want to have a whole reflective piece written up about how doing this section proved to be only to find myself coming across an unexpected problem during the feedback implementation and clean up phase of production, thus meaning I would have to start the reflective piece all over from scratch, but now that this project is almost over, I have the feeling there aren't going to be any major problems, ones that would change what I have to say here at any rate, anytime soon.