Rodney

I probably should have been doing that but I was testing a workflow that didn't use light buffers... just adjusted color directly on the image. Although I was using EXR images... because I was investigating changes in the latest release of A:M. I"m pretty stoked that EXR 2.0 has been initiated in A:M.

At one point I recall thinking the problem was confined to PNG images but I'm seeing in here it other image formats too. I need to skim through the bug reports and forum posts because I believe this is an issue that was addressed before.

For this test I used a single patch with image sequence applied.* We can see the dreaded diagonal line across the image here (I believe I used 'cookie cutter' as the patch image type which would cause transparency to be applied). Note 1: These images don't try to leverage z-depth (or what is often referred to as 'world space'... that is an exercise for another time. Note 2: There is no Keekat model in these tests only an image sequence/turntable of him rotating. *The original spinning one direction while the others spin in opposition is an indication of the direction of the patches surface normal. Flipping the normal would yield the same rotation. relighting test.mov

Here's the introduction of a third light to suggest the presence of a light intensifying then flickering light in the lamp. Of possible interest for a future bug report: When any transparency is introduced to the Layer that dreaded diagonal line across the layer/image appears. When the transparency in the original layer is removed the line goes away. Removing the transparency (i.e. setting it to zero) in the Chor instance of the Layer leaves the line in place). So, the diagonal line across an image bug appears to be related to a problem with transparency. relit imagery (third light).mov

I'm posting this mainly so I remember I did the test... This is a short (randomly lathed object) image sequence dropped into a Chor as assigned to a Layer. Two lights then relight the image and run it through a series of color and intensity changes. relit imagery.mov

Nice one Mark! And it's great to see those pirates again too!

Thanks Nancy!

