Updates as of October 13th, 2014

This may be one of, if not the last update relating to the golem. It has recently been given to the Studio X animation department for testing. Going through the notes, there wasn't too much that needed to be changed, and a lot of personal requests for particular things that didn't apply to the golem due to the nature character's design. One thing to not was that many of the animators did comment on the overall complexity of the rig, which is understandable, considering all of the moving components that are contained on it.

I've also had it looked at by someone in the field, and they were impressed by what they say, as I had shown them the test animation I was working on, as well as the calisthenics test. Their only critiques were to have a close up of the facial area for some expression displays, some extreme poses to break the character, and a walk cycle. They did compliment the fact that the vines worked as well as they did and the variety of rig types that are connected to the character.

On the other front, I'll be creating a demo for one of the other characters I rigged during the Studio X program. I do need to ask for an animation sample of the character, but I do not think that there is anything completed relating to it at this time, so I may either have to create a quick piece myself, or as for a WIP animation from them.

I'm also hoping to be allowed to showcase some other characters from a separate project from outside the school. However, the person is unsure on the decision at this time, so it's up in the air if I'll be able to show it as part of my final review reel.

Update as of September 21st, 2014

Here is the current status of the golem. The vine script is finally done. A user can create a vine with controls in any direction they want, as well as adjust the thickness of the vine, allowing for either very thick or very thin poly tubes. Originally, there was an issue where the script would allow multiple copies of the locators used for the path, resulting in the script logging a KeyError out and mucking up the previous setup's system. To counter this, I have the buttons lock upon their usage, and unlock once a system is built. There is also a reset button, which clears out the current system being built. To be extra cautious, I have the script log a KeyError in case the user tries to use the same name again, informing them to enter a new name.

On the rig front, I've made some further modifications to the rig. To start, I have the limbs and body form in a sequence, rather than the bulk of the appendage moving into place. This can allow for more interesting animation possibilities. I've also changed how the IK controls on the arms work, allowing for a smooth transition between local and global space, rather than snapping between them. Below is a rough test animation I did to get a better understanding of how things are working on the rig.

While working on the above animation, I had caught a few things that needed correcting that hadn't been brought to my attention previously. A few tweaks later, and things were in a better state. Unfortunately, one of the animators I had asked to test the rig is no longer able to bug test, so I've set up a meeting with the animation department lead to hopefully find a replacement. If one can't be found, I have another contact that offered to help find an animator to test the rig out.

Less related to the rig and more of the textures and materials, I changed the brightness of the horns. The reason behind this is that I asked someone currently in the field to give some advice on how the current model looked. Ultimately, they recommended I make some changes to the horns, the vines, and the area around the boulder.

The horns were casting too much light on the surface directly next to them, so they recommended I bring down the intensity of the light coming from the horns. They also pointed out that my current light setup for test rendering needed work, So I swapped out the spotlight I was using for a directional light. After about two and a half hours of adjustments, I've come up with the images below. It mostly came down to ramping up a lot of final gather settings and playing with the lighting a bit.

With lighting

Without lighting

New directional light with increased final gather settings.

updates as of September 12th, 2014

At this time, I've corrected a few things that still lingered in the main setup:

• Due to the blendshape system I used to create the eyes, rotating them in their socket cause them to open slightly when the flower is slightly closed. I've set the blends so that they shut off if the flower is closed slightly, but allow enough leeway so they still bend a little before hitting the cut off point.
• I've added in controls throughout the small tree on top of the skull. This should allow for some more fine movement in the piece, and can be hidden or displayed via a new attribute on the head control curve.

A new feature I've added in was a more autonomous control setup for the tree stump.

The top directional control above the stump allows for it to shift about, while leaving the roots in their relative place. This control can switch between the local mode, which parents it to the leg joint of the main skeleton, or the roots control, which unlocks a global location control. This is also true for the base of the stump. By adding in a new control to the base, it can switch between the local control of the main skeleton, or a global control for the animator to place where they please.

