Rodney

There is an interesting trend going on in business these days and it appears to consist in large part of targeting the human element at it's weakest point to make the sale. (In a way there is nothing new here however. It's just being done on a global scale) The recent (I think classic) example of this might be of Disney's purchase of Lucasfilm. Lucas was recently reremarried... considering the path he should take with young child in the nest... where to focus in his old age... considering his mortality... his legacy. Disney strategically moved in and took full advantage of this and gave Lucas a timely solution to all of these needs. On a lesser scale the sale of Arnold to Autodesk echos a similar sale. (According to the article) The owners father was working well into his retirement. The owner was overworked and distracted by the business side of things... no time for his beloved R&D. The human element... mortality... waiting in the wings. Autodesk strategists stepped in with a solution that answered all of those needs. It's not hard to see where things are going based on current trajectories but considerably more difficult to chart paths that constantly change. The danger of corporations is that they don't (corporately) have the flaw of mortality flowing through their veins. As such those that aren't similarly incorporated eventually find they aren't playing at the same game. And it's all a bit like animation itself where timing is everything.

You may want to consider the source of that information as suspect. Somethings doesn't sound right. According to the guy in charge himself (from the article): Perhaps your source just stated Arnold wasn't sold publicly. There is that a lot of the high dollar products in the animation industry that have no set price (more in the past... still a few nowadays). With those all prices are negotiated on a case by case basis with the company deriving a majority of their income from consultation (service and support) fees. When we see 'contact us for a quote' as the only price listed we can be reasonably sure that the price is out of range from the average person of interest. But this isn't true across the board because the company gets to determine what that person can bring to the table. That quote might consist of a trial phase an educational offering a contract to demo the product... to wear a tshirt... whatever. But the purpose behind the process is clear... the company is in business and has to manage their products and services to stay in business. (If free) It would be a lot easier (for them) to say 'Arnold is still free but by invitation only' or whatever if that was the case. But instead they mention (without detailing specifics) about sales. This may be true to a large extent. Businesses can be ruthless but most strategic plans don't involve removing all competitors entirely from the field as that leads to an environment/industry that cant even sustain them. There is little doubt that they want to have freedom of movement in any domain they wish to reign. The bottom line here would be that Autodesk operates at the strategic level. They are in it to win it. Companies that don't have such strategic plans may find themselves in for the short gains. Not clueless but definitely biased. Mike Seymour does a good job of trying to look outward into the industry but one must remember that fxguide (and therefore Mike Seymour) has close ties with The Foundry. Most of what is reported there will come through that perspective. This is why Arnold's top dog takes extra time to reassure the articles's readers that 'nothing has changed' and that Arnold will still support other products to include Katana which is a premium product of The Foundry. In all cases bias must be considered. We tend to be biased toward A:M around here... we focus on the positive rather than the negative... same/same. Personal aside: I think Mike does an excellent job reporting for fxguide and Wired magazine online about the animation industry. He may be biased but he's also a smart guy. But regarding any real or potential PR BS... well, yeah... Mike Seymour is an industry spokesman; the consummate PR man. But clueless? I'd have a hard time buying that. (Disclaimer: I don't know what laws exist in the land down under concerning publicly traded companies but it might relate to 'insider information' that lets a select few individuals (usually those with shares) in on financial deals before the public gets access... thereby raking in the profits that would otherwise go to everyone... or mitigating/transferring losses by leaving everyone else holding the bag while getting out of the game. There are certainly laws against such in the United States). I'll note that that is not a law or anything, that's just some absurd PR BS the clueless reporter swallowed.

The first thing we might do is compare current import/export plugins with those of import/export available in FBX for other programs. It's a lot like animation itself... in point... out point... break it all down in the middle. Then refine the performance. I'm afraid I don't see a lot of folks lining up to take this on however.

