Rodney

Here's a quick demo of the process of manipulating the roll handles of the finger bones. Note that the attached mp4 file is same thing as the animated gif but at a larger resolution. I've included it because the gif animation is rather huge (especially for a gif file) and may load/play slowly too. I think perhaps folks will think me insane for posting a 12MB gif animation... but what can I say... I really like the format! **I didn't show in the video (and should have) that once the finger bone is selected it's just as easy if not easier to hit the R key to invoke the rotate manipulator and then simply rotate the bone using the rotation circle. Ah well... I'll save that for another 12MB gif animation. The reason it's generally easier to use Rotate Mode is that it can be really hard to grab that little rotate manipulator. Old habits die hard and I've always tended to grab those tiny roll handle manipulators. An added benefit to using the full rotator is that we can move the finger in all directions (to include curling without having to reselect the bone (after having selected the roll handle). I'll add a (smaller) animation to demo. Hand Manipulation with Roll Handles.mp4

Ha! Nice one John.

I had a feeling you might not be familiar with the rig and thought to create a few videos showing some basic operation but... haven't done it yet. The short answer is to grab the (yellow) roll handles of the finger bones and rotate those. Rotating one way will close the fingers while rotating the other will open them. (As I mentioned above... dropping the action I posted above onto the character will also clench the fist for you!)

I have no idea what he's saying but it can't be good...

For those that don't have such a thing or don't want to recreate it over and over again... here's a copyright image that can be dragged and dropped into a shot (using it as a Layer or patch image will work best but it can be used as a scaled rotoscope as well): (Just right click on the image and Save As)

Ah, the joys of TSM! One of the benefits to using the same rig is that the actions generally transfer quite well between models. Characters rigged with The Setup Machine (TSM) are no exception. As an example, this test of right hand articulation will work on any of the models rigged with TSM. Just drop the character into a Chor and apply the Action to the model. If looking for a specific pose of the hand adjust the ease until the proper pose is achieved. This hand grip/flex test was animated with Tar but applied to a hyena. RightHandClenchFlex.act

Well, it is an animation bootcamp so I'd say you are in the right place to do just that.

See the first post. (I'm limited in what info I can provide but It's an app related to medical education) I'm inclined to use Unity (especially since their latest release!) but one of the more recent responses from a lead asked, "Does it have to be Unity?" I haven't responded to that query yet but while it doesn't have to be any particular software but it does need to be 'something' or else the project won't go anywhere.

The latest news... The committee didn't green light the app so that avenue is out. The team is considering other options. For my part I just press on as before with a plan to adapt as necessary. As some the principles will be offline due to other commitments no deadlines loom large on this project so my focus remains on brainstorming, conceptualizing, research and development.

John got me interested in testing out a few ideas using A:M's flocking feature and along the way I decided to test some of A:M's newer GPU accelerated Postprocess Effects (like Blur) too.

I delayed posting this as an alternative because it's not a standard approach and the pdf file format was your focus. As an alternative, self contained file, you may want to investigate Tiddlywiki (www.tiddlywiki.com) While embedding images, audio etc. increases the filesize dramatically it can be done and... like any html file resources can be externally linked. For those that haven't checked it out in a few years it much improved and actively being developed. Worth checking out: http://tiddlywiki.com/#Features If Tiddlywiki looks a bit complex it's both simple and complex. Simple if you just want to enter your information... and complex if you want to dig deeply under the hood and customize it to meet specific looks or requirements.

It's great to see you back at this again Dan! Nice render!

Here's a quick test of Crowd Flocking... (not related to my project but a quick test to remind myself of the various settings available in flocking. I was actually thinking of Gerry Mooney's 'Bugbots' while making this. Everything except the text is flocked)

That's the time honored number one reason for flocking not to work. Flocking is working here in v18k (with particles on). I am so glad you had this problem though John because it reminded me that flocking is a great option in something I'm working on now.

Mike Hough (the author of the AM2RIB and AM2RIB2 plugins) stated he was frustrated with (i.e. didn't like) the RIB format. His effort was back in the 1999/2000 timeframe (before the current HXT plugin format). Nicolas Yue (I think that's how you spell his name) also wrote a RIB exporter called MasterRIB. I don't know anything about that plugin. Added: I see that Nicolas is or at least fairly recently was involved in some RIB/github activity. Also of possible interest to you... regarding the RIB format it has been said (by PIXAR): *emphasis added (Note that I assume the reference is to OpenSubdiv 3.0 (currently in Beta release)

