Rodney

For those who have an iPad Disney is joining the growing number of organizations that are opening their vaults for a peek inside production. I posted briefly about Richard Williams's app that puts his video and text from "The Animation Survival Kit" elsewhere... The primary reason I post on this is that it seems to be a trend to repurpose older material for new audiences using new digital (interactive) technology. At it's core this seems to be a smart move on behalf of Disney because frankly, if they don't do it someone else will. Of particular interest to animators is that the various references from the "Principles of Animation" chapter in Frank and Ollie's book, "Disney's Illusion of Life" are collected and on display. While not everyone has an iPad... one could hope that it will be the beginning of a whole new generation of aspiring animators gaining access to hard to find reference and experiencing the behind the scenes process of classic Disney animation first hand. There's even a part of the app (a Workshop) where you can animate a CG Disney character in 3D (Vanellope from 'Wreck it Ralph"). https://itunes.apple.com/us/app/id632312737? I see it has 30,349,980 likes on iTunes... around 8 million at the app store. That's a lot of folks that like Disney animation.

Very nice! At first I thought we were looking at a real world sculpture/maquette! It's interesting that for the mascot contest I started... but abandoned... a character with four arms as well. I was in the process of adding two more arms (for a total of six) when I jettisoned the whole thing in favor of a simpler idea.

The old cloth (in the older TaoA:M) was not Simcloth so you are dealing with something completely different (a different type of dynamics) there. You can still use groups to isolate areas (usually origins and place that don't move) and leave dangling splines to help control cloth the flow and movement as well.

I was wondering why I always saw Marcos up and about the forum late into the night...

Looking good! It can help to think of hands as six cylinders connected to a wrist/arm. Then it is mostly a matter of capping off the ends of the finger cylinders and attaching the bases to the palm cylinder. There are a few different methodologies to connecting fingers and it's often best to experience the results first hand. I would suggest running through the following exercise a few times and throwing away the results each time. The goal being to get a feel for how many splines you need to connect the fingers to the palm. - Lathe a large cylinder of three sections (Scale this inward on one side either now or later in the exercise) - Lathe a small cylinder of three or more sections (how many sections this cylinder will aid in how realistic/cartoony your fingers will be) - Place small cylinder at end of large cylinder and duplicate three more times (these are the fingers) - Duplicate the small cylinder one more time and move it into place for the thumb - Connect the fingers together each with a single spline (divide each spline with a new Control Point by hitting the Y key) - Begin connecting the fingers to the palm (considering where you will be adding 5 point patches - Cap the ends of the fingers (to allow for detail, i.e. fingernails, only if necessary) - Move splines around until fully formed and refined. Alternately (for boots) add additional heel and grip-like soles to the bottom of the feet. For the boots that can be an even more straightforward approach and there are two primary methods (although there are others). Method 1: From Front View: Lathe a simple (three section in height) cylinder and deform the top of the cylinder to form a leg and the bottom to form a boot) Lathing with more cross sections will allow for more detail but it's is often better to lather a simpler cylinder and then subdivide that later via the SplitPatch plugin. Close in or cap the bottom of the boot and connect the top to the characters leg. Method 2: From Top View. Outline the profile of the foot and the from Front or Left/Right view extrude this shape upward (at least three times). Scale or Move splines/control points as necessary to refine the shape. Once in a generally acceptable position, it can help to select one cross section and hide the rest. Then from a Top View refine the shape to make it more symmetrical. The next time I'm in a position to record the screen I'll run through a quick demo of these basic techniques. Edit: It does occur to me that in the case of modeling boots it is generally better to create them as they would be made in the real world... component by component. Once each piece is created then they are placed together to form the boot. If you want a good starting point using this method there is nicely modeled boot in the A:M Exchange forum you could modify.

I'm liking his proportions thus far. It immediately suggests "Strong!".

I think I... mostly followed you there. I got to the point where the camera view and perspective view were about the same and then I figured I wasn't doing what you intended. Let me check here... By I assume you to mean a very slight movement. Just enough to get us out of camera view. Zooming out then get the camera in view in our perspective view. Since the mission is accomplished at this point... and the camera view and the perspective view are the same... I get confused. This is a healthy workaround because the camera then is always going to see what is in perspective view. Right? Or maybe no? Perhaps I'm just not tracking on what we are specifically looking for here. Back I go to run through that a few more times to make sure. Are you suggesting this methodology as the means to get a Camera to echo the Perspective view? Or is this research for exploring further? Or both? From my vantage point this is the feature that was requested. (In three steps!) Added: Then once the perspective and camera views are the same the user can move back and forth between standard camera settings and perspective view Although at that point it's best just to use the camera commands as that will be the perspective view too. From the Tech Ref:

Looking good so far Lloyd! Edit: I looked back up through this topic and that previous guy sure does have personality. There are enough characters in your movie that hopefully you can use that guy too. The earlier concept is immediately disarming (cute). This new one is considerably more menacing (stern). It'll be fun to see where you go with this.

Here's a generic camera's settings from a Chor (for comparison): A:M Choreography File Name=Camera1 End=0 0 100 Rotate=0 0 0 1 Length=100 Value=166 202 240 FocalLength=70 Value=Targa FileName= Value=FrameRange EndFrame=1:0 Value=TRUE TVSafe=Off And Cameras can be saved out as separate .CAM files and while I haven't yet confirmed this, their coordinates seem to be similarly stored: ProductVersion=17 Release=17.0 PC Name=Camera End=0 0 100 Rotate=0 0 0 1 Length=100 FileName=untitled.avi LastModifiedBy=Rodney FileInfoPos=248 If .CAM files do store coordinates then this might allow for a secondary approach in creating/saving/exporting a Camera with the current window's view settings. To the user success in this instance might look like this: Right click/Plugins/Wizards/New Camera (Current View). A dialogue box might then pop up with additional options for the user such as to save a .CAM file with Camera coordinate settings from the current window view. The default might be to have the new Camera open import from the saved .COM file into the current view.

A definite improvement! Nicely done.

Attached (for general reference) is the dialogue box that pops up when double clicking on the view settings in the lower right corner. It is this information that we can use to generate our automated camera view.

Well, as a shot across the bow of this thing... When a Project file is saved those View Settings are saved into the [WINDOWPLACEMENT] tags in a Project file after the closing [/FileInfo] tag: Thusly: (Example) A:M Project File Name=Perspective View 001 CurrentView=6 Mode=1 FrontView=4.62824 0 0 BackView=-1 0 0 LeftView=-1 0 0 RightView=-1 0 0 TopView=-1 0 0 BottomView=-1 0 0 BirdsEyeView=3.72257 0 -4.10523 43 0 27 WindowPosition=0 1 -1 -1 -8 -28 478 0 717 580 Name=Perspective View 002 ModelName=Perspective View 001 Time=0 CurrentView=6 Mode=4 FrontView=1.33949 -41.3619 -8.30078 BackView=-1 0 0 LeftView=-1 0 0 RightView=-1 0 0 TopView=-1 0 0 BottomView=-1 0 0 BirdsEyeView=0.437259 113.257 -119.164 -45 0 -35 WindowPosition=0 1 -1 -1 -1 -1 239 0 478 580 Name=Perspective View 003 Time=0 CurrentView=100 Mode=5 FrontView=0.538107 100.497 -92.8555 BackView=-1 0 0 LeftView=-1 0 0 RightView=-1 0 0 TopView=-1 0 0 BottomView=-1 0 0 BirdsEyeView=-1 0 0 30 0 30 WindowPosition=0 1 -1 -1 -1 -1 0 0 239 580 Perhaps there are other authorized view tags but thus far I see only three containers that store them: For the uninitiated, double clicking on the numbers down there will pull up the View Settings dialogue box. Disclaimer: I don't think typing settings into the dialogue box always works to change the active view. Aside: An external plugin that created a Camera at the location of the current Window View might need only to save a Project file to disk or memory, then locate and transfer the coordinates of the window to the newly created Camera. An internal plugin might be able to do something sleeker depending on where view settings are stored in disc cache or memory. In other words, in addition to the current 'New/Camera' option there might be a 'New/Camera (current view)' option that would transfer the current window view coordinates into the settings for the new Camera. The process for creating a Camera would then be like it is now but with a new option to automatically set the new camera to the current window view. To further explore what success might look like note that currently when creating a new Camera (in an Action) the Camera is placed at Mouse position with no other orientation copied from the window view. An extension of this might be to have hold down the SHIFT key while creating a new Camera which would tell A:M that the user desires to have the new Camera assume the Window's current view. Anticipated problem with the above: It is not entirely clear to me how we would get the Position to set the camera from the current view although it seems it could be derived from the Perspective (angle) and the Zoom of the current window setting view.

That was my first impression (i.e that it was a dream) but I know you as being too smart of a storyteller to go with the first (easy) idea. I'd post my thoughts/guesses... but sometimes that tends to ruin the whole process of discovery (especially for other people!). I'd say you've got some really good clues in this first sequence for anyone who has been an avid follower of your strip.

Way to set up a story! It'll be interesting to see you get to that point in the story given the impossibility of that scenario from so many angles. Henrietta's response perhaps being the most telling... Color me intrigued.

It's interesting to note that in the sheet of batman symbols you just posted they all have very pronounced spikes in the wings. The symbol you modeled from is more rounded. My memory says something similar was used in a character called 'The Patriot' which was meant to portray an eagle. Edit: I converted the symbols you posted to spline outlines in case you want to use any of those in the future (see attached model file). BatSymbols_Outlines_only.mdl

If you die... and it turns out you win... can the rest of us share your trophy/winnings?

Looking good! (It's good to see you back in action) Take the following with a large does of 'whatever'... these are just my initial thoughts as they came to me. The Batman chest symbol I haven't looked closely at the reference material and you may just be stuck with poor design to work with but to me the bat-emblem looks more like a bird or pterodactyl than a bat. Some minor refinement might be in order here... again, I didn't even look back at the reference material. The attached image is something of an oversimplification but I wanted to point out those areas of greater concern in the three quarter angle you posted. There are three areas that look off to me: The neck and shoulders The crown of the head The (mostly upper) jawline. I believe these may look much better from the front view but in the 3/4 view large areas of bone are either missing or (in the case of the forehead) could be smoothed out considerably. This is a helmet Bruce Wayne is wearing so it should not too tightly conform to his physical anatomy. Note that my overdrawing leans more toward the animated look rather than graphic novel drawing but it's always easier to add more detail than to take it away. Once the basic outline is in place you can adjust it as necessary. All this for what it is worth. Looking very good from this end!

Mr. Hubble would be proud.

I like! I may have a use for this very soon. Thanks John!

As the original poster hasn't clarified their request (assuming it was a request) it's rather hard to say. The original post was mostly undecipherable and posted at the end of an unrelated thread.

I'm just using what is already in A:M. I'll leave the feature requesting to folks that need new features.

Interesting. This discussion has led me to some new (and I think very useful) discoveries. Example: Underlying principle to remember: While we cannot key A:M's window view settings we can save them via a Project file which effectively saves/keyframes those views. Process: Create a few windows (in any view Modeling, Action, Chor or all of the above) Set lengths of shots as appropriate (easier to do in Actions and Chors) Tile your windows so that you have a view on each window (either horizontally or vertically) Move things around in each window or alter your view of them in the window. For keyed shots use Actions or Chors (Models intrinsically don't have movement) Render to Real Time via and save each of the windows views. For ease and organization it can help to call each view appropriately. Example: The Model might be named (Perspectview002Model001Still), the Action simply (Perspectiveview001MovingObjects) and the Chor (Perspectiveview003MovingCamera). Once again... the windows themselves are your production keyframes so make sure you save the Project with those views. If the windows are in your way simply minimize them. Bring all the various renders back into A:M for editing or import them into your favorite video editor. This workflow provides a very fast 'rapid protyping' or vis-dev methodology for setting up scenes and rendering from any current (perspective) view. It allows the use freefloating views and camera views simultaneously as required by the user. Note: We could render to final as well but there is just something cool about rendering the real time preview. I've been looking for a good excuse to use that. Additional Notes: The only way that I know to save a perspective view outside of creating that perspective through a camera is to save the window in a Project. As far as I can tell, if you close the window you lose that specific perspective view. So save the Project so that you can recall that view. For sharing perspective views from one Project to another I'll have to look closer at how Project Files save their window views. Added: Freakin' awesome. Every day I learn something new.

Every once in awhile we see a desire for a feature that at it's core is actually a request to take away some current feature or function. This is one of those cases. This seems to be largely a perception issue because if the default view was the Camera view, instead of the free-floating view that is not treated as a standard keyable rendering camera view the we would already have the functionality we are looking for. (Translation: We appear to have the feature identified but as it is currently don't prefer to use it) At its core what seems to be the underlying request (although not necessarly from Carol8) is to remove the current Bird's Eye View and force the user to operate from within a Camera view that just happens to function with an option to default to what is commonly known as Bird's Eye View, i.e. a 30 degree forward/30 degree right/30 degree downward view on any object(s) in frame. So, now at this point we do have to ask, "Why not just use a Camera view?". I assume the answer is the flexibility we currently enjoy in the default (non-camera) viewport... as Robert has mentioned... which we can render from but cannot key for rendering so as to have it behave as standard Camera views do. So again, I find myself wondering what success looks like. At it's core it seems we are suggesting that all views should be from a keyable camera. If this is the case then we run into one additional problem/issue in that a Model or Action does not (strictly speaking) have a Camera assigned to it. Similarly a Chor can have it's Camera removed. Thus, strictly speaking a renderable camera is not required for viewing... although it is for all but real-time viewing?) This then seems to be the 'Perspective' that we are trying to refine that of the interface's port view in all windows (Model, Action, Chor... and likely Materials and the like also). It seems to me the suggested workaround to all this is a means to simply copy the current Translation and Rotation (I don't think Scale has any relationship to Zoom) of the current view and paste/duplicate those settings into a Camera. Am I getting closer?

If I understood this better I think we could build a tailor-made solution (for instance creating a single Null that is just in front of the Camera view and then moving that around... with the Camera following that view) . In short, the goal seems to be more than just moving around freely in 3D space to get a view on an object and then keying that because we can already do that in a variety of ways. For those opposed to mouse movement there is always rolling the numbers to change the Translation and Rotation via the Properties. This keys the movement automatically too. Mouse movement is an ideal way to move through a scene via a Camera's view although I haven't had a mouse connected to my laptop for a long time so I can experiment with that currently. I've seen demonstrations where folks walk through scenes this way beautifully. I'm trying to imagine what success looks like but still haven't got that quite locked into view. At it's core the real bugbear of this issue seems to be that we have too many views to choose from... i.e. we need our view (whatever it is) to be a/the camera view.