Rodney

That was useful (the tip on turning things off in Settings/Privacy) Microsoft should have turned the majority of those settings off by default and asked users if they wanted to opt in upon installation; the goal being to get folks to upgrade/update to Win10 not sit on the fence wondering if it's the right move to make. That would have eased the minds of a lot more folks who are wary of such things, not to mention the potential for bad press when those that oppose see opportunity to sow seeds of discontent.

Didn't have to reinstall anything (no programs, apps... zilch) as they all appear to have made the transition automatically. I did update Adobe CC shortly after updating to Win10 (because the manager said updates were available) but none of those updates mention anything about Win10. I would imagine that companies will release updates to take advantage of Win10 so won't be surprised to see them. That's interesting. From my days as a workgroup manager I often opined about how nefarious types could circumvent passwords and it seems Microsoft has used that exact same strategy to enable them to do just that. Wheels within wheels. There are some aspects of this that I think are 1) inevitable 2) advantageous. Inevitable in the sense that in a perfect world there would be no passwords (or at least not of the form we are accustomed to using) and advantageous in that where no passwords exist a freer exchange of resources, information and ideas is enabled. And I'll add, also inevitable in that the folks in power need that framework in place to move to the next stage of where they are heading I suspect that we haven't heard... 'the rest of the story'... of Microsoft (and the general push from just about everyone) moving toward authentication via methods other than passwords (images/parts of images/captchas, biometrics (fingerprints, eye scans, voice recognition), etc.). This surely will play into this 'your password is shared with everyone scenario'. This is both good....in that validation of who we are in a transaction is important... and bad... there are many times we prefer/desire not to be known as involved in a transaction. There is a very fine line to travel inbetween those two extremes to find optimal parity. But consider this; if you can know for a fact that I stole your wallet (the one you left out on the front porch next to the jar full of candy and a sign saying, 'Please help yourself') as well as when I stole it and where the wallet went thereafter, might that make a difference in how much you care about sharing passwords?. Bottom line: Remember passwords are an artificial construct that makes us feel safe when in fact we aren't safe from those who know how to circumvent that password. Translation: I ain't scared although I surely I should be.

Love the style of that last image!

Back awhile I was going to post some info related to moving your files from older After Effects into current release but for a variety of reasons didn't post that info (specifically, I don't like to spend other people). I assume you already know the ideal upgrade path and prefer to maintain your older software as well as preferring not to move to the current Adobe CC subscription. All cool. If that isn't the case just say the word and I'll provide what little I know. One thing worth looking at is Adobe's move with the new subscription to enable older versions to operate. It won't go back as far as yours but if it allows the right middleman version to update your files may be well worth it.

Well, it wasn't released yesterday (yesterday's yesterday that is). But to circle around the question to hone in a little more on likely answers. Firstly, I assume you are referring to my earlier attempt to install back in May (and not literally yesterday because it never did not work yesterday so... invalid question). Back in May I started the process by signing up for the initial early release candidate to get a feel for what the final release would operate. Parts of that downloaded and parts installed. Somewhere in the process the install wasn't sure it should go forward and gave me the option to continue. I chickened out** and stopped. So, Windows restored the previous install. After that I tried to make sure that all parts of Win8.1 were updated to the latest updates before initializing the official Win10 install. I think updating those helped and normally I might not install those but didn't want to take any chances on interim fixes being missed. So the update from a fully refreshed install of Win8.1 to Win10 was pretty straightforward. It did takes some time... I'm not sure exactly how much time as I started the install and didn't get back to my computer for about 10 hours. After returning I finished the install which took about 30 minutes. That's my story and Ima stickin' to it. *By chickened out more accurately I mean to say that I must have selected an option that stopped the earlier install. Techically, I didn't know that I'd chickened out but was quite relieved when I found myself back at my old v8.1 desktop. Win10 doesn't look a whole lot different from my old desktop.

