Rodney

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.

Random teeth...

Here's a quick try on a bear shaped face... with spherical eyes. (The grid shows mid way stage right after thinking 'I should add some nostrils') Yes, all these characters need teeth.

Here's a variation on the theme... In this case I started with the four 'holes' of the face*; 2 eyes, nose and mouth and modeled them toward the basic grid shape. Then distorted them from that 2D plane into 3D space. In this one the mouth doesn't quite get enough splines flowing into it to get at proper shaping. Unlike most of the grid-models I've made I modeled the eyes as connected parts of this face. Usually the eyes work better as spherical objects that can be rotated separately. *Technically I guess we could say there are seven 'holes' in the head (if we don't count nostrils) when we include the two ears and the neck. Added the initial grid. Those with an eye for detail may note that I've reformed the splines that move down just to right/left of mouth so that they wrap around to follow the contour of the jaw and connect.