I'm curious if there is anyone that frequents the forum that is familiar with the command line use of Renderman. It seems to me that might be the way forward with A:M and Renderman. Added: Here's a little information on using the standalone Renderman (which doesn't need Maya, Katana or any plugin): https://community.renderman.pixar.com/article/293/using-renderman-without-maya.html Aside: Way back in the day A:M use to have a RIB exporter... While it's not a high priority to use Renderman I've started the process of installing it. Let's see if there is anyone tenacious/stubborn enough to beat me to the first A:M/Renderman rendering. (Using the Maya or Katana plugin as a conduit doesn't count!) Update: Installed (Rendering with the command line will likely require installation/launching of 'it'. For those taking notes: It can be run via plugin or command line.

Need a few posters on those walls! Hmmm... and don't forget one of those 'sharps' containers for collecting needles and such. Here are some examples of wall mounted containers: LINK

I recommend Creative Talent Network (CTN) which will be November 20-22. It's largely comic book artists, animators and such which makes it a prime place to exhibit Animation:Master because A:M is more attuned to these folks than those whose focus is more toward technical proficiency. The demos I saw before by Hash Inc at SIGGRAPH and what I assume James et al. still present is ideal for this type of event where creative types are sharing knowledge of classical approaches to animation but have a keen interest in computer animation. CTN is still a small and cozy gathering in comparison to many other events but it's also a rare opportunity for talented folks to meet with highly skilled folks that one would never think they could ever meet in person. It's also where a lot of young students who haven't yet been jaded by 'industry standards' seek ways to express their creativity in their own unique way. If Hash Inc will be there I will redouble my efforts to be there as well. Here's a link: http://ctnanimationexpo.com/axFloorPlans.php#prettyPhoto The timing is right because exhibitor registration begins in April.

As A:M doesn't have macros I assume you refer here to a text editor like Notepad ++? And DOH! I forgot a very important step in my setup of what I'll call the Grid Alignment Method (GAM) above: 1. Establish your Model/mesh at a scale where the grid (of the Model space) most accurately places the majority of Control Points at or on a grid intersection 2. Establish your Bones at the same or similar scale 3. Select all CPs, Right Click and Snap to Grid 4. Select a Bone, Right Clock and Snap to Grid (Note that we cannot multiple select Bones so another approach may be necessary) When creating Bones the Snap Manipulator to Grid icon could be toggled on to ensure all Bone origins are already at an intersection of the grid. ADDED: In either Model Mode or Bones Mode, Right Click and select Auto Assign Bones to connect Bones to CPs.

I'm trying to imagine what success might look like so bear with me here. Of course there is solving the process of matching Bones to CPs but there is also the matter of what that would accomplish that couldn't be accomplished in some better way. But... moving on... I note the following: It appears the minimum required for a CP to be assigned to a Group is the following entry in the Model: (Scroll down in window to see all code) [Model] Name=CP1 1 Pivot=-13.3138 0 0 Name=CP2 2 Pivot=14.8886 -0.0715798 0 [/Model] And for the Group Constraint it gets a bit more complicated but we need it's corresponding Bone (already existing in a/the Model) to have the following (in an Action): (Scroll down in window to see all code) [Action] MatchName=Bones MatchName=Bone1 GroupTarget=..|..|Groups|CP1 MatchName=Rotate MatchName=X 1 0 -2.71051e-018 MatchName=Y 1 0 5.55112e-015 MatchName=Z 1 0 0 MatchName=W 1 0 100 MatchName=Translate.X 1 0 0 MatchName=Translate.Y 1 0 0 MatchName=Translate.Z 1 0 -0.000134537 [/Action] The Action may not require all these various channels (we'd have to test) but that is what is created in the natural order of activating the Group constraint. The critical part of the assignment being: /// The beginning of the constraint container GroupTarget=..|..|Groups|CP1 /// GroupTarget= followed by the location and name of the Group to connect to which we can assume could be same name for easy identification ... /// Additional Orientation information as required** /// The end of the constraint container ** While I'm sure this ommission (and direct manipulation of the file) is not recommended my tests indicate the orientation data can be omitted and A:M will resolve the constraint automatically. Somewhat related... This process of creating Bones and attaching (or placing) them at CPs is not unlike the creation of Skydome/Light Rigs where an array of Lights (basically the same as Bones in A:M) is created. The primary addition is that of 'parenting' the Bones/Lights to specific CPs (in this case using the Group Constraint. Note that in the above I haven't moved on to look at the orientation and length of the Bone that would place the Bone at a specific location. In Robert's video he shows how to get the ends of the Bones at the next CPs (By using the base of the next Bone in the chain) but I would imagine that where the Bone points could be any number of different locations. Alternately, the bases of every Bone might be desired to be all be at the same location while their tips/ends might be where individual CPs are located. And another observation... In some cases a workflow helper to match Bone locations to CPS might be as simple as this: 1. Establish your Model/mesh at a scale where the grid (of the Model space) most accurately places the majority of Control Points at or on a grid intersection 2. Establish your Bones at the same or similar scale 3. Select all CPs, Right Click and Snap to Grid 4. Select a Bone, Right Clock and Snap to Grid (Note that we cannot multiple select Bones so another approach may be necessary) When creating Bones the Snap Manipulator to Grid icon could be toggled on to ensure all Bone origins are already at an intersection of the grid. Or something like that... I'd be curious to see a mockup of what success might look like for even a simple case. I can thing of one: connecting all of the CPs of a mouth to a ring of Bones to better facilitate dialogue/articulation

I'll guess the primary reason is that the z-axis-position option isn't in the TextureGrid Wizard. We'll have to wait for the GridImages Wizard's release for that. The TextureGrid WIzard only has X and Z offset (and lacks the option to automatically drop the Models into the Chor as well). I should say though that stacking of images on patches is as simple as a Right Click followed by an Add Image. The patch image approach is inferior to these new grid decals in several ways (no x-axis adjustment of the images and images set to cookie cut cut through all of the images on the stack. With this new Wizard we can go in and adjust the positioning of the images via the Decal Editor which is a very nice way to make modifications. I'll also add that v18k's new ability to bake patch images (into decals) is yet another nice way to quickly combine imagery into a single decal (or layering of decals if you count the various other surface properties; transparency, specular, bump, etc.) .

I will assume that's what Serg means until he clarifies. It's a rare bird who takes advantage of A:M's Layers. I don't think a lot of users even know what a Layer (in A:M terms) means. At any rate I don't think Serg is referring to A:M's Layers. Although its a toss up... perhaps he is. Having the ability to stack/layer images above each other (ala patch images) would indeed be useful as that would allow us to immediate composite a series or sequence of images together. Currently that is a manual process adding images to images via decal or patch images. The downside of 'stacking' is that allowances have to be made for image formats that don't have an alpha channel. I suppose the user could be left to figure that out for themselves but folks tend to have a tough time grasping the concept of alpha channels. I would probably refer to the stacking of images in one place over the top of each other as 'compositing' because that'd be what the final result would be; a composited image of all the stacked imagery. If using a camera the effect might be referred to a 'multiplane'.

Nice one Douglas. I'm really liking your economy of spline on this last one. Added: You are running up against something I recently did with a cartoony character in that I like the look of him from a side view but the front view didn't seem to capture the same character. Not that I know in your case but the front view of your last head model from the front view seems a bit the same in that it doesn't quite seem to capture the character represented in the profile/side view. Manybe it's the width of the jaw? The sameness of distance between features? Not sure. I do really like that profile though!

Wow. I can't recall when an update to A:M was as immediately useful as this one has been already. Specifically the Camera View addition, Textured Grid (haven't delved deeply here yet but I will soon) and.... better rendering Boolean cutters! And I haven't had a chance to look yet at some of the others but I know the SSS speedup will be appreciated and rendering from Perspective view is something I've just committed to using for a project. Very nice! Edit: And oh my goodness... I completely skipped over the lineitem for ' 6311: Patch Images do not Bake' Thank you!

I'm guessing that would be a whole new feature as Layers use patch images instead of decals. Or... are you using the term layers in the sense of 'stacking'.