Week 10 - Modeling the Eye

So our initial idea for modeling the eyes was actually a vizor..simply because it looks so modern and badass! Here's a reference we looked at for the eyes

So after drooling at how sexy the vizor look like, the idea was sadly rejected because it'll just be copying Robocop all over again. Moreover, our director Monsieur Loredo wanted our design to look more unique, hence we went with the cyclops eye look. 

Looks pretty good huh? Our idea was the eyeball would be black and shiny, kinda like a glass ball and a red dot light would be emitted inside of the eyeball for the pupil. I decided to add the eyelids to give it a sense of character, and moreover in case we needed to show character of the robot. Our group agreed on it so i decided to double confirm by pitching it to our awesome lecturer. Sad to say, it didn't quite agree to the concept, and suggested a much better one! This werethe reference he showed me,

He feels that the eyes should look like this, concave inwards with a bright lid to show the pupil, and to my surprised it look darn good! Moreover, he was kind enough to show me how it is modeled and the secret behind in making the light shine so bright! This is how the results came up to be,

Sweet right? The black rim around the light is a chrome material and I feel that it helps to draws attention to its eye. So after looking at how awesome it is, and being my usual ambitious self, I decided to give another colour variation just for look sake.

Tadaa the colour red! Why red? Well, I wanted it to look like it is angry when the eyes turn from blue to red. Kinda like when it realisez a threat and turns into combat mode! And with spare time, not that I had but I just wanted to do it so I could see how it looks like, I decided to modify for a bigger pupil.

Within a short time, this is how it looks like. I was pretty surprise how good it turn out so I suggested to our director Kevin. However, he felt that it looked too big a kawaii so it wasn't use in the end. Oh well, at least they have the option to use it if they want, so I did a red colour variation of it.

After doing the red variation, I gave it a switch to alternate between colours...taking that if we were ever gonna use it that is...It would be cool if they animated in the TVC though but guess they didn't.


All in all, doing the eyes was pretty fun, especially when you get to see the emotion of the robot, you would just want to add more things onto it. But i guess our idea was not the have the eyelid from the start, so it is kinda of like a sidetrack of idea. And for the lecturer who helped me in this one, just wanna say Thanks for this awesome suggestion. It wouldn't have turn out this great if it wouldn't..


My last post of Technical Journal, its been a pleasure. Till then, when I come back to Lasalle..my journey continues..

Technical Journal Week 9 - Rigging and Cleaning up transformation Gun

So during my long painful journal of rigging, and after finally finish rigging all of the parts..except the transformation, little did I found out that there were so many flaws in the transformation of the gun my group mate had passed to me. I literally pulled my hair out of frustrations when I saw the amount of intersections, design flaws, tilted poly and missing bolts in the model. It was a huge eyesore for me although the transformation was just a short while in the scene, as a rigger I couldn't stand leaving it like that. So I painstakingly had to do all the cleanup and fixed the parts and movement according to how physics would work.

 These are just SOME of the uncleaned work of the gun

Intersection when hand moves into lower arm main body

Tilted poly that had already been freeze transform!!

Fingers are not straight and rotation are all screwed. A big headache for rigging.

Nozzle frame intersects when transforming. I know this can barely be seen cause its so fast but to me its just an EYESORE!

The crazy amount of intersection when the hand move into the main body. This took me literally the whole day to solve it. Having to re-design the mechanism and the shell of the main body so that there is sufficient space for everything to sit in even when it transform.

Missing bolts and pieces that don't make SENSE!!

A piece of poly sticking out that is suppose to beneath and follow the highlighted green cover.

So after about a day and a half re-design a little, moving vertises here and there because it is already UV-ed...and making sure everything fits nicely and NO INTERSECTIONS and it works according to phyiscs...this is the results..like finally

Perspective view of the cleaned and revamp Gun

As you can see there are no intersections anymore. The parts work well together in harmony and the plates are connected properly with joints the adhere to physics. No more floating parts. Moreover, I had to painstakingly animate exactly every single part and key frame from my group mates animation in the old gun onto this revamp one. It was excruciatingly annoying but I was okay overworking myself to make things better. Moreover, this will be reflected in the rigging reel so I want to do my best for it! Oh and not to mention, I've also re-rigged this and add proper controls to move the parts individually.



