Rodney

I would love to have a copy of the current SDK myself. Steffen Gross is the keeper of the SDK and I believe he maintains a more recent (personal) update of the SDK tailored to his coding practices that he shares upon request. The last official public release SDK is still v13. UPDATE: Since posting this the v18 SDK has been released! Go get it! Animation Master SDK (v18)

Happy Birthday Sebastian! May you always rock the animation scene with your stretchable cartoony characters.

It's great to see you again Arthur. You said: It's in your profile which you can edit via buttons at the top right of the forum but for now I've changed it for you. As for a FBX plugin... lots of folks would love to have such a converter. I for one would just like to know more about using Visual Studio with A:M. I have a few projects I'm researching but its going to take awhile to get educated. Welcome back!

Good point Nancy. I'd have to check what came before again as this last clip is just the tail end of the longer sequence Simon posted before where the character contemplates/ponders for an extended period of time before crouching down to lift the bag. A suggestion back then was to lift one knee off the ground to convey the effort he'll need to lift the bag as well as break up the symmetry/twinning. I generally suggest something once and move on so it's good when others validate these core concerns. Added: Nice quick take Mark! I will say that starting from both knees down with twinning of the legs/etc. on the way up with a robot is considerably more realistic than it would be with a human. A robot might be able to get away with it. Edit: It looks like I was the one that missed a few posts. I'm behind by a few briefs!

Hey, I like that. I don't think I have anything to suggest to... Okay, since this is feedback I'll postulate one thing. If the bag squashes (spreads out) just a little more at the base when it hits the floor my inner crit will be silenced and complete. Perhaps not so much on initial impact but in its final resting place. Kind of a ka-FLUMP to end the scene where the first beat is the first impact and the second the bag is exactly back in it's original place (so you've got a potential for a looping cycle here... very interesting!). Of course, to have it squash too much would suggest it might not over in the first place. I'm pretty happy with that one. But more importantly, what do you think?

Nice. I like! Especially that monkey astonaut guy and the octopus.... cool designs. I edited/repaired your youtube Bulletin Board (BB) code in your post. When posting from youtube the basic code is: [youtube]the video's code only... without the url[/youtube] In your case it will look like: [youtube]lSZqfKnCRAU[/youtube] It's always good to add the direct link as you've done with the full URL just in case the BB code doesn't work. Edit: I see Robert unfixed my fix. I think all three of us were trying to repair simultaneously so... adjusted again.

Thanks for more precise pointing to the reference Nancy. Much appreciated! Here is an excellent (and short) primer on Center of Gravity from the same author behind http://animationphysics.org/ (Alejandro Garcia): zjhRxeR9GXo

Ooooo. Very nice. Despite her pretty looks she is nicely designed to create a feeling of unease. I suppose what I'm trying to say is that you've expertly hinted at the girl's history by suggesting she has not always looked this way.

It's looking a bit snappier now. Perhaps that is due to cutting those extra seconds out of the sequence. I really stared at (replayed that is) the very end of the sequence where the bag leaves his hands. Something is off there but I can't quite put my finger on it. I'll take a stab at describing it and maybe the lightbulb will go on for me... There is an interesting dynamic going on in your scene because the Center of Gravity (COG) changes as the guy lifts the bag. In short, I believe the COG is lower and farter to the right that where you have it represented, particularly at the time he loses control of the bag. Right now it's as if the guy is flipping the bag up and outward as he loses control of it. Outward is okay. I could see that but upward is problematic because of the weight which you've previously established in the scene. It would be interesting to see where you might draw a series of dots on each frame (or every few frames) to show us where you think the COG is throughout. As with most things there are several approaches you could take to resolve this depending on what you want to finesse. Less work would be to reroute the trajectory of the bag downward earlier. Here the focus would be on weight dropping immediately as he loses control of the bag. Note that this would actually push his hands/arms downward because he is (trying to) lift the bag. His upper arms and body were in control of the majority of the weight but as soon as it shifts forward the forearms can no longer sustain that lift and they go downward even as the upper arm is going up. This is yet another one of those Opposing Directions opportunities in that he is pushing with a force upward but the force (weight) of the bag is going down. I should draw this over your imagery because I'm probably not conveying this correctly. I see that you've got a nice lean backward and the upper arms go upward as well... that works! Keep that! I am of the opinion that the forearms however should be advancing downward under the weight of that really heavy bag. Now there is a second approach that might allow for more lateral movement of the bag (such as you've got it now) and that is if the guy swings back and forth a few times in an attempt to keep balance. If nothing else it would provide a little motivation for the weight of the bag to move out and upward as it is now. There are some really nice tutorials on Center of Gravity online and they are definitely worth checking out: Here's one that doesn't quite catch what I'm after but it comes close: http://animationphysics.org/wp-content/upl...nceTutorial.pdf There are lots of nice examples over at http://animationphysics.org/.