Another addition to the rig is one at the head.

One of the animators I have testing the rig out requested the various branches have their own controls. I had at first thought of doing this in earlier stages, but had held off on it, thinking that animators would want to avoid as many minor controls. Looking back, it was a foolish decision, so now they've been placed at the various forks in the tree. I will need to update the nCloth file now, however, since the joint count has increased a fair amount.

Elsewhere, on the vine script front, I've made some strides. The curve itself can now match the positions of the joints in the standard version of the vine. I've also worked out how to add in attributes onto script generated controls that aren't just float numbers. Also, thanks to an expression a professor tested in the past when I had the vine scaling issue on the main rig, I've been able to scale up the script vines. It's still not a perfect setup, as paint effects cannot scale in the same way normal geometry does. However, I have found that, by adding in another attribute on the control, an animator can counteract over-scaling when attempting to re-size  the vine. While the control connects to the global scale of the paint effects, the additional attribute increases or decreases the pressureMax attribute on the stroke. This, in turn, can allow the paint effect to stay within a desired parameter of thickness.

The last aspects of the script I need to create are to be able to position the locators anywhere and have the base control be generated there, and the other controls for the rest of the vine to be moved by.

Update as of August 12th, 2014

So a few things to note today. I've completed replacing all of the ground point controls so they stand out against the individual controls of a component. They now consist of two controls: one for the position, and one for the rotation.

I've also replaced the controls on the IK arms and their switches, so that they stand out more.

Same goes for the back vine controls closest to the body. One of the animators I asked to test the rig mentioned that the previous controls got lost in everything, so I vied for a pin shape with a bulky head that stands out away from most of the other controls.

Another error I found was that the left eye wasn't completely working. At some point, the connections were either left incomplete during the time I was preparing them, or a connection was broken amongst the blends during one of the repair sessions I had. none the less, it's been fixed and works just as the right eye does. There was also a nasty issue with the influences in the neck, where the vines, when in place, would overly move with the rotation of the second neck control. Add to this that some of the base points of the neck vines also had some lingering influences that caused them to shift when the neck was moved. This has also been remedied.

The last change is more of an addition. I'm testing out, visually, if adding some smaller vines onto the anchor would be more aesthetically pleasing.

Updates as of July 31st, 2014

So a few updates, but nothing radical.

The golem:

Still trying to figure this golem out overall. Modified the right arm so that it just runs on an SCsolver and some orient constraints, while the left arm uses an RPsolver, but has no real palm or wrist beyond the radius and ulna twist. Also added a new control to the stump, so that it can be offset a bit from the main body, though I'm contemplating making it a separate entity like the stones. Also streamlined the foot rolls into one node.

I'm honestly glad I took a semester away from this thing, because now I can look at it and see what can change to streamline things, as well as fix some readability in the controls.

Studio X

Things are wrapping up, and most everything that was worked on has been cleared. There was a minor hiccup with one file where the skin had been detached and re-bound by someone else on the team, leaving the weights in a poor state due to Maya's lackluster import weights function, but nothing serious enough to cause panic. A short time later, it was fixed, and I proceeded to make other fixes to the rig as a whole.

Beyond these, not much to report on. With the semester coming to a close in the next few days, work will shift back onto the golem with some more refinement and, thanks to a few friends of mine, animation testing.

Cheers,

Dan Rico

June 22, 2014: resuming activities

A new directed studies class, so a new set of journal entries. The current class is Rigging Studio X, which simulates the workplace of a company. For me, this isn't particularly new, due to previous freelance work. However, due to NDA documents, I cannot discuss what it is that I'm actually working on, unless given express permission by the parties helming the projects. The most I can say is that I'm currently on a conceptual project, and may soon be on another. If I complete a prototype of one rig, I may be placed on a previous project again and resuming some work there, though I may just keep tabs on it, as I'm on a higher rung in the hierarchy for the class.

