Rodney

Ha! Very nice. That last one approaches the feel of those old phenakistoscopes.

MOX is up to Alpha 5 now which includes compression codecs for PNG and EXR (previously those resources were uncompressed). I experienced a problem with the After Effects plugin but the Media Encoder/Premiere plugin works great. I hope the format gains enough traction in the industry that somewhere down the line the MOX format can be added to A:M beause having all the resources (sequence of images, sound, etc.) all in one file is refreshing. A:M could use another movie format besides AVI and MOX (or a similar format... of which I'm not currently aware of) might be just the ticket. As stated before though even if not directly incorporated into A:M using MOX as an intermediate format would help to collect everything in one place. According to Brendan: Dirac is an open and royalty free video compression format capable of lossless as well as lossy compression.

That heuristic may need to be revisited. The goal with regard to lean programming (and of limiting repetition) is primarily to prevent waste which would include limiting avoidable process repetition. As you say... although I'll add a word, "Don't unnecessarily repeat yourself". It's like building a brick wall... where we need to place more than one brick... the question then becomes how to best build that wall and should we need to build another wall right next to it later... and perhaps several other walls of similar type in the future, how best to plan ahead to eliminate waste. One would have to do some testing to see if Action Objects are indeed better than similar (derivative) models. There are some golden rules of old that might apply that would be better to consider than that of model complexity or areas of mesh similarity. It might be that at some point having more references to a resource actually will exact a bigger toll than if the mesh had been replicated. For instance, if each reference brings in its own separate instance of decals, etc. that may cost more than if it where all of one model without references. I'm not sure how it that old articles applies to how A:M processes resources these days but I'll see if I can't dig up that hierarchy of priority article concerning how A:M deals with such things. I think it was Martin's paper on preloading of resources and precedence lists. There are a lot of processes I need to revisit in A:M that years ago I might not have used as much because of RAM limitations. RAM is still a concern for me but not as it was in the past. If I'd learn to shut down unnecessary programs that'd solve a lot of RAM issues. That'd free up a lot of wasted space! Luckily, hard disc space hasn't been a concern for most of us for many years. Added: A few tests I've been running don't show a lot of difference between combined model and instanced models. One major consideration (already mentioned) is whether or not the objects will be moved or animated separately. In this sense it seems that the term 'object' takes on a greater role as that may mean groups of objects that form a new object. That object can then be manipulated individually. One test I did involved a group of chairs. Of course it was much easier to manipulate the individual chairs if they were instances of the original model. Of course at that point identifying them by a Group name might work well to grab them as needed. As individual models they are more easily selected in a chor.

Windows 10 should work better with most apps than Win 8. Microsoft really wants folks to update to 10 so they are pushing that aspect hard. And it's important to note that 'not compatible' does not mean 'will not run'. It's more of a means of optimization and ensuring common/supported frameworks are used. It would be very odd if it didn't.

Brilliant suggestion. That works great. As a matter of fact that is a great way to combine multiple characters with their Actions intact too.

As you've experienced there are some definite gotchas that come with Action Objects and those aren't all limited to Netrender. A thorough testing would need to be conducted but from memory Action Objects are specifically limited in that Actions cannot be nested inside other Actions. Actions can be layered/blended but not nesting inside each other. Somewhere Martin outlined the hierarchy of actions and at the time I thought it useful enough that I created a graphic based on it before losing the reference. Edit: Found it! While it might not be of specific interest related to your query it might provide insight into why certain approaches won't (optimally) work. For instance, when we consider that an Action is independent of each character/object we start to see how an action cant (logically) be dependent on multiple objects simultaneously... that's not how they work. Although where an Action or Pose might not work a constraint or established relationship might very well be made to work. As I have limited experience in real world production especially with complex models I yield to the experts (and you've mentioned two!) but want to offer what I can. I'm not convinced that avoiding multiple copies of meshes is always the best route... at least not when considering the end result. As always YMMV. For instance, when modeling it wouldn't make sense to build dozens of chairs individually if you can just create one BUT... that doesn't mean you can't put that one chair in a Chor multiple times and then export that Chor out as a model that then has has 24. The big question is: what do you need in that shot? Can you render out that scene and just use the image(s) as a backdrop (moving or otherwise)? You might not need any models except your characters in the final pass. What will the character's interact with? Those should probably be models but what can be prerendered and dropped into the scene or even composited later? Thanks for asking the question... that helps us get the creative juices flowing. Edit: I say that Actions cannot be nested and this isn't entirely true. I'll try to post some examples of this after I refresh my memory.

...if relying on Netrender. Otherwise you seem to be saying the technique works well. No caviets with a straight flow through A:M's internal renderer? I'm thinking a workaround should be possible if we can automate rendering in A:M. Once upon a time some folks did this (in order to render out a couple hundred materials) but I confess I don't know how to do it... short of a hack or two. The hack being to set a shortcut key for rendering and then use a keystroke utility to launch rendering. If it appears that the Netrender solution may not be workable in the near to mid term perhaps a feature request could be put in to automate rendering through A:M... perhaps even via command line operation? This would in essence also bring Netrender closer to being fully intergrated with A:M itself whereas (to my understanding) it is a separate renderer based on or which uses or passes data through the A:M code. Lest this be seen as a temporary stopgap or bandaid on a bruise I'd suggest folks try to envision a longer term goal of charting what success might look like in a perfect rendering world. As there is little chance of successfully implementing this in near future now may be a good time to take a glance at what the future could hold. Note that I'm not specially suggesting a framework for alternative renderers but by its very nature a good grasp of rendering workflow in A:M (past, present and potential in A:M would allow for that too. For example, it might be good to review how Netrender's renderer differs from the internal renderer. Since I'm on the subject let me suggest two use cases that might apply well to optimal rendering in A:M: 1) Invisible/completely automated/no renderer invoked outside of realtime or near-realtime views 2) Full screen/customizable In the first case it would be nice to be able to downplay rendering to disk to the point where one almost doesn't consider it at all. I'd be glad to comment more on this but it would be better served in a topic of its own. The basic idea here is that everything that can be rendered in realtime probably should thus avoiding the majority of issues encountered with traditional rendering. Realtime renders might be saved to disk but probably not in traditional way... more like a dump from memory after you've viewed it in realtime... a simply a screen capture of the same saved for later viewing. Note that this would not be quite the same as the current Render Animation Preview... although it could be similar. This will be more likely to happen once video capture becomes ubiquitous on modern operating systems. We aren't quite there yet though. In the second case, once a user decides they need to customize a rendering to target specific goals it would be nice to have the option to see all options available (or as many as possible) and perhapss even see the estimated impact a specific setting might have on rendering prior to launching the renderer. A specific case for a full screen render panel is that currently while rendering nothing else in A:M can occur... the renderer is in full control and does not release control back until the last frame is rendered. Unless the renderer can be made to pass back control to the user and render assigned frames in the background it doesn't make a lot of sense to have a small render dialogue box with screen space all around that cannot be used. Perhaps it would be better to use that space to launch the user into the full experience of rendering? (perhaps more on this later). Bottom line: Netrender is a great asset (and the fact that it's included with A:M is invaluable) but wherever it deviates from A:M's internal renderer there will always be gotchas and workarounds. As such it can only be part of an over all rendering solution. (My apologies for the off topic)

Nicely done!

You've made me smile Steve. I'm glad to hear you've got your system(s) working optimally. And... nice visual! You've got me imagining you working away at creating Kira like Dr. Frankenstein too! There is an interesting dichotomy in what you've posted; advocating for frankensteining the old stuff while just as enthusiastically promoting trying something untried and new. Both approaches are so very valid. Ultimately, we pick a path...smile/frown, rinse/repeat... discover/rediscover what works. We face continual decisions in what we should use. There are good reasons to start from scratch or step away from the tried and true but there are just as many (if not many more) for leveraging paths traveled before. If a thing/approach/solution doesn't yet exist then design, modeling, production may certainly be called for but if it already exists it may be ideal to use as is or be modified (made to fit) for more immediate usage. A:M is powerful software firstly and foremostly because of the design principles and philosophy behind the software... not just the software itself although that has proven powerful too; those 'things' that A:M uses... and reuses. "Reusability is the foundation of Animation:Master" - ToaA:M page 49. Aside: I have been neglecting maintenance on my car because of the anticipated expense involved and suffered through many days of watching my car's health deteriorate even more due to lack of that maintenance. Today I bit the bullet, spent the money and my car is fully operational again. I'm not sure what that has to do with anything you've written but figured I would add the thought. Almost gone is the memory of putting myself through the needless pain so perhaps by adding it here I'm trying to learn...

I'm not familiar with the algorithm(s) for seam carving but it seems to me a similar process could be used to remove and insert splines in a mesh via automation. Prior to processing for carving/retopology all data would be saved in original form as well in extrapolated form in anticipation of reuse in final results The first test then might be to find those splines that start and stop at the same location (a further test might determine to what degree these primary splines are linear, vertical, horizontal,, etc. as this dictates the meshes primary if not optimal orientation).** The test might then move on to sort a list of spline lengths from longest to smallest. The smallest splines then are tested for usefulness as patches; if not of valid use they would be flagged for removal/replacement. The carver would then iterate through the list toward the longest splines with a goal of maintaining equal distances between splines. Areas of increased density would be flagged for further testing; i.e. can that area be reduced further without negatively effecting the surface/smoothness/curvature of the resulting patches. When the carving process is complete the higher rez model's decals would then be reapplied to the resulting mesh via platt projection. Note that I am not really considering the conversion of models created in other programs specifically here as the perfection of the process of moving up and down the resolution scale inside A:M is of more interest to me. At first blush this would seem counter intuitive because splines are of infinite resolution in the first place BUT splines currenty rely on the user for optimal continuity, placement and orientation. Once there is a known goal to strive for that can reliably be targeted and retargeted then the external conversions can be optimally built for it. Futher, knowing how a converter works (or being able to adjust parameters of that conversion, would allow the modeler to create the model in other programs with a focus on 'modeling for animation'... and specifically for use in Animation:Master (which appears to be the ideal for those apt to use other programs but who prefer animation in A:M). I don't do that often but when I do I'm almost always impressed by how well that works! Point cache conversion? Intriguing! **This is where we would begin to fetch the UV data.

I follow you Paul. No misunderstanding. There are definitely going to be workflows with polygon modelers that will be nigh impossible to match with A:M. Understanding why that is helps dull the pain a little but doesn't stop us from imagining a world where that isn't the case. The technological hurdles though... are considerable. I occasionally refer back to some of Martin's articles in order to reset my expectations and realign myself with reality. Specifically that A:M (or more appropriately Animation Apprentice) started with animation first and foremost and splines/patches followed in order to serve that. The rendering then took several years more to resolve. But the point... all aspects of Animation:Master are driven by animation. It's not difficult to imagine what might happen when one models in most polygon programs that are not designed/optimized for animation... or where animation is an afterthought. The models may look great but how well will they animate? BUT... one doesn't have to reference Martin Hash to recognize the obvious. A case in point might be a simple spline or set of splines that form a surface and another set of splines that form another surface that overlap each other. The desire would be to have the second cut a nice hole in the the first (or shave part of the surface away) but if those splines don't line up/intersect we have a problem. And this doesn't speak to a more common likelihood of one object being denser (with more splines and surfaces) than the other. This is one of the reasons why boolean cutter operations with minimal splines are relatively trivially computed at rendertime but extremely difficult to get right in modeling. The primary option would be to split the surfaces more densely in order to allow for the intersections but this would come at the cost of minimal (animation friendly) splines. SO... the solution would appear to be one where we can iterate up and down through the density of splines/patches (currently the splitpatch plugin does fair job of splitting and ratcheting up the patch count... while exporting out at a lower resolution and reimporting back in does a similar thing in reverse (if using the PLH format). Pixar's Subdiv would seem to be a solution but even in that case there are many a pitfall to avoid especially if approaching from a nonoptimal mindset. I don't know enough to even guess here but since that has never stopped me before I'd say the difference may be as non-non-trivial as the difference between the constructs of approximation and interpolation. Pixar Subdiv being (at present) mostly of the former while A:M's approach primarily of the latter. It should be worth noting that Pixar's Subdiv 3.0 stops short of implementing some significant features still planned for future release. Ref: Subdiv 3.0 Notes: The good news is that technology marches on and the situation is incrementally improving. Save those models. If nothing else your great grandchildren may someday be able to animate your Zbrush models direcly in A:M. I think I'll stop there before I hurt myself.

As the 'mesh' in the Decal editor isn't the same mesh as the model it can be manipulated without concern for the model's mesh. As such they can be moved around to any location... rotated... whatever. Obvioulsly the image associated with the orientation, size, etc. will need to be altered to meet visual expectations. Added: I do wish we could adjust biases in the decal editor because those sure like to maintain their original orientation. I suppose one way to get an 'extra' platt section for use in the decal window would be to model it in as extra from the beginning. As it wouldn't be used in the model it could then be tricked into service.

You might have to demo that workflow for better understanding. Barring that I assume you aren't familiar with modeling in a Choreography.

Paul said: Nothing too frightening there. Most folks who say this only have a short time to work on their projects outside their day jobs and other commitments; perhaps a hour after work on any given night. In the end you'd likely find the process takes about the same time (give or take the individual skill/experience of the artist and the inevitable extra time needed to ramp up into longer term periodic projects). And regarding the level of detail... as they say... most projects are never completed... just abandoned. You can almost always find something worth tweaking and/or add further detail. Knowing where to stop is as important as knowing when to begin. I do think it best to tackle all major tasks in one sitting if possible... much time is wasted otherwise. But this is a workflow issue that doesn't relate to the software in any meaningful sense. Workflow is certainly key. One thing folks can do is share a video here in the forum of their workflow or an approach that they would like to refine. When others see that they will make alternative (often very useful) recommendations. You mention several processes that are intriguing. It does make me wonder if you've used plugins like SplitPatch. I assume you have but if not... those are great time savers. A:M has a lot of modeling bells and whistle that few people use (I think largely because we tend to forget they exist). The use of external modelers can be both a blessing and a curse in that a workflow learned might give insight into a method in A:M but it also might frustrate because there are better ways to spline in A:M. What is being modeled will also dictate. Added: My gut feel is that if A:M Users focused more on what A:M uniquely brings to the table we'd see features appear that would be hard to match in any other application. Looking at other apps for inspiration (or comparison) can be useful but it doesn't play to A:M's core strengths.

I'm really liking this angle: There's something about it that just pulls me in.

Excellent idea! I must have missed that tip in the manual. Me too. I would like to say I had high expectations going into this but after purchasing more than a few cheap solutions to I've learned that 'you get what you pay for' is still a very good yard stick to measure potential success. Come to think of it... that's also why I resisted buying A:M for a long time. I figured something so cheap couldn't possibly meet my expectations. A:M is definitely the exception to the rule. I don't want to suggest the makers of the M3D printer didn't put some serious effort into their product because it is obvious they did and do.

Something of an update, although not a good one... During my latest attempt to print, the print fused with the base and removal of it has damaged the base plate. This is going to be problematic because the printer head can't properly print on the 'missing' surface that has separated from the base. Sigh. If you listen closely you may hear the sound of my learning... and furtherance of my 3D print education. I'll have to see what options I have in replacing the base. The good news: Now I'm not too worried about breaking the printer so my experimentation can expand.

Impressive work Rodger. I couldn't resist rendering out sequence of a camera moving through the scene (with your last image as a roto). Obviously not as nice as an actual camera moving through the scene but its fun to feel like moving through that set never-the-less. Edit: With apologies to Rodger, I replaced the first attachment with a more stylized rendering (with some post effect color work) because I like the painterly look. The style reminded me of some of Hopper's work you posted when you first started the project. style.mov

That's a great cast to run the Saucy Rig through it's paces. Looking very good Steve!

I dimly recall that watching these videos (The Pro Series) was were concepts of 'proper operation' of A:M started to click with me. They provided a host of, "Ah, so that's how you do it" moments whereas before I'd been working against... even blaming the software, charting my own way. There have been many such similar moments since then but that was first that clued me into the deeper complexities (and the simplicity!) of A:M.

That is very impressive Malo.

For those of you keeping tabs on this kind of stuff... Brendan has released the first Alpha plugins for After Effects and Premiere (with Nuke plugin to follow later). He's opted to call the file beta format NOX (meaning Not MOX) with the format name shifting to MOX when it goes final (or Beta). I don't have much detail to share beyond that presently but its good to see the format finally out in the wild and getting some real world testing. Update: I tested it using Media Encoder which is perhaps the best way to currently integrate it into A:M workflow (i.e. using it as an external image format/container that collects product created by A:M). The NOX files can then be passed on to other applications that recognize MOX (Premiere and After Effects). The basic process: Set Media Encoder to watch the Renderfolder which then automates conversion of any rendered files to MOX for use in those programs. There are still a lot of feature not added to the format yet so it's too early in the process to suggest how useful MOX will be.

Sweet! Thanks Mark!

Yup and I dunno (other than it'll only let you export the first 6 frames and the last frame in a sequence). Note that you might have to 'resolve' your setup before the new units will take effect but this shouldn't be the case. I'm just saying that if the exported units don't change after you've changed the preferences a reexported... something=wrong. Resolving might fix that. It almost looks like your original data might be scaled for pixel units (which isn't an unit option in SE so you'll have to find the next best thing).

I downloaded the current demo of SE so things might be a little different if you are using an older version. My initial problem was that the scale was HUGE... so *tiny* scale/markers wasn't the issue on my end. Changing the units from inches to millimeters got the scale about right for me. I didn't see any place to enter numbers for the units (other than world scale... which didn't appear to change anything for export purposes). If your unit are set to millimeters you might try inches and see if that doesn't get you close. Added: Image of the preferences panel...specifically the Save/Export panel: