Rodney

Nice test! One thing to consider when using the AI and SVG importers and going for precision is importing only the outline and then working from that. The reason for this is that the importers don't know where to optimally place CPs or connect splines**. By working with the outline we can add and move CPs around, extrude and finish the model optimally. An additional reason working from the outline can be ideal is that the drawing brought into A:M via the plugin is in 2D so it can't anticipate how that will project into depth (3D). So the outline gives the precision of the shape from one dimension and the artist provides the rest. Added: An alternative would be to bring in outlines from each view (top, bottom, right, left, front and back) but that makes for a whole lot of work prior to import that can likely be done just as easy if not easier inside of A:M as modelers work their magic.. The outline can be further optimized using the Resample Spline plugin but CPs are evenly spaced using the plugin and that can result in rounded corners that must be manually adjusted or inbetweened by inserting a CP or adjusting the spline's bias. **I should have said the importer doesn't know how to change the location of CPs to optimize the resulting geometry. It simply works with the location of the CPs from the bezier curves which may or may not be placed optimally. .

Wow. You've been busy! I've been wondering where and what you've been up to of late. Go John!

Yes, indeed. That is the secret to 'no frills' or 'quick' rigging; rig only what needs to be moved/animated. The (primary) downside to this approach is that the end result is not (generally) an all purpose rig that can be put into service of animation on demand. This approach would be geared more toward scenarios where what will occur in the scene is established. As such, if the scene calls for a shoulder and head shot not much else needs to be rigged. In the rigging process of Papa Bear I first thought about core movements/articulations... what is absolutely necessary. This breaks down to: Placement of the object/character This can normally be done by manipulating the Model itself but I must confess that I like objects/characters within a Model to be independent of that 'space'. In this way, two characters could inhabit that same space... becoming one 'model' and the rig would be build to order with consideration of interaction between the two 'characters'. This then leads to... Orientation of the object/character Again, I'd say this can be best approached by having all geometry belong to a root bone that is not the one assigned to the Model itself (that's the official 'root' in the strictest sense of the term). If all (or most) that is required is for the character to do is slide across the ground, spin or somesuch it might be sufficient to pose a character and then use the static mesh sans all the bones except what is necessary. The extra 'weight' of unnecessary rigging and poses can then be avoided. Then to keep the performance alive, consider what else must have life in the scene... eyes are usually a good bet but follow through and overlap should also be considered. Those are the two primary things. This does then beg the question of how to best proceed where there is limited rigging in a character As a suggestion I'd say that, like its real world counter parts, the bones define the gross/basic movement but then the geometry (read: muscles and flesh) is driven/influenced by that. So a jaw might move down but the corners of the mouth move up to form a toothy grin and to get at that Opposing Action that reads to the viewer so well as the brain detects the changing of shapes. The downside is definitely that we can lose a major strength of fully rigged and articulate characters which is re-usability. BUT many animators flee from the very thought of canned actions applied to characters. This conundrum places us in a position of relying on rigs that can't meet our requirements for a shot or conversely, can't be reused/re-purposed effectively. Bottom line for me at my naive stage of understanding is determining what needs to be animated. As I was rigging Papa Bear I constantly tested to see what the results of adding a new Bone... and where it was placed (i.e. child/parent hierarchy) that I found myself learning more about the personality of the character. This guy's ears will need to move to capture a particular look. His tongue will need to be seen at times... better model and rig that. He doesn't need to be holding onto his fish pole yet... so additional dexterity in his fingers can wait. Etc. Etc. This is a pretty nice way of prioritizing whereas there can almost too much to take in and consider with a fully articulated rig. It should go without saying but I'll say it anyway; quick rigging in this fashion lends itself much more to still imagery than to fully articulated animation. And this would apply even more to gaming where a character needs to be ideally posed from all vantage points unlike where all shots will be seen from a camera's perspective which allows for many hidden cheats. Fun stuff rigging! P.S. I need to share my modified mesh with you but I don't want to distract you from the gains you've already made. I took a lot of splines out of the head and gave the shirt thickness because those two areas grabbed my attention. The pics above are rendered with the modified head but I changed the shirt later.

Impressive.

Fun!