After much effort to cleanup every detail, the other difficult process was to SDK the parts so that they react to 1 attribute. This was quite troublesome and it would take too much time to SDK every parts into 1 attribute. So from here, I had my rigging pal Gabriel helped me through a use of a plug-in to connect the parts  to the attribute via node editor. Thanks you GAB if you ever see this post! :D



So in conclusion, WHY MY LIFE SO HARD?! That's animation for you~ doing cleanups since the dawn of time..

Technical Journal Week 8 - Clavicle Aim constraint to IK

From the continuation of last week, this week i decided to be a little more ambitious. You got that right, having the shoulder control move with the IK arm so I don't really have to animate both! As
I recall, this was actually tested on my last semester's character and sadly it didn't work out too well. So I decided to try it again since I am dealing with non-organic character this time around.

Rotating FK clavicle ctrl

So after much thought of experimenting and failed, I decided to actually have two clavicle controls, one for the FK and the other for the IK.

I decided on this because after trying out with one clavicle controller it seemed to have a clash. Taking that I parent the shoulder control to the clavicle control and aimed constraint it to the IK, whenever i move the IK the FK it would follow exactly where the IK is in space. This was an issue as i foresee a problem with animation when I switch between IK and FK. For example, when the FK shoulder control is rotated in the opposite direction and the FK clavicle follow the IK wrist control, switching between IK and FK will tentatively complicate the placement of IK and FK.

Hence, after this complications I decided to go with 2 clavicle controls for each, IK and FK. This is how it turns out when I rotate the clavicle for IK and FK.

Rotating IK Clavicle ctrl

Well, so far so good. Assure as it looks, I went ahead to test out poses.

Everything seems to be fine. The switch between IK and FK works as it should so far, theoretically I suppose. However, problems started to happen when I move the pole vector controls in awkward position.

I began to twist the pose more extremely, it still worked fine. Until the pole vector and this happened. Switching between IK and FK twisted the clavicle around. I checked the local rotation axis but to no avail it didn't solve the problem. I even created the locator behind the clavicle control to use as reference for the world up vector when aim constraint. After hours of testing and trying out different methods, using offset and etc. I decided to just scrap it and rig it the conventional way. Guess I'll leave this one a mystery until I have time to get back on it! Moving on~

Technical Journal Week 7 - Rigging Lower Arm wrist issues

Happily rigging I was, I ran into the biggest problem I've ever face in my rigging experience.It's pretty difficult to explain so I'll show you an image and go along from there

In this image, you can see an IK rig functioning of what it seems to be right. However, the biggest headache arises when you discover more problems and trying to solve them brings you back to square one. Before I began my 3-4 days devastating troubleshooting journey, let me explain to you how the mechanism is suppose to work on this robotic arm.

As you can see, this robotic wrist is modeled in a way that it can only turn 2 axis; the cylinder connected to the lower part of the hand and the hinge joint between the cylinder and coin like shape at the end of the lower arm. This is a huge problem especially for IK rigs because IKs are function to rotate in all directions. Moreover, the challenge is that there are 2 parts involve in 2 different rotations. So the first thought that came into my mind was to orient it in only 2 axis that i rotates and parent them according to hierarchy.Things seem to look right for a change until I translated...in a different direction.

To my dismay it wasn't as simple as logic sounds. It brought up a new problem right away.

The parts began to intersect and there was no way a hierarchy solution could solve it. Tested and PROVEN! Self explanatory of how it works from the image. So I began to consult my best pal, the master of RIGGING! You got that right, GABRIEL!


 He came up of what it seems only a temporary solution to the problem. Yes, creating a double joint for the 2 separate rotation parts. Kind of like the IK twist rig for the wrist joint in organic characters. However, after testing I encountered cyclic warning. In other words 2 or more things are rotating the same part and in the same axis. Sadly, I don't have an image to show as I accidentally deleted the file because it did not work out. In retrospect, there were still intersection, trying to force the IK ctrl to follow perpendicular to the lower arm would cause the cyclic warning.


So after almost a week of troubleshooting, I decided to consult my lecturers. It was tricky at first but he came up with this solution of a rig.

 All seems to go well. Translating Y and rotating Z.
 

Rotation too, until this

