Rodney

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

And of course... in case its worth mentioning... we probably shouldn't bother with texturing of our cloth until *after* the results meet our expectations. Texturing and lighting are generally reserved for latter stage of production and Simcloth perfectly allows for that in our workflow. Here's the same setup with the cloth textured and rerendered (no other changes in the project): Disclaimer: Example only. Cloth this simple most likely doesn't need to be simulated in the first place. Simcloth Animation Texture and Lighting.mov

Hi Holly, Cloth will rely on a lot of different things but in my (little) experience with Simcloth it I've found that the simulating of cloth is the first step toward success; namely it gets you the keyframes (keyframes on every frame that is). The secret then is to identify those keyframes that you need to make the cloth animate correctly and then delete the remainder. THEN those (minimal) keyframes can be further adjusted (animated.... pose to pose or straight ahead) to maximum effect. Added: In the attached (very simple!) simcloth test a simple lathed (circular) plane was dropped on a sphere to get the basic cloth shape; the shape chosen from just one or more of the 30 keyframes generated by the cloth simulation. The resulting model/cloth was then moved down onto the sphere (as if the sphere is now representing a character) and rotated to get the desired turning effect. Further refinement would be to animate the cloth with some follow through or drag, run the same simulation with more complex model or adjust the simulation settings. Simcloth Animation.mov

Thanks! I note that size appears to directly relate to images rendered via the -HDTV-1080- setting in A:M's render panel.

Question: Is there a specific image size that should be rendered for entries?

No, all of the guides can be brushed although when there is overlapping sometimes the ones behind might not realize you are trying to move them. The best way I've found to groom long hair is to change the realtime mode of the hair to wireframe. There is an even better way (IMO)that I haven't explored yet and that is to use color decals etc. to control the orientation of the hair. I confess that I haven't done much in that arena but there is no better way than that to get the hair to go and stay exactly were you want it. I do find that when I get a hair guide that is particularly stubborn (usually in the middle or near the base) I reorient my view and then use FK to pull the end guide out to its extreme and then go back in (with the FK or basic pointer) and move the stubborn CP. Because particle hair can be computationally expensive anything you can do to limit extra visual stuff can help. For instance, you could turn off all drawing of the hair and initially place the guides, then go back in with wirefreme and refine, then go back in with shaded hair and adjust thickness and density (note that at this stage you likely are no longer moving the guides. I don't want to steer you down the path of frustrating exploration but there is a paint program (several actually) that can be used to control direction of hair guides. I would say the easiest way to grab an median CP on a guide is with the FK tool.

Oh oh. I'd better do an angry carrot by the time he arrives!

And now with a couple friends...

The short answer is 'Named Groups'. When you select parts of a model and name them those groups are saved and settings can change for those groups without effecting other groups. If you have a 'skin' group and an 'eye' group you would then set different settings for each *or* (to more closely address your question) materials can be dragged and dropped onto those groups. There are additional (more advanced?) approaches to assigning materials which will allow multiple materials to be layered on top of each other even on the same group but in most cases where you just want to texture a part of a model that wont be necessary. Also, don't forget that there are many ways to alter the surface of a model and materials are just one of them. Decals, patch images, materials and the Groups surface attributes are the primary ways and they can be used together. I usually start with setting a groups color to something simple and then work to more complex texturing from there.

You may need some eyebrows on that guy to make him look angry. Edit: You have a way of pulling me into your tinkering... Here's a try on a 'mad carrot'; with the interpretation of the word mad being 'just a wee bit crazy'.

Agreed! I'd call that success.

And we have a winner! That was it Gerald. On more than one occasion those extra properties exposed by Tool/Options have tripped me up. Thanks for getting that mystery solved. I had wondered about why that setting didn't appear to have been transferred since I experimented with porcelain a week or so ago. What a huge difference that makes in smoothness. But now you've got me wondering if there may be a glitch in the system in that only Normal Weight appears until the advanced properties option is turned on. Then Average Normals will appear but THEN the Normal Weight option will disappear until Average Normals is turned on. (Kinda makes the head spin) Bottom line: Average Norms works and can be accessed via Group properties if/when the triangle properties are set to 'Show Advanced Properties' on the Global tab in Tools/Options properties panel. Added: For completeness sake, I tested the triangle properties option... to see if Normal Weight appeared. As its not a triangle property (sub property?)) that's not the setting that turns it on. Show Advanced Properties is the one that'll turn it on. Addendum. I usually leave both the Advanced Properties and the Triangle Properties on. I'm not sure why I lose them. It's not like I consciously turn them off. I should know by now though that if something doesn't appear to check to make sure those two options are on. And Again: There are a lot of places we can set these settings and I assume the settings aren't cumulative. As long as they don't cancel each other out we should be okay.