As to my golem, I took a short break from really working to give my hands some time to recover, but I've made a bit of progress. Firstly, after a bit of feedback relating to the look of the ground controls, I'm going to test some new ones.

Mostly, I just broke apart the translation and rotation into separate controls, as well as making them circular to better distinguish from the boxes that normally control the various stones.

Beyond this, I did a few texture upgrades.

First are the horns. Using a combination of raw sapphire and smoothed ice from Ice caves, I created this look for them, as well as duplicating and crushing the mesh inwards to create a brighter core for the more intense glowing and light emission.

Then I added the final emblem design onto both the anchor and the opal chest stone. The rainbow effect of the flakes is still not quite there, since the reflective flakes are not randomizing the colors just yet. hey are only based on a sampler info node that connects to a color ramps facing ration node. Once again, I have a dual layer of geometry, though this time, the top layer serves as the surface for the emblem and some transparency to help bloke out the flakes in the blue veins, while the inner geo has a car paint shader to simulate the opal flakes.

Thats all for now.

Cheers.

Updates as of May 11th, 2014

Not much in the way to report this time around. I've completed adding in the remaining cloth sim components for the simulation file. It works for the most part, however, there is an issue with the proximity of all the nCloth objects to one another. With self collide enabled, the simulation time skyrockets, due to the collision thickness is in constant contact. To prevent this massive time lag, self collide was disabled for the time being.

Meanwhile, to reduce the overall dynamic file size, I tossed out all of the excess geometry that have no nCloth counterpart. I've also connected the cloth objects to a control to enable and disable the simulations, so that animators can turn on the dynamics when they wish to do so. I've also create a low res cage for the skull tree to help with simulations.

Everything is currently cached out to help out with calculations.

updates as of April 24, 2014

Not as much to report, given the large span of time. To start, I did create a brief test animation relating to the rig as it stood on the 9th of this month:

Nothing amazing, beyond showing all the components running in conjunction with one another. No dynamics were set beyond the vines at the time of the assembly.

However, while testing, I did discover an odd occurrence relating to the head. When it was set to it's ground locator, the control on the main rig would still have influence over the rotation of the head tree, and that of the eyes. After digging a bit, I had concluded that the orient constraints that were running were broken in some way, so I removed them. In their stead, I constrained the eye controls to the actual joints that bound the skull geo, and had a direct connection from the joints on the main rig onto those that bound the skull tree.

There was also a second issue relating to the two wood plates on the golem's back, where I had unintentionally broken the parenting setup. Where I had intended them to switch between their ground locators and being parented to the chest's center stone, they simply stayed parented to the stone, and would be immobile while set to their supposed ground locators. Diving into the outliner, I corrected the problem, in that I had removed the double parenting, and created a fresh parent constraint to the proper components.

Past this, I decided to revisit the vine script I had made a while back. After building the finger vines, I decided to do a little revising regarding the setup, ultimately ditching the command to look up the Ivy brush that exists in the paint effects, and using the default one that comes pre-loaded into the scene. I'm going to try and combine the two halves of the script, in that it would ultimately mimic the finger vines, but with a little more control regarding the shape of the curve before running the dynamics.

At this time, I've created a separate dynamics file for the stones and wood components, allowing for some easier testing in a lighter scene. However, it's difficult to determine how everything will interact, so the file is referenced into an animation scene.

Here, using the gray wireframe to indicate the original geometry, I can see that the hand stones and the left leg stones should be loosened in their constraints, though to what degree is difficult to predict, as the scene, with everything running, becomes heavy to simulate. It's pretty much trial and error at this point.

Updates as of April 4, 2014

Been a bit of a spell, but here is the low down.