What seems to be unavoidable. The wrist rotates as you translate X.

Hence, the problem was still unsolved.



Until i realized, why use joints when I'm rigging a DAMN ROBOT?! *facepalmed*

After realizing I knew exactly what I had to do, and time was not on my side. So what I did was use locators to control the fingers through a set of SDKs. Got rid of the double jointed wrist and set a control SDK for the IK/FK to rotate separately, except for the cylinder that is connected to the hand, that part it driven by a crescent moon shape control.

So in conclusion, you gotta cheat and work SMART! Glad that's DONE!

Technical Journal Week 6 - Improved Foot Controls and Pivot

In this week's schedule, I was task to rig the robot and I had reach to the progress of rigging the foot.

Although you may already be familiar of rigging the foot through the use of SDKs - Toetap rigging. I decided to improve it and make it more convenient as through the previous semesters I've encountered restrictions with the Toetap rig. Here's an example of my very first toetap rig I did ever since I began animation,

As you can see, on the right hand column there are attributes controlling the movement of the foot. Don't get me wrong, this method works fine for animating but the catch is you do not get the pivots you need for certain movements. Moreover, after using this rig, I found it redundant to actually have SDKs (set driven key) for Heel Roll, Heel Twist and Heel Tap. You never actually have to use those because the base control on the foot could already do those movements, unless you actually move the pivot that is. So why didn't I use this rig again? Well simply put, this rig has gotten a little dull and I needed something fresh and better!

Inspired from the Norman rigg, I came up with this

Yes yes it's nothing special in particular, but what I love about this kind of rig is that you get to be more versatile with the movements. For example, there are 4 pivotal points controlling the foot. For instance, if you want to do a tiptoe all you have to do is select the specific yellow control and rotate it. Moreover, there are no limits as so to using SDKs. In other words in a proper toetap rig you set it to rotate at 45 degrees and that kind of restricts the movement. But then you will ask, I could just connect the attributes via connection editor, that would give the same results! I would agree on that too, however having SDKs will not give you at much pivotal points as a control base rig. Even though it could be accomplished, it would take much more time to rig it and you might just complicate the whole rigging system. As a whole, through my experience I would actually rig from the control than the SDKs simply because it looks more practically to my eyes, even though both an SDK and ctrl rig was available to me.


Here are some screenshots of what it can do!

 Foot Bend

 ToeTap

TipToe

SidePivotRight

 SidePivotLeft

 BackPivot

Here's an overview of the outliner

There are more movements it can do as well, like swivel of the back and from pivot. This rig is good for animation such as falling or acrobatic dance movements.

All in all, when it comes to animating it all boils down to preferences. Hence rigger these days try to give animators as much options as they can to animate. However, you can only put so many different functionality into a rig. As a result, riggers try to figure out the best and convenient ways for animators to animate. 

Technical Journal Week 5 - Hinge joint on elbow

Following the last post about modeling and the difficulties I have encountered, this time around I am going to talk about the other components I had to deal with, and the mechanics inside the elbow joint.



And so as usual being overly paranoid at times, the design and mechanics of the hinge joint was something that bothered me a whole lot, and I just had to do something about it. Although my group mates were alright with it, I was really persistent in changing it and went ahead on my own.

Not to mention, there is a major design flaw in this..and yes! I presume you could already foresee it. Intersection of polygons! Gahh it never ends!

As predicted, this was how it looked like when the elbow was bend. The intersection was pretty bad that even at 90 degrees you could already spot the obvious. Moreover, I was very bothered by the fact that the hinge joint looked a tad too simple and predictable! So without hesitation I went straight into looking for references!

Also known as the EB208, these two robots were modeled and design from this artist called Fausto De Martini, which also had design the robot for the latest film Robocop.

So after looking at these references, I was particularly inspired by the mechanics of the double hinge joint at the elbow. Also, the mechanics on the shoulder caught my attention as well. It functions the same way as the Elysium robot the lecturer had showed me the other day and what's surprising is that the mechanics are exactly the same.

Anyway back to the point, the double hinge joint looks rigid and sturdy and something out of the norm. So I decided to develop my ideas from there.