There are a lot of folks writing/blogging about the changes so I won't try to itemize it all. The main thing that appears to have changed is Microsoft approach to remaining relevant in an age where competition is brutal. This is signaled primarily by the introduction of Microsoft Edge which is their move away from Internet Explorer which has lost ground to Chrome, Safari, Firefox, etc. and will likely continue to lose ground. It's not entirely clear what Microsoft plans to do in the short term with two browsers; indications are that Internet Explorer will be dropped. Cortana (which is Microsoft's take on Siri-like personal assistants) I have mostly ignored to this point but it does demonstrate Microsofts recognition that such personalized yet automated services are gaining serious traction as mobile platforms continue to make computer users out of everyone. It's this last element that of mobility that has caused a major shift in the market as the space once maintained by technical-types gives way to new generations that have grown up with access to internet connectivity. More simply and superficially Microsoft has taken a step back on it full push into mobile in that it realizes that it moved too far and too fast in it's effort to ditch the desktop; alienating a large part of their customers with it's removal of the start menu that everyone who had ever used WIndows was well accustomed to. I've been using Win 8.1 so had access to a proper start menu but was always dismayed by the extra steps necessary to get to programs I wanted to use. Does Win 10 address this? Time will tell. First I have to unlearn some of that workflow established in 8/8.1. There are some promising changes that might relate to A:M, like DirectX12, but I'm not sure how that all plays because with recent releases of A:M DirectX has been out. OpenGL is working so well on my system at present I'm quite happy to leave it out. So the answer to the question of what has changed approaches both 'everything' and 'nothing'. With Win10 I'd say Microsoft is primarily laying the foundation they wish to build upon. Added: I have read reports of numerous bugs (and anti-Microsoft rants) but thus far I haven't ran into any of them. The one of most interest to me is a copy/paste bug because I use that a lot but again... I haven't run across that in the wild. As a lot of A:M Users dual boot into Windows via Mac it will be interesting to see how that works for them.

So this morning I launched the Win 10 update and... It's up and running. So far so good.

As I recall something that will kill glow around the edges of objects is rendering the object with glow with alpha channel with nothing behind the object. This is generally something people don't like... they want to see the glow emanate out past the object but in your case you may want it to stop at the object edge threshold. The workaround to fix to get the glow is to put a solid shape (a plane perhaps) behind the object to prevent the loss of the glow so refraining from placing that mask behind the object should remove it all. If the mask is of a specific color then a chroma keyer can be used to remove everything but the object and it's radiated glow. None of this particularly relates to the banding issue but I'm including it for discussions sake as I try to understand what actually is going on with SSAO. Regarding the banding, perhaps if you crank up the number of passes with multipass that will blend out the banding more. There is much about SSAO I am unfamiliar with (I thought SSAO could apply it's settings to every pass of the multipass render but at present I don't see that option). There is an option to blur the SSAO effect which when combined with higher levels of multipass should soften out any banding considerably.

Assumption: The same thing happens wihen the SSAO is rendered out to diffrent images (rather than with the 'Add to Image' option on?

Interesting discussion. This makes me wonder if A:M's subframe rendering capability could be shoehorned into blending three thinner camera positions into one widescreen image. Does anyone know how Eggslice (Eggprops/Billy Eggington) handled the approach to stitching imagery together? (it seems to me that it accomplished it's feat by leveraging A:M's internal features) The approach to a Cinerama shot might be similar but would extend the process from a camera constrained in XY axis to one that rotates left and right. At a guess I'd say a 'card' placed in front of the camera to block parts of the screen might allow the superimposition of parts of the previously rendered and the anticipated subframes..

Okay you know this stuff already right? Because I'm a big fan of Right Clicking I sometimes forget about the ease of double clicking in the Project Workspace and use alternative ways that often add a few extra steps. The primary exception to the rule in double clicking in the Project Workspace is the top container (Project). As you are already in a project double clicking won't create a new project. In fact it won't do anything. When clicking on Image, A:M will prompt you to open an image. The same goes for double clicking on Sound. A:M will prompt us to load a audio file. Double clicking on a Material will create a new (default) material, ready and waiting for it's attributes to be customized. A good example of saving time via a double click is when creating a Post Effect. As with Materials, if we double click on the Post Effect container it will directly create an empty (new) post effect ready for the assignment of the Type of Effect we want. Right Clicking will get us there too (via the New option) but not as quickly as a double click will. There are some default behaviors that go with the double click to consider too. For instance, there are a lot of different types of Objects we can create (Model, Camera, Light, Null, Force, Motion Control Device, Layer...) but double clicking on Object will create a new (empty) Model. To create the other types of Object, Right Click and run through the available options (New, Import, Wizards, etc.). Once an Object has been created, double clicking on the next tier down (the Object itself) will open that object. Double Clicking on a Camera is an exception like clicking on Project. Nothing will happen. I suspect a reason for this behavior is that as with Projects we can only have one default Camera. We can add additional cameras by Right Clicking on Object and selecting New/Camera. At any given time while in a Choreography the view can then be set to a different camera (or even a light, which can be viewed from almost as if it were a camera).. Single Clicking on an Object in a Choreography will activate it (for animating) while double clicking it will open the original Object (for editing).

I will guess that you are selecting the Null from the PWS listing? Hmmm... I must confess that I am not smart enough to convey what I'm after here and a lot of this is due to my ignorance of the deeper side of Nulls, constraints, etc. I obviously need to approach this from another angle. Nulls have their uses but the elegance of manipulating a single CP is what I'm after. As for the attached gif animation... um... er... I'm not sure what it represents. It's just me moving a single CP around through time and space. Not shown here: Unlike Nulls or Objects that have been constrained/limited in rotation or other orientation CPs always face the viewer so moving them in Z depth works just as well as X and Y without CP scaling or rotation.

I'll investigate. The short answer is 'yes' but the demonstrable answer is 'hmmm... now how did I do that again..." Edit: Actually... it's easy to demo. If you accidentally select the roll handle of the Null then it will rotate. This doesn't appear to happen upon first click but with a second click. I'll see if I can prevent it. How are you creating your translate=-only Null? I assume the Null is part of a Model because, unless I'm missing something, Nulls cannot be limited in such a way outside of a Model.

In that particular case the desire is to be able to always grab a Null (or whatever) and not have it activate rotation. I note that even with limit manipulation settings set to only translate occasionally selecting them will rotate. This can be seen in most face manipulation menus and I recall it happening a lot on characters from TWO when animating via face menu. Perhaps it might be easier to ferret out why the controls allow for the behavior and submit that as a report but Nulls in general haven't satisfied the need. A comparison of grabbing a single CP and moving that around (in any dimension) versus any other object will demonstrate the differences in precision. This isn't to say that single CPs don't have their issues... sometimes they can be hard to click on individually and need to be marque selected (apologies if thats not the right term). One of the benefits to CP controllers is they are trivial to create in just about any configuration. I suspect that one of the reasons I like Point Controllers (Control Points that are controllers is that they always appear to face the user. There are other reasons to like CPs (prefer them to Nulls, etc. that is)... for instance we can stick/project a bunch of them to a surface just by projecting them onto that surface.

I ran an experiment with locked CPs that performed well but as I recall the main downside of that turned out to be that locking CPs is an all-or-nothing type of thing (as is hiding them). In other words, let's say a series of CPs was locked and then a second series of other CPs is desired to be locked. In th proces of locking the second series the first gets unlocked. I think the workaround at that time was to use mulitple models combined together in a Chor where dIfferent CPs were locked/unlocked in model. Then just pretend they are all in the same model. If theCPs were able to be locked in layers (levels?) that might have worked better but I can see how this could easily get out of hand with complex models.. I probably should log some kind of narrative that describes the purpose of the test because I don't have a clue what previous test was about. These recent tests were an attempt to create quick controllers that are easy to access yet very hard (ideally impossible) to manipulate incorrectly. I may have to revisit the multiple model angle again. It might be worth investigating that as Models can easily be Turned On/Off, Pickable/Unpickable, etc.

Yes, that's likely the workaround in the short term. The simple setup that demonstrates the premise is a single CP controller... a trivial example (click for animation):

I must be remembering incorrectly but... I thought when we hid Control Points in a Model or Project and saved the files they remained hidden when the file was opened again. Apparently I just imagined that because a test in an earlier version behaves the same as current version. I must be thinking of Locking CPs. Any thoughts or redirections? I've been using hidden CPs in some experimenatal ways but if they return to visible state when a file is reopened (after saving) that defeats a key part of the experiment.

You aren't talking about volumetrics are you? It doesn't look like you've got that turned on in your shot.

Looking vry good! No suggestions here other than perhaps to dirty up the places where objects meet (brick wall and ground.... trash can and ground). Perhaps that can be accomplished through rendering with SSAO (or AO) but mostly just to break up the smoothness of those lines. If all part of the general style then disregard. I've started four or five insect related images and finished none. Sigh.

If on the other hand you just want to turn Animate Mode off then click on the A (Animate) icon on the menu bar. This is where reversing the red frame can be useful as you can then have it warn you if Animate Mode is off (or on).

Hi Jack, Good to see you! It looks like you've got Animate Mode's visual red framing turned on. In Tools/Options on the Global tab make sure there isn't a checkmark in the option to reverse the Animate Mode warning. Some folks like to know whether what they are doing will be animated (creating keyframes) or won't.

For those that missed this offer before... The (free) express version of Hit FIlm 3.0 is available again and according to the press will be forever. And the full version of 3.0 is available as well. (For those that have Hit Film Pro already you may be able to upgrade at a discount) The folks that make Hitfilm are launching a new approach to distributing/selling their software that relies on the free version getting out to everyone. From within the free Express version additional components can be purchased as needed. Or... one could just purchase the full version with all those components. Of course the one component that I would require is the 3D component and although some press indicates Hit Film as the only free compositor with 3D capability the truth appears to be that the Express release cannot do that on its own. Purchasing the 3D component for the asking price (which I forget at the moment). None of this is meant to detract from the fact that Hit Film is very useful software and having the Express compositor is sure to be useful without the purchased components. So, if you don't have a compositor try Hit Film Express (and while you are at it check out their promo film "Portal Combat" which is a short and fun little film. Many of the assets used in the film are available for downloading): https://hitfilm.com/express

I'll add this because it might assist in understanding what I was talking about before with regard to current preview image implementation and changes I was exploring... The preview image container (in any Project, Material, Model, Action, Chor) is as follows: Width=97 Height=97 Version=2 a000 ... a000 Where entries after and the version and before the closing tag is a form of run length encoding of Base16 form Aside: From 'Hacking A:M', page 322; "A brute force method to generate this image data is to use A:M itself to create the data in a dummy file and then copy and paste the data from the dummy to the desired location." My suggestion to allow for an external file would take the form of: Width=97 Height=97 external=image001.png Version=2 a000 ... a000 If the external file exists the following embedded data would be ignored An approach that might allow for elements of A:M that are not individual files (Projects, Materials, etc...) might be as follows: Width=97 Height=97 Pose1=image001.png Pose1=image001.png Version=2 a000 ... a000 As this is a considerable extension of programming and how A:M handles preview image data I won't speculate further on how such a thing would be best implemented. The issue itself is not how the preview image would be handled but how this might effect the current implementation of Poses themselves. As poses are not independent files but are parts of other files they are handled differently. The solution might be explored by studying an Action that has a single pose contained in it and then extrapolating out from that to multiple poses. This would help us understand how best to approach display of multiple preview images where currently only one such image exists. Again, I do not think it optimal for images to be referred to externally. There are several reasons for this but I won't go into those here. Ask me and I'll be happy to provide more rationale. Optimally it appears to me that the embedded image would be used by default *unless* the presence of an external file is triggered. Aside: In this way a preview image could drive a very low rez decal without negating the optional use of a higher resolution image/decal if desired when rendering. For immediate realtime feedback, the lower rez image will always be preferred. Another interesting approach that would work although perhaps less optimally might be allow Preview Image data to be referenced externally. There would be several benefits to this approach as manipulations could be made to either the link or the external data. For instance, an external reference to sequential data: externaldata=pose000.eid (eid meaning external image data or external id... I'm not sure what an appropriate extension might be) Note that as with other A:M implementations of sequential data the trailing zeros would signal to A:M that we are dealing with an image sequence This image sequence could be animated but would more than likely allow previews to be incremented. Example: Pose1 would link to pose001.eid, Pose2 would link to pose002.eid, etc. As described above futher refinement, animation and assignments might be accessed through cropping (ala spritesheet-type assignment). In this way external data found in Poses.eid might contain all the previews for all poses but the data would be selected in similar fashion as assigning decals with UVs (but without the hassle of actually assigning UVs). Aside: This might relate to why Hash Inc was reluctant to release the Decal Editor as originally implemented and for some time was one of A:M's best kept secrets. They had much better ideas brewing and the Decal Editor as originally implemented did not fully support the desired/optimal implementation. The good news is that it's much closer to that today. This is a long way of saying that code is so well integrated in A:M that one feature implemented in the code can (and does) contribute to the well being of other features. I belabor the point of looking deeply into what is there under the hood now in order to suggest that as we move forward we do so not thinking of new features in isolation of each other (or how they are implemented in other programs... although that can and often does provide the spark of useful ideas that leads to even better implementations with spline/patch technology) but in consideration of the greater parts that make up A:M as it is now and what it will be. Thinking this through the realm of macro and micro views isn't easy and a far cry from the utter simplicity of 'I'd like preview images for my poses please', aint it? Get that report into A:M Reports so someday soon we can preview our Poses with imagery!

Firstly, don't forget to put in a request via A:M Reports. quote/ User requests define the future development of the software /unquote But if they don't get logged into A:M Reports they don't get properly organized and cataloged. Since you've posted your thoughts here we must assume you want to discuss the merits of the idea and how it might be best implemented in A:M so Ill offer the following by way of looking to see how A:M can get from where it is now to where you envision it to be: Thoughts on what A:M has that is similar to what you describe: While not quite what you are talking about, a preview image can be associated (embedded actually) into an Action file (and other A:M files) and it might be relatively trivial to have other parts of A:M reference/display that image. It's too bad Libraries aren't more popular as there is a lot going on there that could be enhanced to the benefit of other internal features. What success might look like: Being able to assign a preview image to every asset would be useful but all the variations under the hood to get it done must be considered. Optimally, we wouldn't want a system that worked for poses that wasn't extensible to other areas of A:M. In other words we wouldn't want a setup for preview images that was either duplicated but implemented differently in another area of A:M without good reason. quote/ Reuse is the foundation of A:M /unquote So let's go play-by-play for a moment on your suggestions: They do currently (although not quite as robustly as needed for what you envision) The following has a lot going on and while I understand the general flow/goal of the idea this is where the vision would need to be refined into something that could become actual coding: Constraints/Technicalities Given that A:M assets currently have the capability of storing a preview image what remains to be considered to get from here to happiness with a full implementation of the suggested feature. Regarding the current implementation of preview images in A:M assets I'll offer the following as observations to consider: How true these are depends on how code is actually handled on the back side of things. Preview images are embedded. Discussion Perhaps an option could be made to allow an external image to be assigned that would over ride the assigned preview image BUT care would have to be given not to circumvent the optimization currently available via preview image optimization. Preview images are Base32 (or is that Base16... I always forget and have to remind myself) Discussion Would the preview image data type need to be updated to Base64 or best be left as is and bypassed as necessary to point to an external file? The longer term vision/associated requirements should drive code change. For instance, can we anticipate a future user request to have an 'animated preview' of their poses rather than the still imagery? As this is not practical to implement fully can we allow for that additional enhancement by leaving adequate hooks/space for it in the features code base? Disclaimer: There is something about the current preview format that seems superior to Base64 etc. but I don't know enough about the format or the usage in A:M. It may be that the data is Base16 and simply less abstracted and therefore optimal. In the few attempts I've made to understand the preview image I've seen excellence in it's implementation and would hate to lose that in any newer/updated approach. The upside of Base64 would be that files might more readily have the preview displayed in any web based implementation as Base64 is well estabished and surely optimal for use with HTML5 imagery/video. Preview images are displayed fully so assigning muliple images to an asset would require changing the way preview images are processed in A:M. Discussion It is not-quite-true that preview images must be fully displayed although that is the practical aspect as is. In fact, changing the preview size specified does allow part of the preview image to appear in the preview/info panel window. Example: if the preview image data is 97x54 and then the size is changed to 5x5 only the top left corner of that 97x54 image will appear. I haven't really tested this but a naive way of looking at this is that (to the user) this basically magnifies a portion of the preview image... ignoring the remainder that wont be seen in the preview window. Could the preview image be cropped in such a way as to point at only one area of an image? This sprite-like approach is one way to get access to multiple images for poses where only one underlying image exists. As with sprite based animation It's could allow for animated previews. Here I have described one way in which the current preview image currently assigned to Projects, Materials, Models, Actions and Choreographies might be extended to include Poses within these settings (embedded or externally). I have failed to describe how the current preview image would be optimal for use but have suggested it as the optimal approach for implementing a Pose preview I have attempted to suggest ways around the current constraints of preview image (one image per file so multiple poses have no adequate source from which to fetch their assigned imagery). I do not believe that using external images is optimal but allow for it via suggestion that a line could be added to circumvent/overriide/bypass the embedded preview image. An alternative might be to assign specific images to assets directly Note that I haven't attempted to discuss how Pose based animation might be altered as, unless directly reading available spline data, the preview image would Bottom line: The preview image is a powerful implementation although underutilized in A:M. As such, for that reason alone extending the preview image to Poses would be a good thing. Manipulation of the preview data is tied to several features that were never fully implemented in A:M that were once and would be popular. I'd love to discuss those further but... that'd be a whole other can o' worms. ...with apologies for the rambling as I attempt to get a wide range of diverse ideas related to the idea into one location.

And now they say Pluto has polygons. If that's not proof!!! Well, heck, no wonder it's not considered a legitimate planet then. Article: Scientists Puzzled over Pluto's Polygons