I'm wondering what difference there might be between an averaging wizard and a circularize wizard. I would guess the circularize wizard would use all of the CPs center as the origin from which to average the spacing of CPs around the splne from the average distance away from that point. Whereas a simple averaging wizard would attempt to maintain the same spline but space the CPs out along that spline at the same distance (like the plugin Resample Spline does). This makes me wonder if the Resample Spline plugin (or at least some of it's code) could be used in furtherance of a Circularize plugin. Similarly, if the Resample Spline plugin could be enhanced so that it could leave a spline in place but move the CPs to a new location (average distance along the spline) that might work also. Regarding FBX import/export... I don't think we'll find anyone that doesn't want an FBX plugin so I'll third that one. Question is... how do we get it done? Who do we hire/kidnap/invoke? What does success look like? (I think I've asked this before) If moving in stages from success to success... as an initial FBX plugin, will import of a mesh (without textures) be sufficient? I ask this because if someone tries to tackle this that has to learn from scratch that would be a logical milestone. The next milestone being to reverse the process and export to FBX (also without textures and animation most likely). Milestone 3 then would be to get the import of textures to work. Milestone 4; textures exported. MIlestone 5, basic motion transfer (translate, scale and rotate) Milestone 6, complex motion from a known origin* etc. All of this assumes that an indirect path to FBX (i.e. OBJ and MDD to FBX and vice versa) might not be easier to code. Currently I'm not sure A:M can even reimport the MDD files it exports.... so that might be a logical first step to conquer. For reference here is some basic best practice FBX info from Unreal Engine to consider: https://docs.unrealengine.com/latest/INT/Engine/Content/FBX/BestPractices/index.html and here's a link to the 2017 FBX SDK: This contains sample import export programs for Visual Studio. For someone well versed in Python it may be that the FBX Python bindings will prove useful. *The issue here being that FBX has only recently began to solidify rigging standards and so those are still evolving. We might therefore assume a basic motion capture format such as BVH as the norm although I see some standardization on HumanIK 2016.5.

I'm moving this topic up to the main Animation:Master forum because it's buried down deep in the SDK forum. We'll have to look at what other truly A:M-related forums are buried too deep and move them appropriately also. And to add another plugin idea... one that might relate more to being a feature... It could be useful to use GPS data to position objects/images in 3D space. I'm not sure how this would work relative to virtual space as well as imaginary spaces such as the city of Zarz on the planet Xeomopline. Perhaps there might be a variable preceding the lat/long values that are used to provide an origin, scale, or to suggest if the object is within a set of visible ranges from other UPS (Universal Positioning System) coordinates. How exactly does one use GPS in space or on Jupiter?

Autodesk has gobbled up yet another company. This time the makers of the Arnold renderer, Solid Angle. Here's an interview delving into the decision to sell to Autodesk (the owner and originator of the Arnold renderer) courtesy of MIke Seymour at FXguide: https://www.fxguide.com/featured/autodesk-buys-arnold-2/ Two primary takeaways: - This will be the first time Autodesk has an in house high end renderer (other renderers have been licensed. Ex: Mental Ray/NVidia) - According to the article "Rendering is certainly one of the hottest areas in 3D right now". This no doubt ties in with Autodesk's longer term plans for render in the cloud. Recent deals like the one with Google and ZYNC underscore this.

It'll take a bit of imagination to consider the potential but the following video tutorial by Greg Smith demonstrates some useful workflow in OpenToonz. It can help to think of images rendered in A:M in the place of the hill he draws and the ball he animates. Of specific interest is the path he draws that is then used to direct the animation. This same basic workflow can be accomplished in A:M but it can help to prototype that workflow elsewhere and then tailor the workflow to fit more perfectly in A:M. xhttps://www.youtube.com/watch?v=eIIMh2PVc2A This should also demonstrate how a program such as OpenToonz can be quickly used to storyboard and plan projects that will be modeled, textured, animated and lit in A:M.

Times are certainly a-changing... It's worth noting that by at least one account, not long ago Toonz would set you back about $30,000 per seat. (or rented seats on a monthly basis for about $600 each as of Toonz 5.0 timeframe) Now here we are in 2016 with OpenToonz available for free. OpenToonz now has nightly builds for Windows and Mac as well as access to source (not sure about Linux). This can be useful if staring at something that doesn't appear to be working but has been tagged for fixing. It may have been fixed but is just awaiting the next official release. Someone with a talent for programming can also examine the source to shed more light on outstanding issues. For those with the time and interest, I recommend the current nightly build over the initial v1 release and the subsequent v1.01 update as it replaces a lot of code that was set aside by Studio Ghibli, which formed the majority of the initial release of OpenToonz. The reason for this is that Ghibli worked mainly from paper with a team of animators, inkers/painters that each had customized 'rooms' to work in that didn't distract them from their task at hand. The elements not needed were still in the code but hidden. Now the initial set of those features has been replaced. So creating and storing customized rooms can easily be accomplished from within the OpenToonz interface. Don't like the general layout or workflow... change it. If previously installed you'll need to uninstall OpenToonz first before installing the nightly build. Installing over the top of previous setup will likely not work. There have been three releases to date (if you count the nightly builds as one): https://github.com/opentoonz/opentoonz/releases

This is something I'd like to delve into at some point but I currently don't have enough data to present. The realities of filmmaking are increasingly making it difficult for everything to pour out of a renderer fully formed. This relates to some of the recent changes at Disney where the Hyperion renderer was built from scratch in short order which was then used in 'Big Hero Six', 'Zootopia', etc. rather than Renderman, etc. What this makes me wonder about even more is how the dynamics work between PIXAR and DISNEY... not to mention other production houses (Dreamworks, Weta, etc.) who are in competition (or riding the coat tails of) the Disney juggernaut. Specifically with Disney/PIXAR though is the question about Research and Development and how elements of one inform those of the other. And with Disney's purchase of Lucas Films a ton of technology and experience has rolled in house that wasn't accessible before. And... we haven't even seen the next wave of films that propose to advance filmmaking more such as the next four Avatar movies... and how they've taken root with Disney too (in a way taking on the place of Lucas Film's Star Tours attraction after all that moved under the Disney umbrella). I don't know enough at this point to know what I don't know. PIXAR is certainly trying to project that they are fully invested in Game A. I've seen relatively little behind the scenes evidence released to suggest the contrary. I do think they shifted some significant focus near the release of 'Wall-e' and this was accented by their (rather odd IMO) decision to include live action characters in that movie. Their need to connect the audience with reality appears to have compelled them into Game B territory in order to make the common-humanity-gone-to-excess throughline of the story work. This sounds to me like you are attempting to be in Game B environment but with a Game A approach. Game B by it's very nature needs to be modular, scalable... open. Game A is, by comparison, modular, scaleable and (mostly) closed. What's the difference? I'd say mostly of inputs and outputs. The example of this in A:M would be that of textures. Textures certainly can be created in A:M and in fact they could all be created in A:M but that might be costly so A:M allows importing of external images for that purpose. Here then is a logical entry point in a Game A scenario. Textures of all kinds can be photographed, drawn, painted, created in almost any form for use as images in A:M's native environment. As is often the case... garbage in/garbage out... it's important to consider what foreign matter is being introduced into the ecosystem. The same can be said doubly (triply?) for meshes made in other programs as A:M is not optimized for use as a Game B platform. A slight caveat should be inserted at this point because A:M does work well with other programs but only as well as the differences between these programs inputs and outputs are understood. This is the same with every program. I like both Game A and Game B approaches. The one I tend to prefer is that which is currently (or optimally) working.

Whoa. Grandma needs to settle down and consider who is watching her! That's a very nice shot Simon. I like. There is always some finessing that can be done. Little things that might please an audience...even if only subconsciously... upon subsequent viewings. My thought would be to get some added emphasis on the bike to suggest weight. This might include any/all of the following: - A noticeable drop of the bike while the wheels either don't move or squash and stretch. I'm not sure if the bike is rigged for that. - A sharper movement at the very end where the bike drops would be nice and perhaps suggest the squash/stretch/impact even if it isn't there. In other words, the ride into the scene is nice and smooth.... as is the movement across the screen... as is the final landing... as is the stop. A little texture in the movement would aid in suggesting the reality and weight and forces at work. In reviewing the shot I can see some slight indication of this momentum shift but perhaps it could be exaggerated. Which leads me to... - Some anticipation and follow through on the part of Granny would be nice. For instance, Granny could be up just a bit more on the pegs of the bike (straighter) as she rides into the scene but then her knees bend down as she sits and lands. This movement would also assist in selling the element of weight that squash and stretch is often used for. I realize that this might require drawing Granny again... very not good... so the standing vs sitting as she rides in may not be an option. - Either some slight movement up/down or right/left to suggest Granny is controlling/resisting the bike's movement. Aside: What you are doing here relates to why I got into 3D in the first place. I knew it was going to be difficult if not impossible to draw things like motorcyles over and over again from altering views and 3D modeling and animation could most definitely do that. Bottom line: The point of the shot appears to be clear. Grandma has arrived at her destination. Well done!

The current forum banner (over the Latest Info forum) is a single frame from a 500 frame sequence rendered straight out of A:M with one exception; it was resized (to a lower resolution) in an image utility called Irfanview. Where I have the option I prefer to use images rendered directly out of A:M; this is something of a 'purist' view. I would relate this to what most would assume is the approach of PIXAR which is to forego any compositing, post production etc.; what comes directly out of the renderer is what will be used. This is the A game of animation. The ideal environment in which to produce. The B game is what most of us tend to use if for no other reason than practicality. I'll call it the new-Disney approach. It might better be called the Hollywood approach or Summer Blockbuster... everyone is doing it. And we enjoy this power of tweaking and adjusting, cropping and recoloring, recombining and generally re-purposing our resources. This is what I tend to use other programs for; initial setup (if needed) and finalizing for presentation. The attached is a rendering out of the newly open sourced program OpenToonz. Technically, it could be called a re-rendering. All of the imagery is still that which was rendered directly out of A:M but only five frames are used from the 500 frame sequence. The closed egg being exposed for the entire duration of the animation (almost as if it was a background) with the other four images superimposed. There are a few settings that didn't get adjusted correctly; the width of the camera's view is slightly too wide. I re-rendered in OpenToonz with a slightly smaller camera view to get all of the banner into view. The timing is not optimized; frames were exposed where I thought they might work and for as long as I thought necessary to be viewed. No optimizations or post processing to smooth or ease in/out. No multiplane camera moves. No recoloring. No film grain. No bells. No whistles. Just the retiming of five images rendered out of Animation:Master in OpenToonz via it's exposure sheet. Certainly, this could have played out in another fashion; the various elements of font, egg, duck, and ground could have been rendered out separately and composited together. This can be a very useful approach if you know particular elements of a scene will change or need to be re-purposed. Perhaps the show might play again but this time with some other character/animal emerging from the egg. Perhaps the logo might change or fade in/out... and on and on and on. I am always in a constant state of conflict between A and B; rendering everything directly out of A:M versus tweaking everything in post. It's not one of those conflicts like warfare though. It's an effort to render better imagery and perhaps even learn. It's like animation itself; working from Pose A to Pose B seeking the perfect breakdown position that will yield the absolute best performance in support of our stories. out000 shrink 4.mov

I don't really need one of these but I WANT ONE. xhttps://www.youtube.com/watch?v=9Pl7xM6atCQ I don't see an anticipated price yet. Sold only through resellers a this point. 96TB of capacity on the desktop up to 2600MB/s speeds RAID 5/6 Specifically designed for use with data from 4/5/6K cameras. For those with the need you can sign up to win a free one here: http://textseagate.com/nab/signup/

One example of a Pose that you would typically want ON by default is a Pose the contains the constraints that make the rig work. Ha! Now we've gone full circle. Yes, exactly. That was the source of great confusion with The Setup Machine all those many years ago which was my introduction to the underlying problem in the first place. I could not understand why folks would want to continually answer newbie questions about why a TSM rig wasn't working with the same answer over and over again, "Turn on the rig's constraint to turn the rig on first." Say what???

This is one of the reasons I was looking at containers like Brendan Bolles's MOX. If I understand correctly, it (and other similar containers) can store sequential images (compressed or not) in a variety of formats and with various codecs. It seems like an ideal approach but I don't have a deep technical understanding... my understanding is on the surface only. MOX/NOX is currently at the point where the Dirac codec is being optimized for use and that leads to considerable compression/quality ratios. A downside of MOX might be that it currently appears to require a plugin versus native processing in a given application. If MOX code is shared widely though perhaps code could be executed internally without plugins. MOX is also more of a production container... I don't know what potential that presents for distribution, presentation or live streaming. That doesn't appear to be its purpose. One thing may be certain, companies will look to see if there is an opportunity to make a profit from the end of Quicktime on Windows. Where there is potential for profit there will be movement. Development on MOX has slowed of late primarily because it has achieved the goals set out in it's Indigogo funderaiser. Perhaps the removal of Quicktime for Windows might encourage new activity with the format. A few months ago a poster from Swordfish posted this comment on the MOX discussion group related to Dirac compression with MOX: Although, it looks bad when every site related to the Dirac codec is missing/disconnected.

Yes, indeed! Although I perceive two 'problems' so I'd parse that as 'one of the problems' rather than 'the problem'. Thanks much for the insightful look and documentation of what is going on. This is an important element of the bigger picture (beyond the issue at hand but moving into a future state of even better understanding for average users and workflows) so I want to 'note to self' for that purpose here. I think it's important (although hardly so from a practical purpose in production) to move beyond things like 'T Poses' where models arrive in states that are 'unnatural'. Getting a model into what one might consider a 'golden pose' or even set of poses that help define 'character' (I think) is important. This may be especially true for shared resources, although I should caveat this with the statement that I don't think the originator of the resource is in any way constrained to get that resource into that optimal state/pose. Their primary focus is the initial design and potential (the modeling if you will) that allows for optimal animation. I'm stepping a bit far afield of the topic to further this idea a little more. Take a character such as Keekat for instance or several of the other characters that come standard with A:M and that are featured in initial tutorials. Keekat has one pose slider called 'Dynamic Pose' that demonstrates basic articulation of the model and (presumably) is designed to suggest character and performance. woo boy howdee... now that's what we are talkin' 'bout. Moving beyond the model... moving beyond the potential... moving into the realm of animating character performance (or at least one extreme pose on the way to that end). This makes me wonder... What downsides might there be to saving a character such as Keekat out with his dynamic pose turned on... thereby storing that pose so that it's automatically activated upon opening in an Action or Chor. The pro response might be to suggest that it is easier to start from the T pose rather than from a more or less random pose that may or may not be anywhere in the ballpark of what the shot/scene at hand calls for. I'm not convinced. I *think* we are looking more for a state where the character is 'alive'. The character 'learns'. The character presents better options to the animator/director to choose from from those that (currently) define its character. Put another way... Why would we want to preset a pose with any given setting in the first place? Why define a percentage pose from -100 to 100... 0 to 5... whatever? Why set a pose to on? When would it be better set to off? I submit that it's because there is an anticipated purpose... a framing of potential outcomes... a 'set' of environmental variables to aid and direct us in our future work.

I"m starting to get a list of things to run through Live Answer Time on Saturday. It's not that it doesn't save. One part of this is that the result of that state doesn't appear (in the Modeling Window (i.e. while it does appear in a Relationship, Action or Chor window). This is to be expected because Models aren't dynamic and Mark clued me in that this may be more of a workflow issue. I might be occasionally expecting to see a result in a Model window when it's not designed to be there in the first place. What I need to do on my end is put together a couple use cases that basically state (This works this way. This works that way. This way isn't working as I had anticipated... or isn't working optimally. Etc.) That would also cut down on any ramp up time during Live Answer just defining the issue and getting everyone on the same page. As interested in smoothing this one out as I am though I've got several other questions of more interest to me personally I'd like to pose during Live Answer and they might be of the variety where the question is introduced at one Live Answer Session so that it can be addressed in a future session. Actually, the following might be the 'concise' set up and question regarding the issue because it is something that is observable and repeatable: Robert said: In a Percentage pose we can Right Click and select 'Settings' to assign default values but... In an On/Off pose the 'Settings' option is not available. This may be the cause of my confusion because after using that option to set default values in a percentage pose I try to do the same in the On/Off pose but can't... in the same way. The logical reason for this is of course because there are (presumed to be) only two states the on/off pose can have (although there are actually three state); on, off and not set. But at any rate, the workflows of percentage poses and on/off poses are different enough that depending whether the Model is saved and where it is viewed the pose may appear not to have worked. Nancy provided an initial piece of the issue that I originally skimmed over (that of Saving) and that is an essential element to storing the persistent state. Therefore the step can't be overlooked in the workflow either. Gerald provided another piece of the puzzle by demonstrating a known workflow that doesn't apply universally; the Setting option is not present in an On/Off pose while it is easily accessed (and obvious!) in poses with percentages. I've found it fascinating that the word 'confusion' has surfaced on several fronts because those with experience are well established in workflows (that workflows that work that is) whereas on my end I've mostly just been bumping up against trying to repeat the exact same steps where those steps cannot be re-stepped. The approach/workflow is different.

I just returned from seeing the new movie and... This is an impressive movie on many levels. What perhaps surprises me most is that I didn't think I would enjoy it as much as the original animated version that is such a classic. No spoilers here except to say the film remained faithful is significant ways to the animated film. I was surprised by that too. Two other things that was a bit wary of going in but turned out to be just fine and well executed: - The film intentionally exaggerates scale on and they work that element like it's almost a character itself. As such it enhances the experience in significant ways and enlarges our view of the jungle especially from Mowgli's point of view. - While the film did have 'learning point' they were pretty seamlessly woven into the fabric and flow of story which is something few films succeed at accomplishing. Disney has hit on a very interesting approach of late that is well worth looking into. The last movie that I thought pulled that off well was 'Zootopia' which could have gotten bogged down and preachy but managed to avoid that. And make sure you stay for the end credits... those were as impressive as the film itself.

Doh! I just had one of those painful reminders that we should save often and save with incremented filenames/numbers. I had spend entirely too much time modeling a character when I thought to save the model. All is well. Then I began to adjust the color of groups in the model. Everything working fine. I'm really starting to like the progess of the model. Then I accidentally enlarged a group and it took over another section of the mesh, giving it the wrong color. A quick undo didn't work as anticipated and then I deleted the entire mesh except for the eyes.... Gah! No problem... I can fix that. Then... My fat fingers and dull mind accidentally Control Saved the model... OVER THE TOP OF THE PREVIOUSLY SAVED MODEL! GAHHHHHHHH! Very not cool. I should have saved again with a number appended to the filename. Then I'd still have my original. Perhaps I should remodel this thing while the topology is still fresh in my mind.

Not seeing the results in the Model definitely throws me for a loop every time. This may just be a matter of getting use to a particular workflow but I just tried a new pose (for a different test) and thought to also use it as a test to see how the default pose would work. I set everything up, saved the model and opened a new (empty) project to import the Model into. Upon opening the Model I see the results in the Model Window as if I hadn't set up the pose, although the Pose itself shows that it is set to On so 'should' be showing. To complicate matters, no Pose slider is showing in the Pose window... I must go to User Properties to see the pose slider. (That should have been a clue) Then I remember to open the Model in an Action and BAM! Sure enough the pose is on and displayed accordingly. Almost there but not quite. More staring at this is required...

Good thinking and an even better theory. My initial test didn't work but subsequent tests did. I'm checking again to find out what I changed in the process of testing. Choosing 'Constant' shouldn't matter though as that is the default so whether on or off constant is selected (unless manually set to time based... haven't even thought to try that... yet more variables/options). One odd thing I did note is that after saving as you suggest when the model is opened the pose isn't set to the last saved constant... in the Model... but as soon as the Model is opened in an Action the pose turns on (or off) in accordance with the setting saved prior.... in other words, correctly. This is in accordance with your memory of how it works. If this is always the case, which it appears to be, this may be a 90% solution. The only downside being that the desired default is not 'activated' in the Model until an Action or (presumably) Chor Action is invoked. This is a bit odd so I'm trying to lock my understanding of what is going on down and I'll bump this result up against prior tests and desired outcomes to determine what gaps remain unresolved or if I've inadvertently reframed my original target. There are some variables I still need to account for. Sorry for all the text but I'm documenting what I'm doing so I can repeat the process. Here's what I'm seeing at present: (Aligned with what you've suggested) I've created a simple 3 CP spline Model. Set an on/off pose where on turns the spline into a smile and off turns it into a frown. Set the pose to on and save the Model as 'smile.mdl'. Set the pose to off and save the Model as 'frown.mdl'. Open a new project (this is to make sure we are starting from ground zero with no pose data left in memory or a chance to inadvertently be in the wrong window) Import smile.mdl Import frown.md Note that -in the Models- the pose sliders correctly display 'On' (for smile.mdl) and 'Off' (for frown.mdl). The disconnect here is that looking at the screen wouldn't tell you this because the three CPs are in their original position in a straight line neither smiling or frowning. Again, this in in the Model view. Open a Chor (the same thing can be done via Action) Drag/Drop both models into the Chor Note that each model activates appropriately in the Chor (or Action) with Smile.mdl smiling and Frown.mdl frowning. A few additional notes Within the Chor the poses are now set at Use Cache Value instead of Constant. This is fine as the poses have appeared as desired. Setting to Constant merely locks those down. I find myself wondering if viewing the pose in the Model might not be a refresh issue but it appears to be the way it is designed to work (i.e showing the default pose of the model without regard to any pose settings. In the case of a character's T Pose the assumption being that in the Model we'd see the T pose but as soon as opened in an Action or Chor the Model would change to the default pose stored in the pose slider(s). Thanks Mark! You've given me another important angle to investigate. Now I have to investigate with an eye toward making sure I formulated the right use case/need in my post above. There I stated: From what I can tell this is be resolved *after* the Model is opened in an Action or Chor. While in the Model mode the poses appear to be correctly stored and just awaiting activation. (Stored potential.... I like it!) I need to better understand how this relates to Drag/Drop poses as optimally (and originally) intended to work. I should be able to rule out a specific need for (default) poses to appear (i.e. be active) in the Model view. At the moment, other than for aesthetics and perhaps to prevent confusion of the 'hey, I thought I posed this model-variety', I can't think of any specific case where that would be required. Aside: And if there is such a need, why are the poses in the Model not initially seen/active. Obviously, I also need to test on more complex models.

Still have to test the percentage on/off switches further as I'm getting inbetweening where previously I hadn't seen any and thought I'd be getting all or nothing results. A workaround there would be to specify smaller increments which while it won't remove inbetweening will make it negligible. Example: Default=.1 Minimum=0 Maximum=.1 ... On the plus side this actually aids in the pose to pose approach to animation in that we get the extremes easily and then refine the inbetweens intentionally (and if desired even mathematically).

Robert, Results from my quick test suggest.... that wont quite resolve the issue. For a second I thought it might. But we may yet turn this weakness into a strength. Taking a look at the percentage on/off option... In a world where all poses are percentage poses an on/off pose can be created by setting 0 as minimum and 1 as maximum. An important setting is the percentage however. That needs to be changed to 0 because if left at 100 my understanding is that will result in percent increments between 0 and 1. (which could be useful also) Setting the percentage option to 0 though results in an either 0 or 1 result which is exactly what we want. As of this moment, if a solution to the on/off defaulting doesn't present itself it looks to me like an all percentage pose approach may be optimal because on/off is a subset of a percentage between 0 and 1 anyway.** The on/off pose would then be used for generic poses that are assigned as 'not set' by default (i.e. a switch that is optimal for awaiting user input of the yes/no variety). **And all this time I had no idea A:M allowed us to create poses that leverage fuzzy logic.

Thanks! That's close Robert. I don't think it's a fix but certainly a work around. What we'd have to test would be saving the model out and then reopening and see if the newly assigned default is maintained in the process. Unfortunately, I don't think it addresses the main issue. The underlying need is to have any number of on/off poses set in the Model so that when they are opened/reopened in A:M the defaults appear as set and will revert to that default as necessary. This would be similar to that of setting the defaults in a percentage pose. And that presents another workaround. We can forego the standard On/Off pose entirely and set up a percentage pose that consists of boolean response; 0 and 1.... -1 and 0... whatever, as long as only two states are allowed. This would create the desired on/off pose whose default could be saved and reloaded. I briefly used that workaround once before. I'll look again at your video and double check to see if it doesn't provide a fuller solution than I see on first viewing. Easy enough to test. I'm curious if saving the Model out via the Chor saves the 'new' default in the Model or if it reverts back to original or not set.

We'll have to seek expert advice but as I understand it this isn't about the movie files... but about the Quicktime program itself. The program code contains the vulnerability not the files it produces. Hence the call to uninstall the program. Of course we can assume that a likely means of gaining access would be through files (movies) the programs opens but any executed code devised for that purpose would do. Perhaps it's time to get that A:M code for video editing out of mothballs. As this is likely a reference that won't resonate I'll offer this image of a feature none of us present (to my knowledge) have ever used. Disclaimer: I know that A:M can't have the code that it takes teams of programmers to maintain in video editors. I just ocassionally consider things that might have been. The timeline filmsstrip is only one of many features that had to be set aside for the greater good of all users (and greater priorities) back in the v10/v11 timeframe. Another would be the little 3D preview image that we could see and manipulate before opening a model back in that same timeframe.

This is something like a ten year old thing so I'm hopeful that a solution will float to the top. It can obviously take me awhile to get around to addressing issues but I eventually do. I vaguely recall using a text editor to test setting of the default but I don't remember the outcome of that. This was sometime around when percentage poses gained the abilty to go into larger ranges than 1 to 100 and allowed negative percentages.