I started out with a single hinge to see how it would work out, however I realised maybe i should add a piston or two to make the mechanics look more complex. As I work my way, it came to my attention that there were insufficient space for two pistons to be in front or next to each other. After much consideration, I decided to place one piston in front and the other behind. This decision was simply made because the hinge is at the center of the upper and lower arm, so I presume placing one in front and behind would balance the silhouette.

 ....and i was wrong. Doing this would bring up more problems. Since it is a single hinge joint, placing a piston behind would intersect when the elbow is bend. As a result, I had to scrap this concept completely and work from scratch.

After much thought in the shortest time, I came up this concept of a double hinge joint. In addition, I modified the upper arm to give ample space for the lower arm when it bends. Also, doing this helps to reveal the mechanics that best represents the robot. Still in WIP as I go along to explore more possibilities. 

With much patience and time, the hinge is finally done! However, I did still ran into complications and made a little modifications here and there. But this image here you are looking at the mechanics is workable with no intersections. I had to deal with small problems like the back piston was intersecting with the 'L' hinge when bent to a certain degree. Hence, I had to arc the piston in a way that avoids touching the 'L' hinge. Moreover, I added a some pipes and springs to give a well rounded finish. However,there was one thing that still bothered me aesthetically and it was the two plates behind the elbow hinge. It needed to be connected to something.

 

So I modified the shape and gave it a bolt to connect the hinge. Originally, I wanted to give 3 to 4 plates so that when the elbow bends, the plates slide above one another giving it a cool looking shape that covers the elbow. However, after much discussions with our leader Kevin we decided to leave the idea as it is. Reasons was because he didn't want it to catch too much attention on a particular part....and with all discussions close this became our final model for the elbow and hinge joint.



As a whole, doing this was to an extent challenging for me as there were no drawings or whatsoever to follow. I had to popped up the idea in my head which took quite some time and had discussions and feedback with the lecturer. The most challenging part was that I couldn't change the geometry of the lower arm and more so retain its exact shape. In other words, the only components I could modify was the hinge and upper arm. Now that it's done, I am glad that it turned out pretty well and I don't have to think about it anymore!

Technical Journal Week 4 - Modeling the torso ButlerMech

Conceptual Stage - Torso

In this post i'm going to talk about the initial concept of the torso, my break down ideas and the complications I face, where ultimately finalizing the model.


In our project group, we were task to model each part of the robot separately, and modeling a torso with a unique function wasn't a smooth journey for me. As I had a faint picture of how I want it to look and function, I began to scout the internet for references.

 

This was a pretty cool idea when I first saw these pictures. The first thing that popped in the head was Doctor Octopus from Spiderman or the assassin whiplash villain in IronMan. They both had a mechanical spine at their back that looks wicked and thought I should include it in the robot.

Mechanical Spine that acts like a support for a suit

Some crazy looking detailed spine

These were some of the references I took. When I saw these, it became daunting to me as to how I would model a spine this epic in the shortest amount of time. Sadly, the fact is I dont! So I probably had to simplify it and made the functions less complicated.

In due time, I modeled the initial concept of the torso and added two large pistons at the side, simply because I felt it looked too plain without it. The pistons was kind of a last thing that popped in my head and I quickly look at examples of the Terminator robot. As you can see, I attached the spine at the back, but beneath the Torso plate. I wanted the spine to be part of the body and not look like it popped out from the torso like an extra component. More so, I added a little design to the lower torso to give it a proper finish.

After modeling it, I decided to do some test. The results were pretty satisfying and I was quite happy how it looked with the spine. It makes it almost like it is a human robot.

Some other test poses

Seems like everything is fine...until I encountered this.

The intersection when rotating Y axis. This was a huge problem for hard surface modeling...
There is no way to avoid this as I realised human spine is anatomy placed at the back and not center of the torso. Moreover, this came into my sudden realization that some robots I had seen in games or films, where the lower torso filled with wires are used to avoid hard surface intersections. This became imminent that I had to either skin the lower torso like a human flesh or revamp the design.

After consulting our lecturer and group mates, this became our finalized concept where the pivot for every component is at the center. This would probably be the most generic way for a robot to move similarly to a spine. However, dateline is at stake and I guess we have no choice to dwell so much on certain areas. As Tosh Roc aka Sergeant Ong always says, Moving On~

After much discussion, here is our finalized concept!


In conclusion, as long it works Move On!!