Those that fail to plan, plan to fail etc. The subject being 'marketing' it's interesting to note a few things one of the chiefest being that we don't adequately use the resources we already have available to us. To chase after marketing is first to assume there is a market to pursue. but... but... when can we be rid of the misinformation that flows so freely through a forum that should know better. There were very specific and itemized goals identified at the outset of TWO and they are just as applicable today as they were then. ...and scaleable. But let's keep the focus on marketing. There has always been a strange fascination within the A:M community for marketing of A:M. I'd tell you about of few of my own pet schemes but I'd surely bore you (the primary one was (initially) a printed magazine devoted to the interests of the A:M community. Ah, would that magazine not have been glorious! In a way we already had that magazine (in digital form)n the form of continuous updates of the A:M forum. It's just a bit less... graphic... than I originally imagined. Martin had his finger on the pulse all along and knew content was key to the future (and that a solid franchise or two certainly wouldn't hurt). And with every A:M user having a myriad of projects they want to create going forward marketing becomes a natural by-product of the community. But much of this product is wasted because we havent quite figured out what to do with it. It's been said multiple times in many different ways in this topic and elsewhere by many and varied people but to those that have a desire to market A:M to the masses I'd say the best advise that can be given is 'use A:M as it currently is to create your project'. Don't have a current project? Join with others who do. People will naturally want to know what you use to create your project and they in turn will spread the word. In other marketing news: Has anyone else noticed we are getting spammed by emails every time a new update to A:M is released. Congrats to whomever made that happen.

I don't know enough to say. I think Martin is deeper than that. I appears to me that with TWO he was listening to his customers that wanted to create animated movies... so he said, "Let's do it. That's why I created A:M." And here's the thing... we did! The project was successful. As far as I know it wasn't commercially successful but many of those involved used TWO as a springboard to other success. Participants gained experience, confidence and a lot of insight into how such projects get made. In other words, exactly the opposite of 'this path didn't work for us'. Just imagine if TWO had garnered the buy in from more of the many talented folks in the community, especially at those critical (and inevitable) stages where commitments fade. I can only speak for myself and the primary reason I joined the effort was to learn how to make an animated movie. While the jury is still out on how successful I was in actually learning how to make an animated movie some progress toward that goal (of learning the process through experience) was definitely made. Hey now, that's not marketing... that's development!

There are many rich veins to plunder in related areas. I consider direct editing of A:M's files in a text editor and development of additional features/utilities through the SDK as elements of 'expert mode' as well. The fact that the text editor or programming application launches outside of A:M shouldn't be too much of an issue for someone with that particular expertise.

You may recall the 7 days begins *after* preproduction has ended as it only covers the period of production (a story-less project doesn't have anything identified that yet needs to be created). Perhaps I can find the topic and point everyone to it but I believe it may have been in the private TWO thread. In this way many productions would be in various states of preproduction with production only commencing upon a central project being green lit. Think of it as a community that would take on different projects during the downtime between episodic production cycles for the various but never ending chapters of 'Tar of Zandoria'. This prevents critical skills atrophying while waiting for the next script while granting some relief from continual work within the same project/genre. While the swarm of production-hardened folk are devouring the primary production additional tasty treats are being cooked up for their consumption in the wings. I'm enjoying this trip down memory lane but starting to remember why others where not in sync with Martin. We couldn't possibly grasp the scope of his vision.

Dan, If you contact jason at hash dot com he'll be able to get you set up.

In case I was a bit too cryptic with that description... Creating a film (short or long) in seven days isn't going to be a one person journey. The idea is to play to everyone's strengths in a community (and their current interests) and plus up the product as it passes through each gate. Then as skills and interests improve or diverge the rising tide floats all boats to a sufficiently successful level to do it again and again (with people coming and going as they see fit). This is not unlike what Jost was saying before with regard to creating packets/collections of models. It's not essential that the product being produced is a film... the essential driver is the community the product is created in... and yes, also in the software used to create it. This is where our community can play to A:M's strengths because not all software is created equal. Where it comes to it's unique splines and patches A:M is the only one even standing in the arena. The seven day production cycle is certainly scaleable but it really does rely on collaboration. We only have so many years of life... going it alone, how many feature films (or short films, or props and resources for your own personal production) can one reasonably expect to create in those years? To get anything worthwhile accomplished I won't say that it takes an entire village, but it can help (and be a bit of fun) to enlist the aid of a few collaborators and friends.

It sounds odd because it would be odd. It would be harder *for A:M* to model. Easier for us. We don't generally see what goes on behind the scenes we just want it to work for us (athough A:M also lets us dig deeper than the surface as we turn additional options on... and with the SDK even deeper if'n we want). A:M is one of the best programs on the market at shielding the user from arcane stuff. It's like that old saying about taking your car in to a mechanic to have the engine worked on and watching as the technician rips (seemingly random) parts out of it. The typical reaction might be to react a bit emotionally, "What the hell are you doing to my car!" Which is why we generally don't want to see that stuff.

Thanks for the response Gerald... I appreciate the time you take to provide input. It certainly helps. I can only speak for myself but I'd say that hitting the period key twice to deselect reselect a five point patch is successful over 95% of the time. I want to say 99% but I'd be hard pressed to prove that. I will say that out of the time that it doesn't work almost invariably I am dealing with a collection of splines that is not sufficiently constructed to make a 5 point patch in the first place. In other words, it's splines layout prevents it from being eligible to be closed as a 5 point patch. Note that I'd have to take a good look at this to see if having the suggested 'optimal spline layout' would still allow areas where the illusion of a legit 5 point patch could be created exists. At a guess I would say that it would... and if so... optimal spline layout (in the sense that only two spline could go through any given CP) throughout a mesh might be problematic for closing 5 point patches. Aside: This is as good a time as any to remind folks that a single spline can be a five point patch. Not all versions of A:M allow this but most do. I believe the lastest releases allow this more than those just a few releases ago but almost all versions will allow a single spline to be closed as a 5 point patch *if lathed*. In other words, if A:M created the 5 CPs then it can almost always be closed as a 5 point patch (because A:M tends to only create legitimate/optimal splines/patches. As I say though, currently in A:M this is working also without lathing. (See attached video). I know that in the past I haven't always been able to draw a single 5 CP spline and close that as a five point patch. 5 Point Patches.mp4

I want to cherry pick a few thoughts because they dovetail with the here and now of the forum (I can't accurately address the aspects of pining for the past or wishful thinking toward the future). I will say that the vast majority of folks that have had issues with A:M seldom actually use A:M... of course they would dearly love to use A:M... if specific features appeared fully formed (in the next release or I won't buy it)... if full compatibility is achieved with my primary software (immediately if not sooner)... if the stars align... etc. We as a community (lead by Martin) achieved many if not all of the stated goals of TWO (we can itemize these if desired as that would be a great learning experience) but not all of his longer term aims for the community of A:M users have yet to be realized (it'll take time for those). For instance, a major trajectory post TWO was/is a 7 day production cycle for animated films.... that isn't 5 or 3 years folks... not even a year or 7 months... a *7 day production* cycle. The fascinating thing; it could have been.... and very nearly was realized but Martin's willpower alone wasn't sufficient to sustain that trajectory It'll take a thriving/active community to put that infrastructure into place. And frankly, we aren't quite up to that challenge yet. (slowly but surely we are getting there though and I'd say that a 7 day production cycle for a short ad/film is on the edge of being implementable right now) Historically we as a community have relied a bit too heavily on a few very talented folks to carry us forward (often still do) but this can often be at the expense of the greater good of the community who are struggling to rise to that level of confidence, skill, experience, etc. often inside a vacuum (because after all... newbies should be seen and not heard). I recall once someone comparing me to the professional (money making) users of A:M saying that I wasn't a real user. However true that may be, this mentality is surely detrimental to us all. Stop pontificating and help me become a real user! Aside: Did anyone notice that the second Oz movie was made with a fraction of the talent pool of the first film and yet is superior to TWO in many significant ways (or at least on par with it)? This was the fulfillment of one of the goals set leading into TWO... to "Be able to do it again". Translation: Another accomplished goal as set forth from the very beginning. Interestingly, 'making money' wasn't a goal of TWO because Martin didn't see that as a realistic expectation. He said he'd give distribution a shot and he did exactly that. This showed a progression of folk that had never made a movie going into TWO that carried that experience forward to achieve completion of a second feature film. That is serious success in my book. If only the greater community appreciated those efforts to rise to the challenge of community filmaking more. While on the subject of TWO... I'd like to think that models will sell but history hasn't borne that out. The fact that the TWO models are already available for free likely wont help either. Having said that I'd love to collaborate with someone interested in packaging up TWO assets for inclusion in the A:M Exchange forum or even to sell via the Hash store (if Hash Inc is game for that... that'd be quite a chore though). And while we are making plans, let's emphasize low cost... so we can all afford those resources. If a higher price potential for the future is desired, perhaps we could price each bundle at $19.99 and periodically discount them 100%. Seriously though... if anyone is interested... let's make a few bundles/packs. These are great assets designed to be used in 3D animation. It'd be nice to see all the great A:M models in the community (not just TWO assets) get more screen time and distribution. And a little far afield: I occasionally use a few programs that if they were just free of the cursed triangles found in many 3D meshes could be beautifully compatible with A:M. It's going to take years (and probably more than a few companies going out of business) before we see much improvement in this arena. Why is this? Anticipated answer: Because few see sufficient profit in it. They are already heavily invested in other approaches... why mess up a good thing.

I had thought of suggesting various colors... an alternative to preventing error would certainly be to tag the error with a different color, larger (or smaller) graphic, etc. But while nice in it's own way, it must be noted that such an approach doesn't get to the root of the problem which is what an error-free workflow would (theoretically) be designed to address. This is why I suggest it would be a separate modeling mode that one would have to enter into because I agree that sometimes the lazy/sub-optimal way is good enough. Heck, the whole world is a slave to that approach with tris... and lots of folks are content for it to remain that way. But if a better way is possible... An example of this is Simcloth which when first implemented was following a polygonal structure that hindered the implementation in many ways. The programmer (Bob if I recall correctly) started again and pushed the tech into the realm of splines and patches to very good effect... with us as the beneficiaries. As for 5 point patches... that's a bit of another topic and the short answer is; hit the period key twice to deselect and then reselect the 5 CPs. I'm not entirely sure what that does behind the scenes but I've always thought it reordered the CPs so they get recognized correctly as an eligible 5 point patch candidate. I have a vague recollection of someone working toward an implementation of an automatic 5 point patch methodology (here I assume that would entail A:M creating a 5 point patch automatically out of any and all eligible 5 point patch locations. I would think that a precursor to that would be that a plugin could be created that would traverse through a model and identify (and group?) all 5 point patch candidates. A subset of that plugin would then be to turn each of those into actual 5 point patches (i.e. a deselect/reselect operation followed by a 5 point patch assignment of the CPs). But back to the original premise of the topic... In order to even consider implementation one must first consider what benefit could be realized. If there is no benefit or very little benefit then there is very little reason to implement the thing. Programatically I can think of one benefit and that would be as follows: - Let's say that we start modeling in the 'ideal splinage' mode and take that model to the point where no other optimal spline connections can be made. - We then save the model and exit that mode into the general mode that everyone uses today. - When the model is complete (or at any point thereafter) we save the model under a different name - Now we run a comparison of the first and second models and note the differences (via this comparison we can identify where special cases have been implemented or may yet be made). - At this point the system (and users) can 'learn' what ideal topology actually is (without starting from scratch every time if that is also optimal or ideal). Now we could go farther and suggest additional benefits but should we even speculate? One might be the implementation of a Subdiv routine that could mirror and likely outperform similar implementation in other programs. With ideal topology this and more can be developed but if A:M has to constantly deal with infinite implementations of bad topology the task becomes infinitely more complex.

While it can be a little bit of work it may be worth considering taking several of those images and combining them together. You could, technically have one decal that covers everything... but that would obviously be a large file. The plus would be that it'd be a lot easier to keep track of than hundreds of separate images. The Decal Editor allows for assignment of the different areas of an image to model geometry wherever you want to place them. This can be especially useful if you have master images for models similar in layout but not in specific detail. For instance, if every humanoid character is going to be modeled in roughly the same way then a master decal image for each can be created. Similarly, buildings have one primary facade where the majority of detail is needed (usually the one that faces the camera). On a larger scale entire cities or backgrounds can be decaled in a similar way. Will Sutton has a very fine video that outlines the basics of the Decal Editor and several nice improvements have been made since then. I'm glad to hear you have such an affinity for A:M.

Yes, it is quite straightforward. I'd say the best method for organizing decals would be to place those decal images in the same folder as the model they belong to. Then when you move or rename the model folder the decals will go with them. Renaming and moving files is the reason the link gets broken in the first place. The same goes for renaming the decal images themselves. By placing the images in with the model they are less likely to be mistaken for images that belong somewhere else. As for reestablishing the path you can either do that in A:M via the browse function to point A:M to where you have moved the file or move the file into the proper location on your harddrive where A:M will automatically make the connection. One easy way to reestablish a connection for decals whose path or location is problematic is to open that image in A:M from it's current location (at this point even if you do not... A:M 'knows' it's path). Then crack open the decal properties in the Project Workspace listing and change/select that image from the dropdown images that appear. All the images that are currently loaded in A:M should appear there. If you have a lot of decals for the same model its a good idea to create a folder inside your model folder (call it 'decals') and place all of your decal images there. If you've really messed things up and 100's of paths are broken it is often best to use a text editor to go into the file and replace the paths via a global search and replace. Having sad all this... there really is no substitution for good (and perhaps more importantly consistent) organization.

I had an odd thought today... What if we had a mode of modeling that wouldn't allow more than two splines to connect to the same Control Point? I can think of one particular downside to this (more on that later), and surely there must be more problems waiting in the wings but the thought is/was that while most folks are looking for easier ways to model another solution might actually be to make it a little bit harder to model in that... while in that particular mode... modeling with less than optimal splinage would be harder if not impossible. The downside would be where we want to connect discontinuous splines to another spline. But in this case we (the modelers) may be attempting to introduce an other-than-optimal spline topology into our model. Now, there would be a special case where continuous splines would/should be allowed and that is if the spline is one of the terminal ends of a continuous spline. This then does beg the question of how we could better differentiate the terminal CPs from the internal CPs of a given spline. These thought occurred to me while considering that many folks spend a great deal of effort trying to shore up and improve the bridges to the polygon world but this is often at the expense of the further development and benefits of spline-patch technology and rarely an aid to it. In other words... building bridges to inferior technology. So I guess primary questions might be, "Should the user be prevented from making errors in ideal spline topology and if so what might success look like? A tentative answer might be that A:M might initially refuse to allow the connection but the user could easily override that 'safety' (via holding down the Alt Key or some other equivalent). From a programmatic view the modeling process (in that mode) would be streamlined considerably because after two connections that particular connection/vertex would be locked or closed. This could lead to a number of other possibilities for modeling with splines. As I see it A:M wouldn't even have to process these because although the user might try to attach additional splines/CPs they won't be able to stick to the model. Why won't it stick? Because it's not going to yield optimal topology. Aside: This is a little off topic but relates to spline continuity. Have you ever considered that a spline circle isn't (i.e. cannot be) perfectly continuous? This is a similar problem to the real world conundrum of creating a perfect sphere... technically we can't as there is always going to be a start and stop point. The classic remedy/solution is that of scale. If you can make the 'error' so small as to not be noticeable it is an equivalent to not being there. Other classic remedies include 'polishing' or masking with other textures or shapes. But none of these change the fact that the starting and stopping points in the original form are still intrinsically there. They simply obscure/hide that evidence. When considering the plight of the circular spline another potential solution presents itself *if* the start and end points of the spline can transfer to another place on that spline. The ideal place for the terminal points to be with respect to a single point of view would be out of site... on the back side of the circle, sphere, etc. And because these terminal points could be told to stay in that relative place on the back side of any 3D shape these terminal points would effectively disappear. They'd also be a lot easier to find at that location should those that know they exist look for them there. A continuous spline (circle) that can adjust/transfer it's terminal points to another segment along the length of it's spline might be useful.

My first animation/breakdown with the saucy rig. And I shall call it, 'Hey waiter.' The tests I did for this include creating five different actions/poses and throwing those onto Robbie in a Chor, then adding additional movement to that. Prior to that.. for no particular reason... I played with constraining Robbie (and the saucy rig) to a BVH action. That satisfied my curiosity so I moved on to creating some drag and drop poses via actions. While playing with the rig the thought occurred to me that the saucy rig needs some more User Settings for basic poses such as making fists and such. Can someone tell me if there is a controller that allows the clenching of hands (i.e. movement of all of the fingers simultaneously) with the saucy rig... did I miss that? dining.mov

Just got done watching the tutorials. Well done! My biggest question out the gate was... why name it 'Saucy' rig? Asked and answered via your website and you expertly explained the influences of those other rigging gurus on your latest rig as well within the videos. I hesitate to mention specifics because I"ll leave a lot out but things like the foot/heel roller are very welcome additions. The null controllers on the hands are intriguing and I'm anxious to try those out. You've also suggested some great workflow tips throughout and I thank you for that. Also: I enjoyed your 'warm up' rigging tutorial... the one with the tank... I'd somehow missed that one. Newbies just getting started with rigging should definitely watch that! Thanks Mack!

Happy Birthday!

The folks over at 'Taught by a Pro' have a new video lesson by Reuben Aquino that focuses on use of Center of Gravity in animation. At $10 I'd say it's well worth the prince of admission. http://taughtbyapro.com/course/animation-fundamentals-center-gravity/ Some of his credits include: “Mickey’s Christmas Carol” 1982 (clean-up inbetweener) “Black Cauldron” 1985 (animator) “Great Mouse Detective” 1986 (animator) “Oilspot & Lipstick” 1987 (CG short, animator) “Oliver & Company” 1988 (supervising animator, worked mostly on Francis the Bulldog) “The Little Mermaid” (1989; supervising animator, Ursula the Seawitch) “Rescuers Down Under” (1990; supervising animator, Jake the Kangaroo Mouse) “Beauty & the Beast” (1991; supervising animator, Maurice (Belle’s dad)) “Lion King” (1994; supervising animator, adult Simba) “Pocahontas” (1995; supervising animator, Chief Powhatan) “Mulan” (1998; supervising animator, Captain Li Shang; won 1998 Annie Award for character animation– Captain Shang) “Lilo & Stitch” (2002; supervising animator, Pleakley & David) “Brother Bear” (2003; supervising animator, Denahi) “Meet the Robinsons” (2007; supervising animator, Mildred and Mr. Willerstein; his first CG feature credit) “The Princess & the Frog” (2009; supervising animator, Eudora & James) “Winnie the Pooh” (2011; animator, Winnie the Pooh & Eeyore)

That was deep. You took the song and added layers of additional (resonating) meaning to it. Nicely done!