I was playing with transparent patches and light and noticed how nice the colors where transferred into the shadows and found myself wondering, "Is this something new in v19?". Launching v18 and running through the same project I observed the same results. No, nothing new here. So, why is it that I've not been using this 'feature' before? Aside: One of the reasons I looked forward to the 'Duplicate' option arriving in v19 was to assist with lighting. The idea being to set up a light in an ideal location and quickly be able to duplicate that light in the same location but with other settings. For example, one light might effect the surface of objects in the scene while the duplicate only casts shadows. Another example, having the duplicated light(s) just slightly offset from the original. Other examples abound.

Random duckbox. Can you believe this is my first time ever modeling a duckbox? Testing SVG import (mostly).

I can't check A:M Reports at the moment but I think this is a known issue that may have been repaired (in v19). In the interim, if you require that feature, you might install a previous release to get at that functionality.

Thanks John, I'm having fun and testing out things as I go. This (below) was mostly just to test out the Duplicate feature in v19. It's one of those features that isn't a 'wow, look at that' feature but is one that is actually useful. Also, testing no lights to get that flat shaded look.

Have been investigating the possibilities.... This mod uses what I'd call a 'no frills' or 'quick' rig. In other words, I'm not sure anyone else but me would call it a rig.

Looking good!

Q: What happens when we join four cubes together? A: That depends on how you set them up. Random boolean (specified) cutter:

Random surface bake tests...

I put splines in the mouth to accommodate the first part (upper lip) I think the splines might be adequate for the jowls (although I hesitate to commit to that). After staging the presentation showing the bones I regretted not using a slightly different angle that could account for more of the upper lip as it rests under the snout. My thought here is that some key poses would need to be set to easily dial up those facial expressions that emote enough to capture that feeling of a mind inside the character (usually doing something slightly different than what their outer performance suggests). You definitely wouldn't want to manually animate splines/CPs every time you wanted to strike those poses. I may start afresh and try to get the model looking a bit more like Humphrey/Papa Bear. Alternately (additionally?), perhaps you can share a current version of Papa Bear and I can explore that. I think I have an early version of Papa Bear but you've surely changed him since that.

I'm sure there is but I don't know where that would be. Perhaps you can PM Will and he can clarify. Added: This underscores some of the issues with 'documentation'. No matter the effort, quality or content... it is never quite what we need.