First up, the left hand dynamics had a rather nasty issue. When simulating on campus, the geometry moved as it should, staying connected to the body. However, at home, the geometry would disconnect and float off into space, before coming back. after a bit of investigation, I found that it was the dynamic curves that were being offset. There were three attempts to remedy this, the first was to bind it to joints, the second, being a blend shape node that linked back to a duplicate of the original curve, and then using an IK spline setup. Ultimately, it was the fact that all of the curves were simulating on one nucleus node, rather than being on either the same hair system or having their own nucleus to simulate off of. After a brief adjustment, this was remedied, and the setup worked.

All of this, so that, a dynamic setup could be achieved on the finger vines. This setup allows for jiggle when controlling the position of the vines, and can allow for complete freedom on the vine's part to move around.

After that bit of madness, I created a new control to influence the visibility of components.

This would allow animators to lessen the burden of the rig on their machine and the scene in question, as having everything active would be a hindrance.

I've also been readjusting some of the influences on the vine curves, so that some of the assembly control pieces, now fully functional, can move the vines themselves. below is a small example of this.

I've also gone in and separated the anchor stone from the golem, allowing the golem to move about freely, or be tied to it, if the animator so wishes.

Even more so, I've added an extra control to this so that the anchor stone can be flat out hidden, allowing the animator to work with the golem as a stand alone.

I've also worked out the eye system, where when the closed blendshape is active, it neutralizes the other blendshapes for when the eye moves about in the socket.

It was a simple matter of plugging in the close blendshape's output state into a multiply-divide node as the first input, then plugging in the rotational blendshapes into the second input state. For example, the closed state going into input 1X, and the forward y rotation blendshape into input 2X. As a result, whenever the eye is open (open blend active), it allows the rotational correction blends to work. However, when the eye is closed (Open blend inactive), it sets the 1X node to zero, cancelling out the rotation correction blends.

I have recorded a demo of the dynamic vine system on the left hand. The original curves are bound to a broken joint chain, allowing for the vines to be posed. The dynamic vines themselves can be activated or deactivated, as well as influenced by the original curve. This gives the animator the ability to make the vine either very stiff, or very loose and able to flop about.

On the topic of the dynamic curves, while working on a separate file for the golem, I ran into an issue with a script I had been using. Originally, the script was meant to create the vine curves, and could create the dynamic sets similar to those on the left hand. However, upon testing the script in a referenced scene, I found that, should an nDynamic nucleus already exist in the scene, it would attach the nHair system to that nucleus, and disrupt the rest of the script, preventing the new setup from being tidy. I had tried a simple fix, adding in a few lines to set it to a new nucleus, but this also had a drawback. If this modified script were to be run in a fresh scene without an nDynamic, nucleus, it would create two nuclei instead of just one. I'll probably need to experiment with an "if than" or and "if else" command in my script to prevent this.

Rig updates as of March 12, 2014

Been a bit longer than the norm for updates, but here is the current status of the golem.

At this time, I've completed the ground to control rig system for all of the individual components, as well as set up attributes on the golem global to hide the numerous controls across the rig relating to that system. All of the normal maps for the major body components have been completed as well, so the only things left to texture are the horns, the chest opal, and adding the opal's glyph to the anchor stone.

Relating to textures, I've replaced all of the materials for mental-ray materials for better accuracy come render time. The horns and opal also have a surface light node plugged in to the mia_mat's additional color node, which allows the material to emit light.

Back on track, I did encounter a rather frustrating issue with the paint effects curves I am using with my rig. Due to me attempting to use a multiple component scaling system, where in the anchor stone and the golem could be scaled both independently and in unison with one another, the vine geometry would not scale properly along with the rig. It would shrink in diameter, which as one would guess, is not a good thing.

