Problems with parent armature/bone

Related to 2 threads of mine (Link_1 Link_2) - here is a blend file to practically check the effects… End bone of little finger, R hand, is to be renamed to “Fg_4_3_R” (via the script). Cube.084 is the mesh (object) to be linked to that bone, ok? The script is customized to this object’s name only, later on will be modified to a cycle over ALL objects needed (after solving the problem). Cube.084 was linked to the same bone BEFORE renaming. At first let’s try to link it to the armature… Originally, the script is set link it to armature --> click ALT+P… You may see that Cube.084 is linked to the armature but it moves a little… Correct??? The question is “WHY so?”.

The above was exercise No 1 :wink:

Get out of BLENDER w/o saving and load the BLEND again…

Now try an exercise No 2… Take the object a little bit above the one currently named “Cube.084” and to the middle between 2 cubes of the little finger… It is now called “Cube.0842”… It is there just for testing puposes… So rename the current “Cube.084” to - say - “Cube.0841”, and the current “Cube.0842” to “Cube.084”. So that the script will work now with the other object (currently called “Cube.084”), ok? Run the script (ALT+P) and the object “Cube.084” is linked to the armature OK but this time w/o moving anywhere else!!! The question is again “WHY so???” Why an object that have not been linked to the armature links to it w/o geometric problems while object that have been linked, then unlinked then linked again - move or rotate? What is BLENDER storing in addition? What is NOT cleared before the new linking???

Now try an exercise No 3… <<< Linking to the bone >>> Therefore, go back to the initial BLEND-file… Now comment row 60 and un-comment row 61 so that you run the Arma_restore_parent_bone procedure instead of Arma_restore_parent_armature proc. Click ALT-P and you will see the Cube.084 linked to the bone at its end but rotated improperly…

Now try an exercise No 4… <<< Linking to the bone but the other object >>> Therefore, go back to the initial BLEND-file… Rename the objects as in No 2 above, comment row 60 and un-comment row 61 so that you run the Arma_restore_parent_bone procedure instead of Arma_restore_parent_armature proc. Click ALT-P and you will see the new Cube.084 linked to the bone at its end but rotated along the bone’s axis, i.e rotated properly!

The same question - WHAT is the reason for all that?

Pls any info on the questions above… Will be very much appreciated! :slight_smile:

Regards,

My finding on the issue is that FOR SOME REASON the object of my interest (Cube.084) is located in the SAVED .blend file at (-10.240, -2.560, 7.610) visually while as per Blender data it is at (-10.240, -2.460, 7.610)… :confused: I.e. BLENDER shows the object at Y = -2.56 while in loc value the figure -2.46 for Y is stored.

Apparently, certain update is NOT done… but Im a bit puzzled how it is possible to save a file with objects practically placed NOT at their recorded positions in object’s data blocks??? Is it possible??? Obviously, YES…

Entering into EDIT mode and going out updates object’s position to Y = -2.46, i.e. the data from data block is used for that.

But how can a script determine the “visual” position (cause in that case I want to preserve the place where the object is shown which would be equal to updating the recorded data for that position)?

Here is more:

Use my originally published file (see posting #1 above). Parent armature’s bone “Bone.032” to “Cube.084” (last part of the little finger) as it was before my last saving the file… Rotate the RIGHT arm so that it goes at horizontal position (rotation of bone “Bone…027” on X with angle = -90). Now put in the center of 3D window the little finger - ALL its part move (rotate) together with their parent bones due to parent-child relationship… When you are able to visually control what is happening with object “Cube.084” (the tip of the little finger, run Arma_remove_parents(aName,oaName) procedure ONLY --> it is in the BLEND-file so at its original state you only need to comment row 60 and un-comment row 59 in the text window… After running the script at this Step 1, you will SEE that object “Cube.084” is still in its previous place but is is NO longer a child of armature nor the bone “Bone.032”… You will also see that in object’s Properties panel the location of object “Cube.084” is as before reported to be (-10.240, -2.460, 7.610)… Now do the so called Step 2 - run Arma_restore_parent_armature(aName,oaName) - i.e. you need to have only row 60 in the TEXT window un-commented… You will probably lose object “Cube.084” which may go out of your sight at its reported position (-10.240, -2.460, 7.610), this time for real!!!

Between those two steps, you may SAVE the file, then un-load it then load it again (or load it when you want…) and you will STILL be able to SEE object “Cube.084” at a position far different (a way above and to the right) from its reported coordinates (-10.240, -2.460, 7.610)…

Modifying my proc Arma_remove_parents(aName,oaName) like this (one possible option which should be polished):

def Arma_remove_parents(aName,oaName):
    ob = Object.Get("Cube.084")
    print ob.parent.name
    if (oaName==ob.parent.name):
        ob.clrParent()
        ob.sel = 1
        Window.EditMode(1)
        Window.EditMode(0)
    return

solves the issue as ALL objects un-linked from the armature go correctly to their positions as per the data in their data blocks. Then the developer is to decide what to do with them, right?

I know that something in my original proc Arma_remove_parents(aName,oaName) is not updated BUT saving the objects at their visual position (not corresponding to data in data blocks) may be a BUG in Blender… :eek: If somebody else things so - please share an opinion…

I dont know where to report this, to whom and how (except in this forum)…

Regards,

Probably i will not be able to help you cause have been never working with armatures and python.
Though for better communication I’d suggest you make a blend file with two animations demonstrating the issue in style “is - should be” comparison, where:

  • “is” is the python-driven-armature
  • and “should be” is non-armature manually animated model simulating correct behavior.
    so everyone can see whats wrong.

These sort of problems is very difficult to describe only with text. Screen-videos are the best choice for this.
I had similar problem to report while ago, taking screen-shots from demo blend file: http://wiki.blender.org/index.php/User:Migius/orientation_matrix

@ migius - Thanks for your advice and suggestions/help in the other thread too! I have already published a link to my testing .blend file (see posting #1 above). And I will certanly publish some pics explaining the issue better than worlds only. I think that animation wont be appropriate to publish cause what Im saying is a problem lyes at pre-animation preparation period of designing and set-up.

For ALL trying to keep track on the issue Im explaining in this thread and my other two (listed in posting #1 of this thread), please also take a look at vincentweb’s thread here - more specifically at migius words in posting # 7 there. This may be the key for solving the problem but I havent investigated the python side of it yet so that I’ll tell you later if I managed to get to a solution or not.

Im basing this text on my posting #1 above.

Related to another thread of mine Link_1 (Im providing you now only one link to one other thread casue the other one’s issue has been solved thanks to migius! :)), I will explain with pics and text in all reasonable details the problem Im facing to (1) detaching some object from their parent armature bones, (2) renaming them (this step can be skip for now for easy explaining the code problem), (3) attaching the same objects to the same bones (with new names or w/o new names) with the idea to everything working OK after this! Of course, Im speaking of doing this via a python script. And of course my idea is to do that over many bones/objects but for ease of explaining I customized my current scripts to just 1 object called “Cube.084” and 1 bone called “Bone.032”.

Here are some .blend files which I will refer to further - Robo_test_41.blend file Robo_test_42.blend file Robo_test_43.blend file

Here is the armature in my testing .blend file (with many of bones deleted, just R arm and back bones preserved plus three objects representing the three parts of the little finger):

This layout is with ALL three parts of the little finger parented to the bones. They are moving OK (see Robo_test_041.blend file).

How it is produced? There’ve been a lot of other parts (for legs, head, etc. - no removed for simplification of the scene) that were put at their positions. Then I added appropriate bones, then I linked (manually) objects to their respective bones. Then, of course, ALL this was saved!!! And before getting to the point of attaching a script to control the armature, I had the problem to rename the bones and I thought it could be done automatically (via a script). Then - after renaming - a complete mess of re-positioned objects appeared… So Im writing you about just one of those in order to investigate the reasons and = hopefully - find a solution which is to be spread out over all others, ok? :slight_smile:

Now, let’s see what’s going on with object “Cube.084”… Starting with Robo_test_041.blend file, using the script set-up as shown in the following pic (running proc Arma_remove_parents(aName,oaName) ONLY - see the right part of the pic too!!!) and saved under a new file will give you the Robo_test_042.blend file with object “Cube.084” detached off its bone and still at the same position (see the Properties tab):

At the joint between 2-nd and third bone of little finger, I placed a cube that is NOT connected to the armature. I will tell you later on about this…

Now as soon as you have the file securely saved, you can load it again at what-so-ever time after that you’d expect (just as myself) after connecting the Cube.084 to the same bone nothing visually to happen except a new tiny dashed line to appear just showing us that the object and the bone have a parent-child relationship, right? Sooo please try only the next proc Arma_restore_parent_armature(aName,oaName) as shown on the pic below (right part) and look at the left part… Object Cube.084 moved slightly!

You may notice that the bigger cube (old position of Cube.084) is at (-10.240, -2.560, 7.610) while BEFORE and AFTER script run Cube.084 is reported to be (-10.240, -2.460, 7.610)!!!

The dashed line goes to armature insert point (armature center) and right now Cube.084 is NOT parented to its old bone Bone.032 but the whole armature. This is only for testing purposes! And you see, the Cube.084 moved a little! My question is why? Well, I can imagine that during construction and firls linking to the armature, some of cubes were moved, may be in EDIT mode, but I cannot expect after SAVING the file and linking to the same armature the same object to move!!! Also - pls compare the Properties panel - it show the same! Heh :eek: That is why Im looking for an answer to the question WHY SO?… At this point it is practically impossible to write a script (at for me) which is to “judge” somehow which object will move and which wont move after connecting to the armature! That is why I put the other cube (just in the middle of 2-nd and 3-rd bone of the little finger) - to test this… So to test what will happen - start with the original Robo_test_042.blend file, rename the bigger cube (called there Cube.0842) to cube.084, then apply the proc Arma_restore_parents(aName,oaName) ONLY as above, i.e. it will work over the “NEW” object “Cube.084”… And the rsult is that now the cube is NOT moved at all, just connected to the armature!

OK… Now start over again the original Robo_test_042.blend file and run proc Arma_restore_bone(aName,oaName) ONLY as shown in the script set-up to the right (pic below). The result is to the left - my object of interest (Cube.084) is linked to the bone but now it is located at bone’s end (not bone’s root as it was) plus that the object Cube.084 is rotated:

In the mean time the bone is renamed to “Fg_4_3_R” as per my plan. Even not renaming the bone, you will have the same situation with the Cube.084. Now Cube.084 location is reported to be (0,0,0) - it is due to the need of nulifying object’s location - otherwise, I need to look for my object very far away of this place! Suddenly, I found that the rotation applied to my cube is exactly (90,0,0) sooo if I apply a rotation to the oposite direction and move my cube at bone’s root, I will have the perfect situation I am looking for! The problem is HOW TO jusge on this as soon as - as above - I am still not able to write a script to sense this (location and rotation changed)… I tend to think that change of rotation comes due to the fact the arm point straight downwards and we are speaking about one of the fingers. If we dealt with one shoulder, there shouldnt be a need of rotation!!! Again - the problem HOW TO learn that via a certain script, i.e. w/o looking by eyes on it??? Plus - what if the angle wasnt 90 degrees? What if it is NOT sooo obvious? How to find it?

Again - try the above with the bigger cube - it attaches the same way to the same renamed bone! Does it mean that I need to destroy my ALL old object and re-work them again, position, rotate then attach to the bones so that I avoid the mess? I dont think so… There should be a way to attach old objects to their bones w/o deleting and reworking new ones! I think…

I tried to get bone’s matrix… but using this approach I reached nothing. May be this is a part of the solution, may be NOT.

Exploring the idea of bone’s matrix influencing the solution, I made the Robo_test_043.blend file. The armature there s with the R arm rotate to be horizontal, i.e. -90 degrees on X thus providing a chance to object Cube.084 NOT being rotated after the exercise I described last. On the pic below. pls notice that this is a TOP view and it come from the Robo_test_043.blend file with proc applied as per the script’s set-up to the right:

The result is as before - Cube.084 is moved and rotated, i.e. NOT following the bone’s line as it may be expected BEFORE starting the script…

The same question - WHAT is the reason for all that?

I know the posting became quite long… Thanks for the patience of ALL of you having read it entirely! :cool:

Pls any info/ideas on the solving the issues mentioned above… This will be very much appreciated! :slight_smile:

Regards,

IIRC for correct result in python you have to match mesh’s orientation matrix to bone’s one before parenting. It means the vertices in mesh must be eventually moved/rotated/scaled in its local space.
For inspiration you might look into Collada scripts, cause they deal massively with this stuff.

@ migius - Im sensing that my work on my task as described - renaming bones (and object) while preserving parent-child relationship - wont reach a successful solution w/o aligning objects (proper set-up of location and local rotation) to the armature and respective bones… This is OK for me! :slight_smile: BUT this wont make obsolete the question WHY is Blender saving objects at place where they arent according to their own data blocks provided they have been detached off their parents BEFORE the save!?

I’ll need some time to figure out how to deal with my task… Will post results of my work here or in an independent specific thread when I have a good advance on that! :cool:

Regards,

Hi Abidos, here is your text just re-formated for better understanding.

@ migius - Thank you for that!

Could you also provide me with proper direct links to threads showing/discussing COLLADA scripts, please? I only noticed recently (today) another guy asking for help on that (see this thread) but NOT script’s code.

Regards,

I saw this too, but cant help. I have some experience with matrix-math for standard parenting as i know it from CAD systems, but parenting to armatures/bones with their pose-mode/rest-mode/edit-mode + animation curves(IPOs) is too wired for me.

I meant Collada importer/exporter scripts bundled with Blender - to find in scripts folder.
afaik there is no thread elaborating this topic. Eventually try to search through Mailing List-archive: [email protected]