Rodney

I note that with both methods we can connect multiple CPs anywhere in the decal at the same time as long as they are aligned over the top of each other. Perhaps Steffen could increase the tolerance so that CPs connect when they are 'close enough' as sometimes the CPs appear to be over the top of each other but the only way to find out if they are attached is to attempt to move them.

I would like to find out why Ctrl Alt Click is not working for some people. But the good news is that now some of us have two ways to connect CPs in the UV Editor: Align/Select/Move/Click and Align/Select/Ctrl+Alt+Click Isn't it fun exploring new features. It should be emphasized that with Nancy's method we can not only reattach CPs but entire patches provided they haven't been altered too badly (this is what I take Nancy means by coplanar etc).

You mean like some kind of undo button to get back to the state before breaking any of the CPs? I'm investigating what you've added here because the only way I was able to attach CPs was with the Ctrl Alt Click method. Edit: That method works for me too. I think you've just discovered an undocumented feature! So once again with feeling. Here is Nancy's shortcut method (as it is working for me): (Disconnect some CPs in the UV Editor first in order to test this) - Align two CPs over the top of each other - Select both CPs and move them (anywhere) but do not release them - Click on the CPs At this point the CPs connect for me. (I'm not sure about all of that coplaner stuff. Thus far I've just needed to make sure they are on top of each other before selecting or else it won't connect the CPs.)

I should have said that this is how Alt Clicking is designed to work according to Steffen. So keep doing that if you want to separate patches.

Well, I don't know about restoring to the original connection but Ctrl Alt Click will attach any two CPs in the UV Editor together. Reconnecting is a rather exacting (five step) process. If you fail at any one stage you'll likely not reconnect the CPs. Make sure you: MAKE SURE YOU ARE USING A:M VERSION 17 - Place the two CPs you wish to connect exactly over the top of each other (there is surely a tolerance here but it's not very big) *I suspect this would be the primary reason why Ctrl Alt Click will not work for some people (Just for good measure at this stage select some other/third CP at this stage to make sure you aren't going to miss selecting both CPs in the next stage. - Select both CPs by surrounding them them with a mouse defined bounding box - Hold down the Control Key - While holding down the Control Key now hold down the Alt key - Click with the mouse on top of the CPs Note: At this point you can then place another CP over the top of these two CPs and after a Ctrl Alt Click have three connected CPs. Added: Maybe we can encourage Will to update his tutorial as the game has officially changed.

Do you folks need a video? Or just a better explanation? Does the following not work for you in the UV Editor?

That's such a popular subject that it's got its own topic: http://www.hash.com/forums/index.php?showtopic=42992

Well, that makes sense then. Carry on. Carry on! We might need to see the camera view in order to refine our comments. The action of the character is smooth enough. My suggestion would be to break up the symmetry. If one leg/knee goes down first and the body follows, that would accomplish that. I would suggest trying this yourself but I know you can't. Perhaps you could have someone else perform the action and you could video and study their action? I can see that you are close but it's hard to tell from this angle.

Gerry is on to something here. Unless you are going for humor here you may want to pursue a slightly different camera angle. While not necessarily gospel there is something to the theory that straight on shots like this are ideal for comedy and lighthearted works. That may be what you are going for here but I assume not because of the 'dark and stormy' theme. Are you intentionally trying to lighten the mood or building up to the punchline of a joke? If you are then the flatness may be an asset for you. If not, consider a camera move. I guess ultimately I'd have to say that at this point beyond the obvious that he is opening/adjusting something, I don't really know what is going on. Take heart though... six isolated seconds does not give us a lot of time to figure out what is going on. Rock on!

Charles, Wow! That's amazing work. I especially like the instructions you created to go with the STL models. Another excellent use of A:M! http://thingiverse-production.s3.amazonaws...nstructions.pdf Nice touch! Not answering for Charles here but want to make sure everyone knows... A:M now exports to STL format. (See image below) P.S. Welcome back Gorf!

Great write up Will. Short. Concise. Informative. You've opened my eyes a little more. I was thinking in terms of final rendered imagery and hadn't even thought about realtime resolution and animation. That should be at the fore. (I know your article is saying that because A:M spline patches are resolution independent we are already covered for both, I had just been focused on final rendering resolutions, static images and such.) I guess what I am considering here is whether there is a minimal or even optimal resolution given current images as found on many websites appearing blurry on Retina displays. In the past low rez generally worked for me but now I sense that I may be need to be more cautious of rendering out to lower resolutions. There also seems to me an opportunity to leverage both high and low resolution to take advantage of a greater range of clarity vs blur. You know those old theories that state things like "the farther away an object is the more it appears blurry". It presents something of an opportunity that did not exist before.

Is anyone up on the specifics/requirements regarding creating images for Mac Retina Displays? I've read a few articles but lost the one that I thought outlined it best. For those that haven't heard of this before it's related to how Mac displays are now produced with pixels spaced closer together which allow for crisper displaying of shapes and lines. This has ushered in a requirement for higher resolution images because the lower rez (normal pictures found all over the web) now look blurry by comparison. Has anyone seen a definitive guide?

Herein is one aspect that needs to be further defined. Are we talking about subdivision in a Model Converter? For import? For export? Optimized for a Renderer? Which one? Optimized for a Graphics Card? Which one and should we assume it is for modeling, animating or final rendering in real-time? While the end goal of each of these might be to make surfaces smooth, each of these will have different approaches and requirements. For fast playback one might assume the exceptions (things that require more computation) are simply skipped or approximated for the purpose of displaying in real time.

I've see that same thing before. Perhaps in Martin's patch technology write-up?* Edit: Didn't find it. It may also help in the understanding of it all to why such a change is needed. For instance, is there a specific issue you've run into or are you simply trying to explore and optimize? Here's a write up I'm sure you've seen Malo. I include it here for those that want to catch up: http://www.cs.sfu.ca/~torsten/Teaching/Cmp...ML/08_2Dcurves/ Of interest to me was the very last slide where it talks about testing for sharp edges and exceptions (this would be the realm of three point patches). It should be no surprise to see that they suggest handling those differently than the rest of the mesh. From that early Pixar paper you pointed to that seems to be where the scientists have been spending a lot of their time.

Nice pic Robert! I think that is closer to how the patches are (or can be) optimally subdivided.

I believe Robert is referring to A:M only. Previous to A:M (Animation:Apprentice etc.) others were certainly used. Hash Inc made an attempt to push the tech to graphics cards but (as I understand it) the math is easier to understand when using polygons. I see ut as the equivalent of working with straight math versus dealing with intensive algorithms. The algorithms perform better but someone first must create and then optimize the algorithms. This as opposed to crunching the obvious numbers via "perform math, perform math, perform math and recycle." Nice images Malo. They nicely illustrate your idea. (Disclaimer: The following is VERY naive) I can't say much regarding your thoughts on three sided patch division except to say that it appears that your proposed scheme would create shapes that are not rectangles (which are then subdivided into two polygons). They would appear to be modified rectangles/trapezoids. Therefore this new approach would have to be handled/interpreted in a different way than all other divisions, perhaps by sliding either the top/bottom or right/left sides within the given subdivision. I could see this going one way (to a renderer or to export) better than the other (import or continuity of 're-unsubdivided' or reconstituted splines). I'm trying to imagine how that would work for an importer it would have to test for both rectangles and trapezoids. I assume trapezoids first because they would be rarer and require more attention so they would have to be dealt with specially after ID'ing. So I'd guess we'd have to start with the question: Are all patches already (currently) simularly subdivided? If they are then implementing this new way to subdivide would constitute an exception which would work against optimizing. Of course, being an exception does not make it not worth pursuing. Exceptions to a rule often turn out to be that same rule (at least partially) optimized.

Shows what YOU can do after you've set your mind to it! I was recently viewing "Here's a Thing" on A:M Films and thinking... now that's how it's done... just dive right in and do it! Your videos are always entertaining. This is not only a testament to your talent but to the value of teaming up with other talented people. Ref: http://amfilms.hash.com/video/26/Heres-a-Thing

I'm not quite following you so this may be way off the mark. Are you using Euler drivers in your rotation? That can be set/initiated via Right Click.

Yes, it's Shift + Bake Surface. It lets us specify Higher Rez maps and you can tell A:M to overwrite previous decals. That and we can specify the overlap/margins of the generated image. (See dialogue box) - Rodney (Shift) Baker Added: I'll say this too. BEFORE YOU DELETE all those extraneous elements make sure you save your file somewhere. This will be useful if you ever have to go back to the original and bake everything again.

Here's a mostly undocumented feature in v17 that will be primarily of use to folks that login to the A:M Community. It can be useful for schools and small studios who want to deliver custom content and information into the A:M Community tabs. The Support tab in the A:M Community can be replaced simply by dropping an html file named 'Support.html' into the root folder where A:M was installed. For instance, if A:M installed to C:\Program Files\Hash Inc\v17 any html file named 'Support.html' found there will show up in the Support tab instead of the default support page. Fuchur designed a beautiful page to illustrate the possibilities with customizating the support tab that deserves to be seen and shared. Below is a screenshot of Fuchur's "Bestof" page in the Community Window. It displays a few images from A:M Stills. Check it out! Note that there is still a support link in the upper right hand corner of the page. Edit: Whoops. It looks like the default support page in the A:M Community links to a nonexistent support page. All the more reason to copy/paste the attached file as your new support page. Fuchur's support link will direct you to Hash Inc's current support page. Support.html

No, we are changing a representational equivalent of the mesh; (for lack of a better term) a UV mesh. So we aren't changing 'THE mesh' that is the actual geometry. But, Yes, we can change that mesh that is in the UV view. Steffen worded it better in one of this release notes but I couldn't find it. Added: Optimal workflow for adjusting both meshes would seem to be to have Modeling Window and a Decal Window both open at the same time and switch back and forth between the two. Edit: Nancy G has documented a second way to attach Control Points in the UV Editor that also attached patches if they are properly aligned and selected. In short it is: Place two CPs exactly on top of each other. Select the CPs and move them somewhere (only a short distance is required) Click on the CPs This should attach/reattach those CPs.

I'd say that we are just on the route to the implementation of that. If you consider that we haven't had Surface Baking for that long and the steady improvements we've seen in that, it makes sense to keep moving along the hierarchical chain to the actual images and colors of each patch. Of all of the surface attributes we can assign to a surface in A:M the attributes assigned to Named Groups are the most important throughout. Patch Images are extremely powerful and IMO they often better than materials and decals. But they aren't simply images on patches. They can be percentages of Color, Displacement, Bump, Transparent Ambiance (as well as others). And all of these can can be Layered on top of each other. Knowing a little of all the variables involved convinces me that there is a lot of work involved in keeping track of and programming enhancements to that. Add to that a changing world where we expect to be able to directly paint on surfaces and things get even more complex. I didn't post just to say all of the above but rather to suggest there is something of a mid-way method that can get some of my general nonsense accomplished. The following might work well for someone that just wants to reproduce each group in the image resulting from baking a surface. - Create a Material that is of a generic color or transparent. - Drop an instance of the material on each Group you want to show up in the Decal - Bake Surface - Save Decal - Adjust in Decal View / UV Editor and Associated Graphics Package Note: If you like what you see in the Surface Baked Decal you can then go in and further enhance the Material. This is imporant because Baked Surface Materials maintain their color, specular intensity, etc. (See image) Once satified just Bake Surface again with the new material changes. Disclaimer: This workflow is extremely experimental (for me).

Thanks Fuchur, Steffen you rock! Can you imagine doing this same editing of decal placement at any scale with a millionbajillion polygons? I surely cannot. Yet another fine example of the elegance and simplicity of patches.

I'll do that. Thanks for the confirmation. Edit: Done!

I'm trying to refine my workflow a little and am curious... Can we bake Patch Images into the images that result from Baking Surfaces? As far as I can tell they aren't considered part of the surface that gets baked. As they are defined by the patches themselves they'd be especially useful in defining regions for decal images created by the bake. So I'm curious to know know if they actually can or cannot be included in the bake. I'm not seeing a way to accomplish that here. As a workaround there is always the tried and true methodology of a simple screen capture and decal placement. Having patch images in the bake would skip those manual steps for patch images and result in more precise placement. This would ensure each Patch Image is matched to its corresponding patch in 3D space and that relationship recorded on a 2D plane. The latter of which I assume is the whole point of Surface Baking.