This is a very interesting aspect of USD. On the one hand we see binary files with all the associated speed and compactness and on the other we retain access to the file in a fully human readable form. This is a good omen. OpenEXR has proven itself a worthy format and yet the surface has barely been scratched on its usefulness.

Interesting. My initial thoughts: He should keep one knee down on the ground when beginning to move upward. Think in terms of resistance and push/pull and wait for it... an important principle of animation; Opposing Directions. As the bag is going up (being lifted) his bulk of his effort/weight is going down (if the weight were enough to exceed the tolerance of the floor this force would penetrate the ground). Imagine a wood floorboard here and this might begin to make sense as that floor would naturally bend as it reacts to the weight. As this floor is more solid this give the guy the resistance he needs to lift the weight off the ground. But again... this is important... in order for the bag to go up the guys weight must go down. Keeping his knee in place is one thing you can use to show that he is stable and balanced and ready to continue to lift the bag off the ground. My primary concern as it is right now is that it is very slow with little texture of timing throughout. Think here in terms of Slow/Fast. Steps/Beats 1. Slow. Character takes a moment or two to contempt picking up the bag (2 beats... more if character's performance antic is exaggerated for entertainment value) 2. Fast. Bingo! With his decision made he moves immediately into action (1 beat to lean down and another to initially grab the bag) 3. Slow. Character adjusts to account for the actual weight of the bag (Note that here he is bridging the gap between what he thought he was going to do with an imaginary bag in Step 1 and what reality dictates now that he has contacted the 'real' bag. 4. Fast. Character launches upward using his upper body first until the free movement is delayed or stopped by the actual weight of the bag (this is where the chain reaction of the human body (Successive Breaking of Joints) is observed and it's why at least one knee might still be on the ground) 5. Slow. Character is now fully lifting the weight of the bag. 6. Fast. I don't see this in your current shot but the character's goal is to move or get rid of that that $#&%! heavy bag! 7. Slow. Recovery phase as he accomplishes (or does not accomplish) his task. Added: There is more than one way to approach weight and your shot suggests a shortcut in that if you consider breaking up the Symmetry of his pose (legs and arms... entire body... twinning/mirroring themselves) then the rest of the character's posturing begins to work itself out. At any rate... try to get some texture of slow and fast movement into the animation. Hope that makes sense.

I was going to suggest tilting the camera but see that Robert has already got that suggestion into the mix. General aside: If it's an option and you are going for a more stylized look (in animation/movement) you might consider adding the spaceship itself directly in front and constrained to the camera ala the view of a first person shooter. This thought occurred to me when I started to contemplate how to suggest scale during the approach to Jupiter's moon. If the spaceship stays the same size as the camera moves forward that would supply that sense of scale... suggesting these objects are huge. I suspect you are going for a view outside the spaceship window so... no spaceship needed... thus my thoughts for aside #2: Aside #2: You could also throw in some space dust/distortion by placing a moving image that is almost entirely transparent just in front of the camera. My initial thought here would be to create a cube and fill it with a noisy material that is entirely grayscale. The black would suggest space particles the viewer is traveling through. If opting for adding the spaceship the spaceship could actually proceed through this layer (perhaps animate the materials so they accelerate toward the camera). This to suggest the considerable depth of space traveled between Titan and the viewer. This last one is mostly post work so don't let it distract you. Looking good!

In considering the various approaches (and there are many) it occurs to me that you might start by simply taking one frame from a key scene (or one from each major sequence) and manipulate that in photoshop or other graphics program to give yourself a target If you just start lighting without a given goal you'll end up exploring (i.e. wasting a lot of time). It will help also if there is an example of the basic style of rendering/lighting that you can use in the short term to calibrate your eye. Added: a failed attempt to decal the ground from camera view...

