inverting part of matrix_world data

Still working on some updates for a md3 exporter. I have an issue with the objects rotation being backwards. It is fixed simply by multiplying the vector co by matrix_world.inverted except, the problem now is that the scale is exported inverted.
I’ve made a variable my_matrix and have tried many different ways to just invert the rotation or scale with no luck. I think it should be very simple but I’ve overcomplicated it for myself and am drawing a blank. Any help would be greatly appreciated.

To clarify my question:
How can I invert either scale or rotation in object.matrix_world?

I’ve got the scale back to before inverting the matrix like this:

        mat = obj.matrix_world
        my_matrix = obj.matrix_world.inverted()
        my_matrix[0][0] = mat [0][0]
        my_matrix[1][1] = mat [1][1]
        my_matrix[2][2] = mat [2][2]

Unfortunately, I was wrong assuming the inverted matrix would be correct once the scale switched back. I guess I need to invert the objects rotation before I call for the world matrix. Is there an easy way to invert rotation? Or do I have to suck it up and do the math?

for a rotation-matrix (thats the 3x3 thing) it should be the same like a simple transpose –
check it in the blender-python console with a world-matrix converted to_3x3()
and then the inverted and transposed values.

added: beware … not every 3x3-matrix is a rotation-matrix!

Well, I’ve done dozens of tests and eventually went to a very simple test. I made a cube at frame 1 it is default, by frame 10 it is scaled 4 x axis, and rotated 90* Z axis. The scale is applied in blender to the object axis itself, whereas on export it is applied to the x axis of world space.
Now here are some pics of what blender draws and what my exporter spits out. Any ideas how I can fix this? I’ve attached a blend with the script.


Exporter_test.blend (384 KB)

Hi Drek,

When transforming coordinates you should use the following multiplication order for matrices and vectors:

transformed_coords = transform_matrix * original_coords

This is related to the point that test-dr made. In your code you appear to be using the reverse order of multiplication, test this out and let us know how it goes. Hope that helps.


Thank you so much. You know I could be mad at myself for making that mistake (I do remember reading that rule somewhere, now that you point it out.) Instead I will be happy, because that simple mistake lead me to learn so much about blender coding. Thanks again for your help everyone. Now I can fix some more errors that have shown themselves, I was adding object.location data twice, that shows more clearly now that the other blatant errors are gone.

i can only give you this advice (its not really teached in school - and i dont know why, except some bad suspects…): Matrix-arithmetic is not the same like normal-number-arithmetic. One of the main differences is the order of the operands.
Some example may show it:
7 * 9 =is the same= 9 * 7
that is most times not true for:
mat1 * mat2 =?= mat2 * mat1
the above matrix-multiplication is only true for those matrices
with: mat1 * mat2 = the-unity-matrix(the one with all 0 except the diagonal is 1)

to reverse a multiplication with normal-numbers, you would use the division
like this:
a = b * c
and then, if you want to know c:
c = a / b
and you may have learned, that this may totally explode the whole system, if b = 0 (a very special number).

to reverse a mat-multiplication, you have to generate the reversed mat and use this for multiplication, because the reversed-mat * mat = unity-mat.
And the generation of the reversed-mat may not be possible - this is something like the division with 0 (zero).

only to inform, i start again looking in the old-working md3-exporter,
because i’m tired of patching the default image-filename into it to use
the simple testmodel function in etxreal.
If i have it done, i will put the changed md3-exporter into the otc6-branch for etxreal too (where the mdm/mdx thing is already).

hell – should read more sinner the specs … it is not necessary to change the md3-exporter – i only have to use the proper image-name for the uv-texture-name, this will be exported at the place of the shader.
So a uvmap like: models/players/hud/myhead.tga
will then put as this imagename into the shader-slot and the game-md3-loader will use it as the default to texture …

Thanks for the help guys. Ya I guess the rules for doing math with whole numbers doesn’t apply to lists and matrices. I don’t quite understand exactly whats going on in that complex formula, just glad it works right now and I can move on.

About shaders:
Define a custom property of “md3shader” then define its value to “skin_path/filename” eg. “mymodel/myskin.tga”

I am ironing out a few more details, then I want to take at shot at trying to export particle systems somehow. Does this even sound possible to you more experienced coders?

After that I will be writing some documentation and making another “release” of this script. Check out for updates, although I will probably post it on the forums here somewhere also.

@Drek: so i wanna try a question, i could not solve up today. And at the etxreal-irc no one seems to say anything about it (… sounds like dead end road).
This blend-file is a simple flagpole with to flags and – i first made a thing with cloth and wind… and then noticed every time the second flag (flag2) for the second team should be pulled up… in game the whole flagpole was clipped off if the player came close to touch and activate the flag-signal. So i ended with this stripped down version to test why this happens.
Up to know i know the pulled-down flags in the ground have to be small, so they dont blow up the … bounding-box-calculation …
and while i am writing this, i think i should again check the origin of all three surfaces (objects in blender, the pole and 2 flags) maybe i still missed one setting …
If anyone has any hints, i would be glad to know, because this thing is stunning me a bit too much — one flag working and one … the same with this clipping-sideeffect…


flagpole.blend (81.1 KB)

It has to be the game code doing this. The model exports great to md3.

thanks for your check, but the original model works - could be the settings of the pull-up-animation is wrong in my simple re-build. I have checked it several times and the pull-up, stay-up, pull-down frame-ranges seem to be the same (i even imported the old model and animated this puzzle … )
… and the source … from cg_ents.c:

static animation_t multi_flagpoleAnims[] = {
        { 0,    "",     0,              1,              0,              1000/15,        1000/15 },      // (no flags, idle)
        { 0,    "",     0,              15,             0,              1000/15,        1000/15 },      // (axis flag rising)
        { 0,    "",     490,    15,             0,              1000/15,        1000/15 },      // (american flag rising)

the first two frames are used as the idle-state …
that makes me think … maybe the player-model has still some funny wrong clipping
… i will have to check the model with the old et-paks …

only to give some response, looks like i can get it working,
but i still dont know why - what reason -
this is nearly the final version,
the pull-up/down is not like i want it, … and there is something
with the frameranges used for the flag-animation.
But this is now with the cloth-modifier and some noisy wind…


update the old md3-exporter script:
for blender-2.61

it now exports the empty for tag_objects with their animation and
exports those animated empties without any surfaces(meshes).

This is usefull for low-level animation where only a static object
is put to the location and orientation of an md3-tag and animated
according to the moving and rotation of this.

Next, if there is an custom-variable added to the scene with the name
and the output path of the md3-file to be created,
this variable will be used as default output setting
and its name without the md3-extension will be filled into the md3-name.

So its easy possible to generate multiple scenes with linked objects
and every scene setup with a different selection of objects and frame-animation-range and the md3-output will then go to the md3-file
specified in this scene-custom-variable. This reduces the md3-generation
to only select the correct scene, than md3-output and accept the already selected

the script is in the otc6-svn in the etxreal-branch and its blender-subdirectory