One fix I attempted was the wrap deformer adjustment, where in the geometry that is being wrap deformed onto another object is bound to a single joint, and that joint is placed in a group along with the main bind joint system of the rig. However, this lead to the double transformation problem seen in the lower half of the above image. Ultimately, I had to scrap the individual transformations and settle for the main global to do the scaling. This still left with the diameter issue. To get around this, I plugged in the scaling information from the main global control into a condition node, then took that information and plugged it into a multiply divide node to whittle down the data. Finally, I took the output and sent it into the pressure max node of the paint effects strokes. Once connected, everything scaled properly.

After that problem was dealt with, I moved on to adjusting the left wrist area again, as well as adding dynamic hair curves so that the finger vines could have a large amount of jiggle if the animator so wanted. With a separate control above the left hand stone, the dynamics, and the corresponding geometry, could be enabled or disabled at the animator's whim.

Relating to dynamics, I'm hoping to begin adding in some of the jiggle/jostle systems for the rig soon. The only things left to really set up on the rig that don't involve dynamics are the eye flowers, which have been started as of this post, and the tree on the top of the skull.

For now, here are the current textures on the golem:

Displaying the subtle light emissions from the horns and opal

Showing the adjusted teeth textures, as well as the adjusted vine colors.

Update as of February 24, 2014

I'd like to say that the golem rig is at a good point at this time. I've managed to bind all of the key components to where they need to be, the vines are moving around nicely, and the diffuse passes on the textures have been completed. At this time, none of the dynamic simulation components have been added yet, as there are still some errors that need to be tended to. I have also added joints throughout the goelm in anticipation of both the construction rig and the usage of jiggle bones.

Test render of some of the textures

Second test, full view, no anchor vines

Updated materials on some of the components, plus a different light setup and the anchor chain.

An attempt was made to use the dynamic hair system on the finger curves, thereby allowing a more believable sense to the fingers being vines. However, I need to consult my advisers on how to make the base of the vine more stiff while not sacrificing the stiffness of the vine near the tip.

As a bit of an aside to the main project, I'm going to attempt t create a ragged looking cloak to add on top of the golem. It's mainly for a cloth sim class, but it can also allow for better insight onto using nCloth throughout the rig itself come time the rig is labeled ready as an animatable piece.

Below I've attached a current visual breakdown of the rig at this time.

16-02-2014 update

So much to place here, yet so little. Since the February 5th update, I've gotten a lot done behind the scenes, such as finishing up the UV unwrapping and binding the skeleton to controls. All of the vine curves on the main body have been bound to the skeleton, and a good deal of skin weight adjustments have been made so that deformation feels more believable when things move about. Thank you Component Editor.

Elsewhere in the project, I got some texture work started, focusing mainly on the diffuse pass for now. I've also cleaned up all the naming conventions, as I was scolded for not having my initials on everything within the file itself. Add to this the IK FK setup on the arms and the IK systems on the legs, and most of that technical bit was set.

Some planned sculpting for the back components

temporary mockup of the current textures on the model 

I know I'll need to adjust the texture a bit to closer match the original concept art colors, but that'll be on the next update.

Back on the setup page, I broke apart all of the vine animations onto their own controls, so now the arms, body, leg, and neck can grow into place individually. This was done using the set driven key setup and keying the max clip control on the paint effect brush stroke. Needless to say, I should look into a faster way, if possible.

 

Past this, I've also blocked in the anchor, as seen in the background of the video above, and setup a temporary control system for the vine chain leading to the golem. This simply consists of an IK spline controlled by free floating joints. Still, the section between the anchor chain and the golem's back vines needs to be worked on, as the current point and orient constrain setup has an issue where the joints flip. not a good thing.

Current rig setup

Lastly, I'm currently developing a design to place on the anchor to help round out things. I liked the look of the calligraphy word god in arabic I want to use on the stone in the golem's chest, so I want to create something similar to the look for the anchor stone.

Update for the week of January 27th, 2014

So after a semi break between sessions, the opening week classes brought about some more work on the Curpigeon birds. A few nodes weren't functioning as they should, so some reorientation was needed to fix the issue. However, I was asked to add additional controls to the facial setup to the sixth pigeon. There is still an issue with the right wing, but I will need to ask the person who set up that bird on their method for it so as to fix the issue proper.

