I’m having a problem which appears to be a scaled armature causing a scene to crash. I think the problem is with the scaled armature because, when I do “apply scale and rotation” to it, the scene is suddenly able to render. Of course this results in tremendous distortion to the meshes the armature deforms. It would be awesome if there were simply a way to apply scale and rotation and not get the distortion. I’ve tried selecting the meshes with the armature and applying scale and rotation to everything as a group, but I get the same distortion.
unparent the mesh first, scale them both , then control A to apply… then re parent the mesh to the armature.
hope that helps
The problem is generally caused by bones with Stretch To constraints, which each maintains a “rest length”. When you scale and apply size to the armature, the armature object no longer has a scale to multiply with the rest length.
I usually detach anything connected to the armature first: Select your armature and enter Pose mode. Change your 3D View to the Outliner and make sure you are viewing the outliner and not the OOPS schematic. Find and completely expand your armature. Select each bone, top to bottom, and watch in your buttons window for bones with Stretch To constraints. Whenever you find one, click the little [R] button to reset the rest length. (If your armature is not linked to anything, it should reset to 0.000.) Repeat ad nauseum.
Its a pain, I know…
Eh, that does suck. I’m going to get far too much practice with this . . .
it’s easier to do that if you organise your bones from the beginning, you can also reset them in the constraints tab yourself, so you select the bones, and press the R button that appears in the constraints tab. It’s just a little trickier to make sure you don’t forget bones, but you don’t need to fully expand scroll through the outliner.
EDIT:
jeremy, as for unparenting it doesn’t mean you lose your weights and all, or at least I think it shouldn’t.
You just remove the armatures name from the armature modifier, do the pose/res stretch/scale/apply loc/rot/scale thing, and fill in the name again. shouldn’t be too much work IF you setup your bones in a manner that makes em easy to find/modify.
My armatures are usually fairly complex and I find that it is easy to miss a bone. Hence, I always use the Outliner. It isn’t really that difficult. In the latest versions of Blender you don’t actually have to click every bone, since the Outliner shows you wish bones have constraints attached…
I’ve followed Duoas instructions, but only found ik solver, copy rotation, and action constraints. Aws357 built the armature, so this is all new to me. I’ll point him to this thread.
Aws 357 says there are no stretch to constraints.
Here’s a .blend file illustrating the problem -
Left - full size armature, no “apply scale
and rotation.”
Middle - scaled armature, no “apply scale
and rotation.”
Right - scaled armature, with “apply scale
and rotation.” It’s fugged up!
Perhaps the animation keys aren’t scaling?
You are almost right … It’s not that the animation keys don’t scale it’s the 90 degree rotation that have been applied to (I would guess) align the armature to the crazy Z up viewport hotkeys and the fact that the keys have both Loc and Rot keys applied … that’s screwing up the animation keys not the scale of the armature when you apply scale and rotation . And also the fact that for some reason when the keys were added you decided to key EVERY BONE (!) to apparently give you ulcers instead of just keying the IK targets etc. to make editing/fixing things later easier … It is possible to avoid the spaghetti mess of having to deal with quaternions by simply keying the Loc values of target bones and not the Rot values (because this is when the Quats show up and editing the IPO curves for them are not very intuitive) …
… At this point you might just try to have your mesh have the same “up” axis as your armature, i.e. the Y, and scale/rotate them together and this should work … or create an empty in the “top” view and then parent the armature to it then the mesh to the armature and parent the rest of the scene to the empty (if any) and just rotate the empty 90 degrees to align with the Z up view ports …
But if the issue is with the scaled armature crashing Blender like you said in your first post then the file you posted doesn’t give me enough information to figure that one out … maybe the mesh does not share the same “up” axis and/ or scale with the armature and is for some reason is causing the problem ?
… If that is the case then just apply the scale to the armature with out it being rotated 90 degrees along the X, i.e. when it’s “front” view is the the “top” view then reparent the mesh etc. then rotate … other wise the keys you have now will not behave properly when you apply the rotation aligned to the Z up view port (because the Rot values are keyed and you have Quats to deal with) …
Thanks for your reply Vertex Pusher.
Here’s the armature that’s causing the problem -
Part of the problem is, the meshes derive their scale and position from the scaled armature, so if you unparent them they return to their original position and scale.
This may be too much of a problem to solve. If you can do it, you get a cookie. If anyone in your area delivers cookies, I will buy you one 
Huh? Z up viewport hotkeys?
I don’t know anything about a 90 degree rotation being applied. All I did was scale the thing down. Since I’m going to be compositing these parts maybe I should scale it all back up. I scaled it all down so I could have a bunch of capitol ships battling in the distance, but I ended up having to scale them down so it’s all fakey fakey now anyway. It would be good to get the problem worked out though so I don’t recreate it in the future.
I didn’t animate this file, but I confess to making the same mistake in my own animations. Neither aws357 nor myself claim to be animators. I plan on throwing away everything I’ve done so far, but it would be good to use it for the next few renders.
Don’t the fingers at least need rot keys?
How do you get an overall axis for the armature to display? I can get axi to display for the individual bones in pose mode. The Armature Base_down bone (sticking out of the back) has the Z up. Armature Base has it down, but at least vertical.
Heh … this is a bit funny even if an odd situation … from looking at the file and your “not rendering” problem seems to be caused by the fact that the armature modifier for all the meshes parented to the armature have the Ob: field all blank !?! … If you just copy and paste the Arm_snk_back armature name into that field(s) the mesh(es) seems to deform as expected … easy as pie or rather a cookie ? :eyebrowlift:
And as for your questions about my post …
“Z up viewport hotkeys” … Blender’s numberpad hot keys for the front/side views have the Z axis as the default and as of now unchangeable “up” axis . This is not the case with most other packages (it is the Y) and in fact even in Blender the default up axis for all objects created (for the object itself) is the Y … A lot of new users after they get a hang of the hot keys add objects in the “front” view (numbpad 1) without realizing they are creating objects that are rotated 90 degrees along the X axis to the objects own up axis … This in itself isn’t a problem until usually you start animating and adding keys with other objects created in different views with poorly thought out hierarchies/parenting .
And yes your armature has that “hidden” rotation . You can see this by going into Object Mode -> selecting the armature and hitting N to bring up the Transform Properties subwindow in the 3D window . The RotX: value is 90 . And when you Ctrl-A to apply scale and rotation it screws up the Quat rotation values and so your animation goes all screwy .
Don’t the fingers at least need rot keys?
Not if you set up your rig so that the target bone simply needs Loc transform values … Here is an “adjustment” I made to Bassam’s Mancandy/ED finger rig : http://uploader.polorix.net//files/307/MANCANDY_FINGER_VARIATION.blend
It’s set up the same but there is a target bone for the scale/rotate bone that you can just set up to key only the Loc transform values . I avoid, like the plague, quaternions whenever possible … It’s confusing just on a conceptual level and almost impossible to correct when you have to edit the keys/IPO curves …
And on the topic of keying too many bones … it is a good idea to use the bone layers and place just your control bones on one layer and only have that layer visible when animating … If you accidentally select all the bones when keying you only have the control bones to deal with … not pinky.003_L as well …
How do you get an overall axis for the armature to display? I can get axi to display for the individual bones in pose mode. The Armature Base_down bone (sticking out of the back) has the Z up. Armature Base has it down, but at least vertical.
Hit N . Transform Properties subwindow in the 3D window in Object Mode . And btw the “up” axis for all armature bones is Y (also the axis the bone rotates around) . This is hardwired in the programming and is so most likely by convention . The Transform Properties subwindow is your friend …
And just a parting thought … even though the apparent solution to your problem was an odd glitch (did you import/append the objects from another blend?.. ) the advice given to you from the other posters are valid … and you could do a slightly better job at scene management … the body mesh also has a rotation around the X axis but it is an odd rotation (6.200 ?) …
The whole “up” axis thing is just annoying and not really a problem once you know that that “problem” is there (hopefully you will be able to change this after the refactoring of the code, and the key bindings more easily adjusted - apparently the guy who hardwired that in the code was an engineer - I had an argument with an engineer friend of mine and apparently they use the Z up axis as their convention), and is simply avoided by 1) applying the scale and rotation to every object you create, 2) creating all objects in the same view (if you want to be a purist in the "Top"view), 3) never ever rotating an object in Object Mode unless it is to key an animation, and if you do do #1 …
If you always do those you could get away with setting up animations without considering hierarchies/parenting … As it is now despite the fact that your file contains objects with odd scales/rotations it still does work is because of the simple hierarchy (between mesh and armature) … if you added a curve as a path and parented it to the armature your mesh would be flying around everywhere … Unless you unparented then reparented the objects in a particular order (curve to armature to mesh) .
… But if you have all the objects lined up to have the same “up” axis you could just use the armature modifier from the modifier stack/use the curve deform function from the NLA for walkcycles with out the need for parenting/hierarchies (and it is a good idea create all objects in the top view - the default intro view - if you remember the first time you opened Blender, like I said all objects created in Blender has the Y as its default “up” axis and this is the programming convention for 3D) …
Sorry for the confusion. I removed the armature names from the modifier on purpose. The next step is to clear the armature parent from the meshes and apply scale and rotation to the armature. When you do those things, you’ll see the mess I’m getting. Also, if you F12 render the file as-is, or with the armature names back in the modifier fields, you should get a crash. I get one every time.
Ok no cookie yet … 
… But When I just F12 and rendered with the file as is with the armature name back in the modifier it did render … Yesterday when you posted this I did try to render and it did crash … but the console indicated something about “no disk found” and I had assumed that maybe you had a texture link that was local to your computer … but now it seems to render fine for me here even when I use different actions …
In fact just to test this out I rendered out the walkcycle as a sequence and it came out fine (though sequence wouldn’t replay in the render preview and made the render preview crash … but not Blender itself … And Blender created the long C: media/…/…/ directory you have as your output directory - without asking me …) … I get the feeling that this is not caused by the armature scaling/rotation issue (I don’t think you have one functionally because the meshes are the children of the armature and just by that fact all the other non alignment/scaling issues go away … in this setup anyway …)
… I redownloaded your file again / replaced the armature name back in the modifier and still it renders out fine for me here … I am using 2.45 RC1 if that helps … And now as I think about it the “no disk found” message was telling me that I didn’t have the output directory paths you have in your file … until it was generated automatically (???) on my hard drive …
I nosed around the data directory but didn’t find anything too unusual except a whole lot of material settings … You know sometimes misdirected textures settings/ nodes etc. can cause rendering problems or crashes … But like I said I seem to render out fine after I reapply the armature name in the modifier … maybe you should try that again but I can’t seem to reproduce your problem here at my end … sorry …
But just to reiterate, I do not think that this is an armature scale/rotation issue … and with how things are set up right now (you have animation keys that will be screwed once you apply scale/rotation) and the meshes will turn into twizzlers if you re apply the armature after “correcting” them, and since I can seemingly fix the problem on my end so very easily (which is a good thing if you think about it you won’t have to re-key your animations ), I think maybe you should try something as mundane as setting a new file path for your output directory and also pay attention to the console if a crash happens again … If you can get more information that way maybe we can figure this out …
I put the armature name back in the object field for all the meshes and rendered again.
I also changed the output directory.
It will render at 25% of 2538X1080.
It won’t render at 50%.
I got this error in the console when it crashed -
“libpng warning: incomplete compressed datastreamin ICCP chunk
libng warning: Profile size field missing from iCCP chunk”
I changed the image format to jpg, and got the exact same error message when it crashed again (libpng).
O.K., I’m lost.
I’m in 2.44. I’ll download 45 RC1 shortly
Data directory?
I looked at the materials in the oops schematic. “skin_face_taonui” doesn’t appear to be attached to a mesh, but it’s not getting auto-pruned on save. It looks like there’s bunches of stuff that should be auto-pruned, but it ain’t happening.
2.45 didn’t help. Still in crash city.
“libpng warning: incomplete compressed datastreamin ICCP chunk
libng warning: Profile size field missing from iCCP chunk”
I’m not sure what that means but it seems you are missing data chunks and or your blend isn’t writing properly to the hard drive … and that also happens with the jpg format ? … maybe try an uncompressed format like bmp or tiff or targa raw …
I tried to render at 100%, 75%, 50% … all rendered … so hopefully if you update to 2.45RC1 or 2.45RC2 what ever glitch isn’t making it render on your end will be fixed …
And yes you can browse the internal data directory of your blend by hitting Shift F4 … if you have an object or an action or a material etc. you will be in that data type’s directory … all you have to do is to hit the “…” (double dots) to get to the main directory with all the data directories …
And yes your file seems to contain a lot of unused material data … I don’t know why they are there … they might be connected to a material node or something ?
… Considering that you are having problems rendering and also have all this unused material data bloating your file maybe you should consider just starting a new session and just appending the wanted objects as well as updating ? You’ll have to reset the render output frame size but at least you’ll have a “clean” file to work with …
Hope updating to version 2.45RC1 or 2 gets rid of this problem for you (and maybe appending in a new session)… good luck .
2.45 alone didn’t do it, but appending the scene to a new file did. It renders at all sizes now, so apparently the problem does have something to do with unused material data. Well, now I know something new 
This was part of a larger scene, but I broke it up to make it more manageable. But it became more unmanageable 
2.44 is also rendering the new file fine. Cookie time! Thanks for your help 
Incidentally, on quit 2.45 rc2 threw the errors -
“libpng warning: Incomplete compressed datastream in iCCP chunk
libpng warning: Profile size field missing from iCCP chunk”
Maybe the libpng warning is tied more to Blender crashing in general than to the render crashing Blender? I’ll keep an eye out for it in the future.