More randomness... (I don't want to let a day go by without splining something in A:M) This started as a quick doodle of making flat anime-style eyes. The eyes needed a face... The face needed a body... The body needed an environment... And this strange slugworm thingy appeared shortly thereafter. In these explorations I try to include things I haven't done before or tried in a while. Those include: Experiments with mixing of color, light and transparency. Playing with Mist. Bias tweaking. (well I always use that but usually not in negative values) And no, I have no idea how this guy moves across the ground with a shell on the ground. Some kind of magic drawing power? I did say these were random!

I couldn't see if you'd found Will Sutton's reference/video so just in case: xhttps://www.youtube.com/watch?v=gkBmYlRwP_8&feature=youtu.be Make sure you set aside some quality time as he goes step by step through the demonstration.

I'm not a Mac user but... historically... graphics problems I've had on the PC seem to relate to Nvidia cards as well. I say 'historically' because it has been many years since I've had an Nvidia card. Almost every system I have had since v13 timeframe has had intel graphics. The head scratching part for me is that others report they prefer Nvidea cards and avoid intel graphics... the opposite of my experience. Off topic: Where the heck is Nancy?!?

Nicely done.

Exploration. Snout as child of Head. Jaw as child of Snout. Orient Head. Aim Snout. Articulate Jaw. Pose Lips. This guy turned into a dog (literally and figuratively?) when I decided your character would likely need to whistle. Because the shape looked more like a dog than a bear the whistle turned into a howl. (Eye is notional because this thing looked strange without any eyes) More splines will be required to get at more expressive shapes. Less spline required in some places which makes me want to consider hooks (something I seldom use). Added: Shot of bone movement.

Well, I wrote a post in response but in the process of pursuing a quick grid-theory I seem to have browsed away from it. Ah well... most of it was theoretical outside of my initial 'Nice reference!' A few things I recall. - We have to allow for artist differences in that reference. - Our exploration can benefit from the fact that eyes and body don't have to be explored... but (especially given what you say about Papa Bear not talking) the eyes and body will most certainly have to be added back into the equation - The snout in the reference appears rigid, steady and independent of the mouth. It's a pointer... seeking... searching... for the thing of interest... smell of food...etc. The primary part that I would think would be animated would be the end of the snout/nose with the nostrils... assuming that the present story calls for that, which if I recall correctly it does not. Here's a quick take on what I think might work... still using the grid-method because I haven't tired of it yet. I was tempted to include the tongue in the grid but then thought better of it. Now to do a few rig tests.

I can't quite remember who it was at Hash Inc (I think it was Heath) but I recall exchanging a few emails with one of the programmers where I exclaimed, "We can write our own programs with A:M." The response I got was one of those deadly silences that implied a straightjacket was waiting in the wings for me ala, "Yeah, sure thing Rodney.". Grid paint isn't really an example of what I was talking about then but it certainly comes close. Basic steps: Create grid of desired dimensions Create group for colors needed Use lasso tool, patch selection tool or other to select parts of the grid. Want to clear the 'canvas' and start again? Delete all of the color groups except the base color group. Additonal features Right click and create a material of the current color (apply that colored material as needed) Copy paste painted geometry into 3D space to achieve effects with depth. For more interesting colors/fills change the material to something more complex. For access to better results and more tools consider gridpainting in a Chor window. So yeah, if you get a little bored... create your own mini programs with A:M. Added: Example of basic use in Chor window

And another pixelgridpainted terrain. This one leverages the seldom used Composite feature as the decal image applied to the displaced terrain (which was captured using A:M's Snapshot feature because I hadn't used that in quite awhile). Why use Composite instead of a typical image as a decal? Composite introduces a non-destructive workflow because any change made in the composite can then flow to the decal. This leaves original images contained in the composite in their original state but changes the output via 'live' post effects. If a decal image is used, that image must be modified/replaced.

Taking a slight break from modeling faces (but not quite escaping from grids), here's a terrain generated using Landscaper material (color), Terrain Wizard (geometry) and something I'm calling A:M Pixelpainter (to generate the image used by Terrain Wizard). In short, everything created with A:M. A:M pixelpainter is a foray into gridpainting via groups... on odd concept that worked much better than I had anticipated. I saw an old topic where Andy Whitlock mentioned he was willing to share the Terrain Wizard code so that others could work toward other terrain plugins. I'm guessing he'd still be willing to do that. Of interest to me is the Terrain Wizard's ability to paint inside a plugin window inside A:M... that certainly has potential for other applications. At any rate... a random terrain...

Most definitely a requirement. The initial grid is never left unmodified... at least not for me... I'm not that good at anticipating where the curvature will work best in 2D so that it will fall into proper place when properly distorted... not yet! One of the neat things about the grid-modeling approach; the ability to explore different topologies quickly and reroute splines as necessary first in the 2D plane and then later again in 3D as we discover something doesn't quite work. The knowledge gained is then applied to the next attempt... and the next... and the next... and perhaps best of all, when going back to standard modeling sans grid the brain (usually) remembers the lessons learned and the modeling comes together without as much guess work. I plan to use the grid modeling approach with more mechanical shapes as well but I've been having fun with modeling heads at the moment. I assume mechanical modeling will lend itself readily to the grid structure although time will have to validate that. Aside: One useful aspect of grid-modeling (in general) is how patches tend to start as roughly the same size. This is ideal in many cases and many of the models I've deemed as having ideal topology tend to keep patch sizes very close to the same which tends to maximize spline/patch smoothness.. In modifying the initial grid I tend to lose consistency in patch size and need to remind myself to do my best to move back toward that. I did try some cube-modeling with use of v19's 'remove internal patch' feature but the primary issue there is one of spline continuity. There is no way A:M can anticipate what the best flow for a spline will be in every case so that is usually best left to the modeler to determine. Like the grid-modeling method, cube-modeling can give us an initial starting point but unless it's used only as a proxy (not likely to be seen up close) it will require work.