Thursday, April 24, 2014

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.

Friday, April 4, 2014

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.