One possibility... *after rendering to color* convert the entire thing to grayscale. (Using A:M's Tink Post Effect you can use A:M Composite (or the post effect dropped onto a Camera) to quickly do that) Add noise or film grain (also a Post Effect) but it can also just be a patch/image placed in front of the camera as necessary. This will give the short a early B&W movie/TV feel. If you have more time then you could subtley add in a second color pass that tints the B&W with color. This would suggest someone has taken the time to color an old B&W film. Concerning the lighting... I'm a fan of deleting all the default lights and starting from scratch (this is a bit scary at first because initially everything will be black) First light the most important part of the scene (where you want the audiences eye). Then add more light to fill in secondary objects. (here consider the true sources of any 'in scene' light.... some may not need to be actually lit... it may be sufficient to simply color them white) Add negative lights if necessary to decrease light in areas you need to be darker (be careful here as negative color shadows can result from using negative lights) Finally, after saving to a safe place go in and subtley adjust and enhance the lights. Where possible try to think only in terms of black and white (and grayscale). Afterwords add the color. (like my earlier suggestion to composite color over B&W you can do the same thing with coloring of lights to enhance the mood, create temperature differences and further direct the viewers eye.) My 2 cents. Good luck!

Very nice Steve, I like! I was doodling hands a month or so ago (one of my five minute exercises) and they truly pale in comparison to that!

A subject near and dear to my heart assuming I understand your request.... Unfortnuately there is no direct method currently to achieve what you are after although there are several alternatives. The most promising in the short term is to assign or associate an external bitmap to the file and then have your operating system use that as a thumbnail or icon. If it is the A:M file's internal icon system you wish to access then that is something we would need to code as a utility/program. If I understood more about the code I could do it but several pieces of information still elude me. Here is an old topic where Yves Poissant discusses A:M files internal icon format: http://www.hash.com/forums/index.php?showtopic=9636 Here is the important part (Yves' response):

Hear! Hear! Herzlichen Glückwunsch zum Geburtstag! Isn't yoda something like... thousands of years old... (Research reveals something of a debate: either just before 900, slightly over 900 or exactly 900 years old.)

Here's my very rough example... (with apologies for the low quality all the dead time that could have been edited out) I'd comment more but am heading out the door. Did I misunderstand your goal? Snap2SurfaceInPose.mp4

This response is from one of the developers to a query about obtaining more information about USD: In the USAF I often asked my troops what they considered to be short and long term (naturally I would be following up with them on their plans for the mid term) and it seems clear that PIXAR's USD approach fills the need for their longer term goals (no surprise there).* Information may be slow to come and that in and of itself provides an opportunity to climb on board while few people have a clear view of the final outcome. This won't apply to everyone but consider... leveraging this information will be useful if you ever plan to work for or with PIXAR. Lot's of folks dream of working for PIXAR but few take the steps necessary to get there. If that is your plan... get into it! As for USD, it's likely to be a slow mover in the short term as PIXAR considers how to best leverage USD with respect to short and long term goals. This translates to an opportunity for some to nibble at easily digestible information (and learn from the mistakes made by early adopters). Regardless of what you do with the information PIXAR provides, it will very likely strengthen your personal workflow *But note, PIXAR isn't about to reveal all of their goals. They will surely be keeping the most important of those Close Hold.