I don't see an "Average Normals" option. I do see a "Normal Weight" option. But that isn't an on/off setting but a percentage. I will guess that is what you are referring to. I hope that helps. v18m here.

I am impressed that you have the talent and experience to do that. I wish I had the resources to pay you to teach me how to do it. I've got tons of ideas... can't implement any of them 'cause I'm ignorant of what I need to know to get the job done.. Although not knowing what I should have known has on more than one occasion been an asset. There are so many people programming applications for online management that it becomes increasingly hard to envision a home brewed variety that can. I'll go out on a limb and suggest that Project/File Management and online collaboration (at least the basics of such) is something an operating system should do. In other words, if the vast majority of users of an operating system need a specific tool then there is a viable market for it. The powers that be keep circling around the solutions but they don't bite because there is too much at risk (at least at present) to lose.

Yes.it should. I'm not talking so much about it working as I am about getting that line "AverageNormals=True" into the file (I assume it is only present in the material file but plan to test it in a Project file). The part that I'm not sure about is how to access that line in A:M's user interface. If you can toggle Average Normals from True/On to False/Off where did you access that parameter in A:M? And just so we are clear... I'm not sure what you are specically referring to when you say 'it' works for me. I assume you mean the code I posted above? If not that then... not sure what you are referring to. If it is the code you are referring to then the reason it works is because the line "AverageNormals=True" is in the file set to True so the averaging of Normals should work assuming A:M still knows what to do with that code. (Which I assume for backward compatibility it generally would). Note that my assumption is that that particular setting has never been a part of the UI hence the need for the Porcelain material in the first place. Assuming this is true a related question would be how A:M handles the Averaging of Normals now as opposed to how it did back when the porcelain material was regularly used. I vaguely recall reading a post on that subject after porcelain material was deemed obsolete but I've been too lazy to launch a search for it. Ah the joys of ferreting out the usefulness of presumed obsolete processes.

I'm liking the look you've got going. As for the Porcelain material... hopefully this won't go too far afield in your topic: I was experimenting with that the other day and updated an older porcelain material to v18 BUT in looking at the material code/text it became obvious that most of that material was/is now redundant because 1) there isn't much there to begin with 2) what is there has (mostly?) been incorporated into a porcelain-less workflow in current releases. I should say however that in my testing I did still note considerable change in the smoothness of some models... but not in others (very odd) and Gerald may have clued me into why some models appear to be affected by the material while others don't.... namely, the settings of the FIRST material or group of patches. I'll have to check that out! The entire text of the porcelain material for v18 should be something like this (note that you'll have to scroll (over on the right of the post) to see all of the code): A:M Material File ProductVersion=18 Release= PC InstanceCropStyle=InsteadOfCache Name=Attribute AverageNormals=FALSE NormalWeight=100 LastModifiedBy=Rodney Baker FileInfoPos=262 There are only two parts of this material that trigger the porcelain effect. They are: AverageNormals=TRUE NormalWeight=100 Of these two settings we can set the Normal Weight in any Group but as for Average Normals setting... I'm not sure where that would be adjusted but if set to TRUE (in the porcelain material) that tends to make a difference. At least it did in my initial test that prompted me to update the Porcelain material for use with v18. More testing required. If anyone can shed light on the Average Normal setting and how A:M handles that now in a porcelain-less workflow that would be appreciated. Added: From what I can tell setting AverageNormals=True cannot be accomplished in A:M. That line must be added/edited via a text editor.

Malo, Is there a specific browser to use for those? I'm getting a black screen upon opening the html index file. Perhaps the page can't be loaded locally in a browser but needs to be on a live site? I'm seriously impressed that you can do things like this. I like the idea of peaking first before applying decals. Update: Interestingly, the html is viewable in Dreamweaver although the code wont run. Update 2: I was able to run everything successfully via Adobe Edge Animate. Success! Perhaps I have a setting that is blocking access via normal browsing.

Looking very good!

:Looking good!

Definintely check out Barry Zundel's tutorials. There's even one on modeling a hand: http://www.villusionstudios.com/amtuts/01_Modeling/11_Will_Hand.mp4 Of course, there are different approaches to modeling and Barry demonstrates one of many. I think the primary thing I would do different than Barry would be that I would be in Shaded Wireframe mode more than just Wireframe mode most of the time. For simple hands I might also just outline them and fill in from there whereas he approaches more from a standard method of lathing cylinders for the fingers and attaching them. P.S. Welcome to the forums!