Rodney

I note that OpenSubdiv could deal with Gregory patches before but as of 3.0 it deals with them differently. The 'legacy Gregory patch' methods are maintained for backward compatibility but no longer used in OpenSubdiv. Here's a bit from the docs that refers to that: Source: http://graphics.pixar.com/opensubdiv/docs/intro_30.html For those familar with OpenSubdiv 2.0 there is a porting guide to get you up to speed on 3.0 available: http://graphics.pixar.com/opensubdiv/docs/porting.html Added: Regarding Gregory patches and OSD this is an interesting quote from the docs:

There are some services behind the scenes that can be utilized such as annotating content, project management, etc. *If* they leverage some of the project management technology they've been developing over at Animation Mentor then that would justify some cost. It remains to be seen how this might change given newer technology coming on line via Windows 10 etc. (although with Win10 that is mostly related to annotating within the browser) When any service like this comes along my skepticism kicks in and I try to weigh the various pros and cons. My flaw though... I want to be optimistic. I'm specifically interested in how they will approach the collaboration of online projects because I've got a few thoughts on such things of my own (not that I would or could ever implement them). The service is what would keep folks buying into the program. I assume there may be some free access and other access that would allow additional services (much like the other creative collaboration services popping up online). The primary process is one of notifying folks that the project owner is looking for assistance on a project. This is where they specify that they need 1 modeler, two textures... whatever... at a given time on their project. A percentage bar then lets everyone know how the project is progressing so they can view its current status. A popular project might have a multitude of people wanting to join in while a lesser known project might struggle until it finds a proper champion or someone that can help get the project off the ground. What's in it for the folks behind the scenes is another question but the underlying answer for any business is always going to be profit. Profit potential can come is a number of varieties but I'd say this is in line with where the authors believe animation content is heading; which they state as moving more toward social collaboration. For those that don't care to read their FAW they also state "Artella will be free to join and cost a low monthly subscription fee for projects, we do not plan to offer discounts as our goal is to make it accessible and affordable to all." The primary thing Artella has to do is pay for its cost of operation. If Animation Mentor can use it as a recruiting tool then that might also keep costs down as it can be reasoned that a good number of the students at Mentor will be likely to join in projects posted to Artella. My projection: If a good number of paying gigs (perhaps initially sponsored by Animation Mentor) can be maintained then it should prove to be quite popular (folks would get involved in free projects and vie for positions in the paid projects. If others (individuals and companies) routinely sponsor paid projects on the site it will be successful and especially useful for project collaborators. .This isn't to say that much could be gained by joining in on the free projects but we must remember that a goal behind the effort is to profit; yes for the folks behind the site would surely like to make money but they won't make any if the system doesn't find a way to for the creative talent to profit. Artella will not be paying any of the talent. That is up to the owners of each project. The added aspect of course is that profit (on the part of the collaborators at least) doesn't always equate to money. For the direct info: http://artellahq.tumblr.com/FAQ

From the folks behind Animation Mentor (Bobby Beck, Shawn Kelly and Carlos Beana) comes a new online collaboration platform; Artella. There's not a lot of info at present but the Artella FAQs suggest the goal is to make it something of a GITHUB for creative projects. One of the primary motivations appears to be that many folks want to get involved in creative projects but not everyone can do that for a living (i.e. there are only so many paying jobs to go around). What do you do with all that knowledge and experience? How do you keep from losing motivation? What exactly do you do with your talent? Additional info: - Creators maintain all rights to their projects. - Project content is stored on Artella servers. The big question is how much will belonging to Artella cost? No word on that yet. Artella plans to go live in late 2015. http://www.artella.com/ (I might need to start a separate forum area just for all the various online collaboration services that are popping up these days)

That's certainly good news. Willi said: I believe the hope is that Subdiv techniques can eventually fully perform this process. The detailed mesh would then be an aid to the simple mesh and vice versa. The goal being to automate the process so that no one has to do it manually.

Brendan just uploaded an Alpha 6 that fixes the After Effects issue so all is well in NOXland. I'm going to experiment with various workflows and if I come up with anything worth sharing I'll post it. As most folks don't have a means to play MOX/NOX files yet here's a converted sampling that was directly run through After Effects to Premiere and then out to MOV (with a few minor adjustments at each stage to ensure changes in each application worked: alpha6runthroughAEtoP.mov

Sure is.

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!