Much of this is predicated on current coding practices which are still prompt/text based. It will be interesting to see what future generations bring to the table with visual programming that automates underlying interfaces. Still I don't think we'll be seeing the end of prompt based coding any time soon as there is always a way to optimize something with ones and zeroes. The current trend into immediately being able to test/validate code live, as it's typed in, is very encouraging. A:M itself is an excellent example... perhaps the premiere example... of 'code-less programming' in how it allows the creation of programs (derivatives, utilities, stories, etc. etc.) without needing to expose the user to command prompts and scripts. It's rather amazing. There were several themes that have been recurring to me since reading through some of the USD documentation. The first was that of layering (non-destructive editing) as mentioned in my earlier post. (I didn't use those terms but it's there) The second is that of Articulation/Rigging which PIXAR acknowledges as too 'non-standard' to standardize in USD. Their solution is a logical one... layer the rigging data over the geometry and shading while referencing the data for use in it's intended proprietary system. Yet another is USD's approach to variations. Now this will be a oversimplification but A:M's Action Objects is a clear example of this and a very effective one at that. In A:M we are only a few drag and drops away from referencing multiple model variations based on the same base. Note that I consider this completely distinct from saving out a model as a new model as it then becomes a new derivative base has freed itself of any internal reference to the original base.). I say all this because there is a tendency for some to read about a product and immediately think "Boy, I sure with A:M had that." when in fact it's been available to them in A:M for years. While I'm sure there is a lot of work involved... there surely must also be a lot of fun to be had there. Not to mention the sense of accomplishment when a plan finally comes together.

The latest trend is a bit different in that it doesn't try to convert resources but to introduce and/or leverage open source standards and to promote, to the maximum extent possible, systems that can contain resources of any type (compatible or otherwise)*. Of course there is a limit to this and some standard must be targeted to ensure compatibility. The downside of this is that we are all in our own ways very proprietary creatures and we tend to create resources that are also proprietary. But some of this is necessary to encourage innovation. The prime example of this is where new technology is released broadly but because plugins are specifically developed only for certain platforms. But this also in reasonable because we wouldn't expect anyone to freely develop for a competitor's platform. It is this last development element presents a real challenge to open source interchange as many new propriety states can spring into existence because the developers lack resources and time which prevents full exploration and communication within an open system. But this is also the realm of innovation where folks get to invent things over and over again (hopefully) to the benefit of all. *This compatibility issue includes a critical element of toleration that is counter-intuitive to us because we see anything incompatible, unproven and not in line with our own personal or collective interests as wasteful and bad. This is complicated by the fact that closed systems tend to be well known, optimized, reliable and fast. PIXAR's approach here certainly isn't free of selfish ambition. They would surely prefer a proprietary solution if it was securely owned and licensed by PIXAR. But history has proven that technology is synonymous with evolving standards and rather ironically, PIXAR is too big and proprietary themselves to innovate 'everything' themselves. There is an interesting note two regarding USD that suggests PIXAR is committed to open source solutions at least in this specific case; their identification of the back end of USD being supported by Open Berkeley Database (OBD) which, they state, has potential licensing issues. From my perspective this appears to be a move to exert some pressure on the license holder(s) to release rights that will in turn keep PIXAR's own costs manageable and increase their profit margin. The alternative (and their negotiating leverage) is that they might otherwise be required to move to another more open standard. There are some elements of USD that echo some plans from five or so years ago to enhance A:M's internal interchange and file handling. The move to XML compatible file format was an early move toward that. The primary difference there and with PIXAR's USD is largely a matter of scale. Of importance, the average A:M User already has this basic all-in-one (in-A:M) access to workflow and interchangeability.

This is largely unrelated what is needed by the average A:M Users but I found some of the information about USD interesting for a number of reasons. The site provides insight into where PIXAR is heading and why some popular tech (such as Alembic) currently isn't sufficient to get them where they want to be. For the A:M User with an eye (and patience) for technical explorations much can be gleaned to spice up the ol' workflow or if nothing else to capture the imagination. From the site: http://graphics.pixar.com/usd/

Nice job Jason!

Simon recently posted a link to an animated advertisement called "The Bear and the Hare" and this post relates closely to that... as Aaron Blaise was a key player in the making of that two minute ad. Aaron Blaise has now released #9 in his series of Art Tips and it's a decidedly different and candid one that speaks to the heart of the artist. In Art Tip #9 Persistence, Aaron discusses some of the trials he's gone through, to include the loss of his wife to breast cancer, and how life's interesting twists and turns has brought him to where he is today. The focus of the tip is to persist even when times get tough... "the sun will still come up tomorrow" so "hang in there!" Here is what Aaron had to say about the ad in a recent interview at Cartoon Brew: Note that the last four to five minutes is the playing of 'the making of' and the ad (The Bear and the Hare) itself. Hbcdn8QXcts

Very nice! That's a great way to get realistic reflections! This is a nice example of how traditional animation can be enhanced and modified leveraging modern technology.