Meanwhile, I've returned to my golem once again, completing the vines that permeate it's being.

I've also added in the sapphire horns atop it's head. All that is left is to replace the tree on it's head, and the stump that acts as it's left leg. The reason for this is due to an earlier version of zbrush creating some none to friendly geometry. The poly count ended up ridiculous, as well as spiraling down some of the branches and roots. not optimal in any way for unwrapping. Speaking of unwrapping, everything was also unwrapped over the weekend, minus the tree and stump. This means I can start hunting for some textures to use, as well as experiment without the texture being mangled.

For this week, I'm aiming to begin the controls setup for the arms and spine. I want to try a ribbon spine system, considering that there isn't a rigid fixture between the hips and the rib cage. I've also been asked to clean up my naming conventions on the file, which I completely agree on, as I've been sloppy about it this time around due to my focus on the vine growth system, what with it being one of the key elements of this character. I'll attach some demonstrations below.

The vine animations need to be broken apart and attached to a better controller, as currently they are all driven by one, and run simultaneously with one another, as can be seen in the videos.

I'll also be test skinning the vine curves onto the rig to check for areas that may be problematic when the character moves. There is also the construction system that I need to work out. I'm considering creating floating joints that animate into place on the main rig. This way, an animator can place the various parts where they please, and have each one move into place. I'll need to consult my professors about this, as they might have an easier method..

Winter session wrap up

To close out the end of the winter session, I'll summarize the end results of both the curpigeon and my golem's work status thus far.

As a whole, I've technically built two rigs; the first being the 4 in 1 rig that took the whole of the entire session. The body types involved are the very thin to the fattest of the characters on the curpigeon project. It's not the most perfect rig in the world, as it still needs a low res mesh to be added so that animators won't have to fight with the rig doing calculations, and, unfortunately, some of the controls are stuck being inside the geometry, as the blend shapes made it difficult to move the controls into a better position, but overall the rig is a good success.
The second rig is for the fifth character names long beak, who's overal facial structure couldn't be added onto the multi rig. However, I simply stripped off the geometry from the main rig and reused it, with a bit of re-positioning. Do a bit of weight painting, and that character was said and done.

As to my Golem, I had to set it as more of a secondary project, but some progress was made. The constraint system for the stones was tweaked a bit more, so that the major pieces hold place fairly well, while smaller pieces have more wiggle room. I've also gone with using an IK system on the left leg's roots, so that the whole can be moved, or the roots can stick a bit when the leg is lifted up. I'll need to play with some influence objects relating to the vine curves, as a simple skin bind doesn't work as well as I would like.

Progress for the week of November 17th - 24th, 2013

Golem

While using the nDynamics system, It can simularte a spring constraint to get that floating aspect I'm aiming for. However, the points on the geometry tend to expand dramatically if there is rapid movement. Upon further testing, I've found that it works easier to use the stock settings on nCloth mesh, rather than to use one of the presets. I had thought that using the concrete preset would be best, but something in that setting results in the geometry expanding. Currently, stock settings between 2 ncloth objects cause them to phase into one another, and get their vertices stuck. For the time being, I will use the soft leather preset, as it seems to give a fairly decent result. I'll adjust it more as things progress, since I'm still noting some give in the stone's forms.

Curpigeon

More refining and fine tuning on the rig, being sure that things bend reasonably when the bird is flitting about. I ultimately went with a simpler system for the neck setup, using a broken chain system to allow for stretching. Added some small tweaks to the eyebrow controls, having a larger catch all control to move them about.

Progress for the weeks of November 3rd and November 10th

Curpigeon related:

At the request of the animators, I've retooled the wings on the rig, allowing for a more staggered range of movement. Now, if one were to move the arm control, the elbow and wrist would follow only in translation, rather than rotation. It took several trial and error sessions, and more skin weight adjustments toe get the wings to look passable, compared to it's earlier iteration. I've also added a wing fold control to the shoulder of each wing, though if the controls along the wing are not zeroed, the wings will break.

It has also been agreed on to do the singular rig for multiple birds, though a recent test showed that the other models built so far are not compatible with the base model, preventing the blend shape aspect of the rig from working properly. I may need to find another solution to this quickly.


Golem related:

more modeling work performed, adding in the arm vines network into the body, as well as the support vines for the left shoulder. I've also connected some of the brush nodes onto a simple control system to test the rate that the vines could move. While a nice representation of what I'm aiming for, the vines themselves need to be broken apart within the time of the controller, so a more refined control will be necessary for the construction rig.

The animation aspect of the rig may now have some new foundations, after I had asked one of my professors who had worked on the rock monster in "Galaxy Quest." He commented that the monster was actually a set of props built onto a single rig. The first set was just the big shape of the monster so that the basic movements could be done, verifying that an earlier idea I had for the rig wasn't far off. The second portion of the rock monster rig, which is what I've been struggling to get a good sense of how it would be set up, functions based on a dynamic spring system. The setup goes something along the lines of as follows:

A dynamic spring constraint is set between the joint of the rig system, and that of a particle. This will allow for the particle to slide about and jostle, while still being connected to the rig. From there, I would connect the stones I wish to have in place to the spring bound particle. via a group. From there, I would need to add another control to the stone for manual placement, should the stone stray too far from the course. I will need to test this potential system as well once time allows.

Progress Log for the week of October 27th, 2013

Not much to report on this week. Due to a recent job opportunity, I haven't had as much time to work on the golem or the pigeon. What little I did is as follows:

For the golem, more body structural formation via new vines placed and some joint placement tests. However, due to the abnormal limb sizes, I can't just mirror over joints, so I need to be cautious on how I orient them. I asked Jason Patnode in regards to how I could get an interactive system similar to that of the rock monster from Galaxy Quest. Though he demonstrated using a fractal texture and plugging that into the translation nodes of the stones, it doesn't quite match what I was aiming for. I asked another student in class, and they recommended using a rigid dynamic system, as it would be the only way to attain that free floating, yet interactive look I was aiming for. I'll have to make time to retry this system again, though I know that it will be very heavy on the system. Maybe I can bake in the animations of the stones interacting to help ease the load on the rig.

In terms of the pigeons, it has mostly been cleanup on the wings and neck area. Around Tuesaday, I received notes from the animators, requesting some more controls and deformation fixes. Stepping in to the class on Friday, there was a brief recap on said fixes, and some suggestions, as a scaling control system on the mouth, and a bending control on the top of the beak. Another suggestion, which I'm considering more than the others, is an IK/FK hybrid system for the neck, as well as a more detailed control over the feathers on the wings, as currently, the wings rotate based solely on the wrist and elbow. There was a request for feather bending, but I informed the animators that something like that is low on the priority list at this time.

Log for the weeks of October 7th through October 19th

7th - 12th

With the slow progression of the bird models I focused more efforts on building my golem.

The base structure itself now complete, I've begun to add the neck vines and create a small base plate inside the chest to have the back vines stem from. Most likely, I will modify it to look like the underside of a tree trunk, and place the energy stone at its center, then build outwards to help fill the rest of the chest.

I was introduced to a potential Ivy generator, in the hopes that it could serve to build the golem faster. However, upon obtaining the program, I came to learn that the geometry becomes too dense, and there is no direct control as to where the ivy flows to, rendering it a potential hazard. Were I to use it, it could potentially bog down the system and make the rig neigh unusable, as the poly count could potentially skyrocket.

As to curpigeon, things remained quiet for the bird models, so I continued to refine one of the human characters a little more before moving to other projects over the weekend.

20th - 27th

Curpigeon suddenly became the hot project for me, as I was asked to create a rig for a different character than I had been originally assigned. Monday turned into mostly joint relocation, as I duplicated the joint system from an earlier rig, and set them to the new character.

Tuesday brought about some more coverage on nCloth, which will become something I use in creating the stone collision system on my golem. However, I will need to create a new, lower resolution of the stones in order for it to work, as the current poly count would probably bee to high for it to function efficiently.

Wednesday became a class once again focused on the new pigeon character, placing controls and setting orientations. Nothing too extravagant, though there was talk between Jason, Hector(a fellow rigger on the project), and myself of potentially creating a universal rig. In order for this to work, though, we'd need to be sure that the geometry on the other five birds could work with the most average form of one of the overall 6 bird characters. Still, the main rig needed to be built, and that was my focus for the rest of the day.

Thursday became a mad dash of weight painting and some experiments regarding a broken chain hierarchy, or as a classmate had described it, a ribbon system. This proved quite useful when constructing the tendons on the wings, allowing for some better deformation than just letting the arm and elbow joints control the geometry. It is by no means a perfect solution, as there are still folds in the geometry, but with some controls added, it should work well. Adding a joint system for the feathers is proving more difficult though, but I may have a solution.

The lead rigger on the project sent me a tutorial on the rig setup for the human character faces, recommending that it could be used on the pigeon's face. However, I found it can function more effectively as a joint placement setup for the feather joints. The only real difference is that I would skin the controlling curves to the wing's joints to deform it. With locators acting as place holders, plus some orientation constraints coming from the outer most locators inwards, the joints effectively held place, and the feathers along with them. However, the setup is not ideal, as it causes a double transformation that I didn't have the time to work out. The lead rigger sent an example my way of something he whipped up, using a combination of parenting and orient constraints. With some mild modifications to the setup, I was able to get the feathers to track more accurately.

Log for the week of September 29th, 2013

While waiting for the final version of the pigeon models to be done, I was asked by the producers to help clean up two of the human rigs for the project. With those being more complicated that what I normally build, it took a bit to find my way around the inner workings to fix some of the issues. Beyond that, it consisted a great deal of weight painting.

Next up on the list is a bit of experimenting with fur in maya. I do not know if it will be particularly useful on my golem, but it doesn't mean I'll rule it out for aesthetic purposes.

Regarding the golem itself, I've completed the skull model and have blocked in more of the securing vines on the right leg, and build the back vine cover that will act as an anchor for the left arm.

Log of September 22nd - September 28th, 2013

While no particular advancements were made in terms of the dynamics systems on the golem, there has been more modeling progress. An initial attempt at reducing the poly count on the stones had some headway, it was thanks to the usage of a newer tool that Maya has incorporated recently into, called Modeling Toolkit. Specifically, a sub tool called the transform constraints, where in you can create a cube with a reasonable subdivision count, and snap the points to the surface of a selected geometry. This will definitely cut down the nasty high numbers of polys, as well as allow the rig to run more easily come time for setup.

In terms of the rest of the modeling, I've near finished the skull of the character, and have decided to restructure the vines of the body to better fit the design.creating the curves based on live geometry, then attaching the paint effects brush afterwards, allows for an easier placement, and can allow for a more interesting layout of the vines.

Meanwhile, on the curpigeon front, my initial experiment with the arm tendon has failed. I had thought of using a squash and stretch spline IK system, similar to another project I had worked on briefly, but the curve involved does not maintain its line of sight with the two controlling joints, bending and flexing about, rather than just compressing as I had hoped.

I'm going to try using an aim constraint system instead to help simplify things a bit more, though I have my doubts about it.

As an aside, I have volunteered to assist in working on some of the human characters for the project as well. I will try to detail what I can regarding the setup, though from what I gather, it'll be more of an insight for me on advanced rigs than me actually fixing things right out the gate.