Re: [Bf-committers] Patches Submitted

[Campbell Barton]

On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese  wrote:
> Hi Gang,
>
>
>
> FYI. I submitted 3 patches for your review.  I'm new to the list and I
> wanted to give back to the Blender community.
>
>
>
> 28030  SCONS Build: Build Date reflects
>  d=9&atid=127> "1" instead of actual date of build
>
> 28031  Minor typo in Blenlib
>  d=9&atid=127>
>
> 28032  Python Mathutils: Matrix Multiplication Error
>  d=9&atid=127>
>
>
>
> Great work guys!  Appreciate the great product.
>
>
>
> Scott

Thanks for the fixes, committed all patches however you're changes to
mathutils effectively only change the order of multiplication,

http://projects.blender.org/tracker/index.php?func=detail&aid=28032&group_id=9&atid=127

In you're example
>>> print (m1 * m2)

Change to...
>>> print (m2 * m1)

This is a bit confusing because in C we have
mul_m4_m4m4(m1, m2);
 which is the equivalent to "m2 * m1" in python.

A while back Benoit Bolsee was concerned our matrix multiplication
order was wrong so we switched it (between 2.4x and 2.5x)

What makes you think the order in blender is wrong? what's you're reference?

Just checked and we're currently doing matrix multiplication
differently to numpy which doesn't bode well :S - test:

# --- snip
m1 = ((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0,
0.0), (0.6, 0.0, -0.05, 1.0))
m2 = ((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0,
0.0), (0.0, -0.02, -0.1, 1.0))

from numpy import matrix
n_m1 = matrix(m1)
n_m2 = matrix(m2)
print("\nnumpy\n%r" % (n_m1 * n_m2))

from mathutils import Matrix
b_m1 = Matrix(m1)
b_m2 = Matrix(m2)
print("\nmathutils\n%r" % (b_m1 * b_m2))

# --- output

numpy
matrix([[ 0.  ,  0.  ,  1.  ,  0.  ],
[-1.  ,  0.  ,  0.  ,  0.  ],
[ 0.  , -1.  ,  0.  ,  0.  ],
[ 0.6 , -0.02, -0.15,  1.  ]])

mathutils
Matrix((0.0, 0.0, 1.0, 0.0),
   (-1.0, 0.0, 0.0, 0.0),
   (0.0, -1.0, 0.0, 0.0),
   (0.62, 0.1, -0.05, 1.0))


# --- switch m1/m2 order for both mathutils and numpy. re-run

numpy
matrix([[ 0.  ,  0.  ,  1.  ,  0.  ],
[-1.  ,  0.  ,  0.  ,  0.  ],
[ 0.  , -1.  ,  0.  ,  0.  ],
[ 0.62,  0.1 , -0.05,  1.  ]])

mathutils
Matrix((0.0, 0.0, 1.0, 0.0),
   (-1.0, 0.0, 0.0, 0.0),
   (0.0, -1.0, 0.0, 0.0),
   (0.6, -0.0, -0.15, 1.0))
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Fwd: knifeless.blend animation

[Daniel Salazar - 3Developer.com]

@Bassam: that's exactly how it works in BMesh

Daniel Salazar
3Developer.com



On Tue, Jul 19, 2011 at 4:06 PM, Bassam Kurdali
 wrote:
>  One of the things that makes the softimage (for example) knife 'better'
> is that you can continue to navigate the view while in the knife
> mode.(imagine cutting e.g. a wrinkle around a character's trouser leg).
> I had a brief misunderstanding when 2.5 'non blocking/non modal' stuff
> was announced that this meant that this artist friendly functionality
> was coming to blender (also useful for e.g. circle select), however my
> hopes were dashed when I realized 'non blocking' meant 'artists now have
> to redundantly hold down keys on their keyboards' (joke)
>
>  In seriousness: if this is at all possible given the 2.5 architecture
> it would be a big increase in functionality.
>
> On Sun, 2011-07-17 at 07:53 -0400, Howard Trickey wrote:
>> In fact I've been reading the bmesh knife code recently, on my project to
>> help close out the bmesh TODOs, and the code right now there may be doing
>> some closer to what you want: hitting k takes you into a modal mode where
>> successive left clicks make connected cuts; hitting e ends a cut and lets
>> you start a new series; holding down CNTRL turns midpoint snapping on,
>> holding down SHIFT turns all snapping off (by default, edge and vertex
>> snapping are on); and using the middle mouse button temporarily takes you
>> out of cutting mode so you spin the model.
>>
>> Who knows how long it will take to get bmesh into trunk (though I am trying
>> hard to contribute to making that sooner rather than later), so it is
>> probably worthwhile to fix the old version now, but it would be good to
>> settle on similar behavior between old and new so that it will be easier for
>> users to adapt to the change to bmesh when it comes.
>>
>> 2011/7/17 Αντώνης Ρυακιωτάκης 
>>
>> > Hi, before doing unnecessary work maybe you should check with bmesh
>> > too? If it's going to be merged anytime maybe it's better to work
>> > there?
>> > ___
>> > Bf-committers mailing list
>> > Bf-committers@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patches Submitted

[Juha Mäki-Kanto]

I've needed to try and figure this one out too so here's my two cents and
some random matrices.

Since Blender uses column major order matrices these printouts are actually
"visually transposed" to normal math, actual matrix columns are shown
horizontally in the inner brackets and rows are vertical. So the 2.5 in a*b
((a*b)[2][0] -> column 2, row 0) is a result of dot produt (a row 0,  b
column 2) as it should be -> dot( (1.0, 0.0, 1.0, 0.0), (0.5, 1.0, 2.0, 0.0)
).

>>> a
Matrix((1.0, 0.0, 0.0, 0.0),
(0.0, 1.0, 0.0, 0.0),
(1.0, 0.0, -1.0, 0.0),
(0.0, 0.0, 0.0, 1.0))

>>> b
Matrix((1.0, 0.0, 0.0, 0.0),
(0.0, 1.0, 0.0, 0.0),
(0.5, 1.0, 2.0, 0.0),
(0.0, 0.0, 0.0, 1.0))

>>> a*b
Matrix((1.0, 0.0, 0.0, 0.0),
(0.0, 1.0, 0.0, 0.0),
(2.5, 1.0, -2.0, 0.0),
(0.0, 0.0, 0.0, 1.0))

>>> b*a
Matrix((1.0, 0.0, 0.0, 0.0),
(0.0, 1.0, 0.0, 0.0),
(0.5, -1.0, -2.0, 0.0),
(0.0, 0.0, 0.0, 1.0))

One nice thing about this is that the columns are the axises (0,1,2) and
translation (3) of a matrix, so a camera direction for example would be
-a[2][0:3].

2011/7/20 Campbell Barton 

> On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese 
> wrote:
> > Hi Gang,
> >
> >
> >
> > FYI. I submitted 3 patches for your review.  I'm new to the list and I
> > wanted to give back to the Blender community.
> >
> >
> >
> > 28030  SCONS Build: Build Date reflects
> > <
> http://projects.blender.org/tracker/index.php?func=detail&aid=28030&group_i
> > d=9&atid=127> "1" instead of actual date of build
> >
> > 28031  Minor typo in Blenlib
> > <
> http://projects.blender.org/tracker/index.php?func=detail&aid=28031&group_i
> > d=9&atid=127>
> >
> > 28032  Python Mathutils: Matrix Multiplication Error
> > <
> http://projects.blender.org/tracker/index.php?func=detail&aid=28032&group_i
> > d=9&atid=127>
> >
> >
> >
> > Great work guys!  Appreciate the great product.
> >
> >
> >
> > Scott
>
> Thanks for the fixes, committed all patches however you're changes to
> mathutils effectively only change the order of multiplication,
>
>
> http://projects.blender.org/tracker/index.php?func=detail&aid=28032&group_id=9&atid=127
>
> In you're example
> >>> print (m1 * m2)
>
> Change to...
> >>> print (m2 * m1)
>
> This is a bit confusing because in C we have
> mul_m4_m4m4(m1, m2);
>  which is the equivalent to "m2 * m1" in python.
>
> A while back Benoit Bolsee was concerned our matrix multiplication
> order was wrong so we switched it (between 2.4x and 2.5x)
>
> What makes you think the order in blender is wrong? what's you're
> reference?
>
> Just checked and we're currently doing matrix multiplication
> differently to numpy which doesn't bode well :S - test:
>
> # --- snip
> m1 = ((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0,
> 0.0), (0.6, 0.0, -0.05, 1.0))
> m2 = ((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0,
> 0.0), (0.0, -0.02, -0.1, 1.0))
>
> from numpy import matrix
> n_m1 = matrix(m1)
> n_m2 = matrix(m2)
> print("\nnumpy\n%r" % (n_m1 * n_m2))
>
> from mathutils import Matrix
> b_m1 = Matrix(m1)
> b_m2 = Matrix(m2)
> print("\nmathutils\n%r" % (b_m1 * b_m2))
>
> # --- output
>
> numpy
> matrix([[ 0.  ,  0.  ,  1.  ,  0.  ],
>[-1.  ,  0.  ,  0.  ,  0.  ],
>[ 0.  , -1.  ,  0.  ,  0.  ],
>[ 0.6 , -0.02, -0.15,  1.  ]])
>
> mathutils
> Matrix((0.0, 0.0, 1.0, 0.0),
>   (-1.0, 0.0, 0.0, 0.0),
>   (0.0, -1.0, 0.0, 0.0),
>   (0.62, 0.1, -0.05, 1.0))
>
>
> # --- switch m1/m2 order for both mathutils and numpy. re-run
>
> numpy
> matrix([[ 0.  ,  0.  ,  1.  ,  0.  ],
>[-1.  ,  0.  ,  0.  ,  0.  ],
>[ 0.  , -1.  ,  0.  ,  0.  ],
>[ 0.62,  0.1 , -0.05,  1.  ]])
>
> mathutils
> Matrix((0.0, 0.0, 1.0, 0.0),
>   (-1.0, 0.0, 0.0, 0.0),
>   (0.0, -1.0, 0.0, 0.0),
>   (0.6, -0.0, -0.15, 1.0))
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Proposal: better envmap scripting

[Tom Edwards]

Hello all. I'm currently writing an add-on to ease the export of renders 
and environment maps to the Source game engine, and I'm finding my 
options when it comes to envmaps extremely limited. I'd like to add the 
following functions:

bpy.types.EnvironmentMap.save( filename, layout=( 
(0,0),(0,1),(0,2),(1,0),(1,1),(1,2) ) )

Saves the envmap with the scene render settings. "layout" determines the 
location of each face in the output image; 1 == EnvironmentMap.resolution.

bpy.types.EnvironmentMap.render(ignore_cache=False)

Renders the envmap if it is stale. Ignores the camera and indeed goes 
ahead without one. Might render other envmaps for recursion. 
"ignore_cache" bypasses the normal envmap cache checks.

bpy.types.EnvironmentMap.clear()

Same as bpy.ops.texture.envmap_clear(), but without the overhead of 
setting up then reverting the context.


Is there any reason why the above couldn't be added to trunk?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Material Nodes: No normals in worldspace?

[Tobias Oelgarte]

In recent time I worked with node-materials quite often and anything 
seamed to be fine. But then I came across the very simple task that 
needs the actual normals of the object surface in worldspace (z-up, 
x-right, y-backside). But there is no input for such normals. All I have 
found are the normals in viewspace and the view-vector of the camera 
(also in viewspace). Since both are only relative to each other, there 
is no way to get the worldspace normal of an object just by using this 
pair. That means, that there is no way to influence the shading 
depending on the orientation (not location) of the faces itself.

For example you would like to give any upward looking face an own 
material and fade it out to a second material, as the angle gets bigger. 
This can be achieved within viewspace, but only if you never intend to 
rotate the camera. Tilt it 180° to left or right and the bottom of all 
objects will show the first material instead of the second.

So my questions are:
a) Is there a way to access the normals in worldspace/localspace within 
material nodes?
b) If not: Why was it never implemented? Seams to be very useful: Snow 
depending on surface angle; Trees covered with moss at the rain side, 
ice at the wings of a plane, etc.)
c) Is there any workaround that would also work on animated meshes?

Best wishes from
Tobias Oelgarte
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Material Nodes: No normals in worldspace?

[michael williamson]

On 20/07/11 20:14, Tobias Oelgarte wrote:
> way to influence the shading
> depending on the orientation (not location) of the faces itself.
>
> For example you would like to give any upward looking face an own
> material and fade it out to a second material, as the angle gets bigger.
> This can be achieved within viewspace, but only if you never intend to
> rotate the camera. Tilt it 180° to left or right and the bottom of all
> objects will show the first material instead of the second.
>
> So my questions are:
> a) Is there a way to access the normals in worldspace/localspace within
> material nodes?
> b) If not: Why was it never implemented? Seams to be very useful: Snow
> depending on surface angle; Trees covered with moss at the rain side,
> ice at the wings of a plane, etc.)
> c) Is there any workaround that would also work on animated meshes?
>
I also miss this!
Cycles allows you to access the normals in world space, so that's a 
small mercy!  I'd love to get this in BI!

There is a hack workaround... it uses a distant light, light group 
exclusivity and an extra material in your node setup.

Here's a video tutorial on how form Sebastian K

http://vimeo.com/23852345
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Material Nodes: No normals in worldspace?

[Tobias Oelgarte]

Am 20.07.2011 23:11, schrieb michael williamson:
> On 20/07/11 20:14, Tobias Oelgarte wrote:
>> way to influence the shading
>> depending on the orientation (not location) of the faces itself.
>>
>> For example you would like to give any upward looking face an own
>> material and fade it out to a second material, as the angle gets bigger.
>> This can be achieved within viewspace, but only if you never intend to
>> rotate the camera. Tilt it 180° to left or right and the bottom of all
>> objects will show the first material instead of the second.
>>
>> So my questions are:
>> a) Is there a way to access the normals in worldspace/localspace within
>> material nodes?
>> b) If not: Why was it never implemented? Seams to be very useful: Snow
>> depending on surface angle; Trees covered with moss at the rain side,
>> ice at the wings of a plane, etc.)
>> c) Is there any workaround that would also work on animated meshes?
>>
> I also miss this!
> Cycles allows you to access the normals in world space, so that's a
> small mercy!  I'd love to get this in BI!
>
> There is a hack workaround... it uses a distant light, light group
> exclusivity and an extra material in your node setup.
>
> Here's a video tutorial on how form Sebastian K
>
> http://vimeo.com/23852345
In the meantime I came to the same solution (seams to be the only one, 
without baking and limitation to static objects) as Sebastian König 
represented in this tutorial. But it is more or less a surround for the 
problem. Shortly after that I stumbled upon the exact same problems as 
inside the tutorial. It shows how complicated/limited it gets, even in 
this simple case. It could be much easier and powerful to have 
worldspace normals and maybe even the view-vector in wordspace 
coordinates. This would allow many new possibilities for reflection 
mapping and other cool stuff. On top of that it would work smoothly 
together with GLSL and shouldn't be so hard to implement. Maybe this can 
convince one of the programming gods to implement this feature? I would 
appreciate it very much, and I guess many others would also do.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] The dilation I am seeing in Blender is imo not good. I thought I'd propose an alternative (if there's support)?

[Morten Mikkelsen]

The dilation I am seeing in Blender is imo not good. I thought I'd propose
an alternative (if there's support)?


Here's a close-up of the dilation blender does -->
http://jbit.net/~sparky/blender_dial/bakezoom_BI_dial.png
Here's a close-up of the dilation I was able to do outside of blender using
diff. code --> http://jbit.net/~sparky/blender_dial/bakezoom_other_dial.png

The bumped visual you get using the first one is this (ugly filtering scar)
--> http://jbit.net/~sparky/blender_dial/scr_BI_dial.png
The visual you get using the other method is this (significantly more
subtle) --> http://jbit.net/~sparky/blender_dial/scr_other_dial.png

The blend file to produce the texture is up there -->
http://jbit.net/~sparky/blender_dial/bmake.blend

This is the full-res baked result you get with dilation using blender -->
http://jbit.net/~sparky/blender_dial/bake_BI.png
and this is using the alternative dilation -->
http://jbit.net/~sparky/blender_dial/bake_other_dial.png

I dumped everything here http://jbit.net/~sparky/blender_dial/ incl. a
blender file.



Let me know what you think.
Cheers,

Morten.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Simple Todos-Straighten

[Kyle Mills]

I have created/finished the "straighten" uvedit tool mentioned at
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Simple_Todos
Please check out Patch [#28045] Straighten tool from Simple Todos
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] The dilation I am seeing in Blender is imo not good. I thought I'd propose an alternative (if there's support)?

[Sean Olson]

This would be really nice to have working better in Blender.  I remember
running into this exact issue a while back and having to bring all my
normalmaps into photoshop to dilate them using the xnormal dilation plugin.
 A headache I'd love to avoid in the future.

-Sean

On Wed, Jul 20, 2011 at 5:13 PM, Morten Mikkelsen wrote:

> The dilation I am seeing in Blender is imo not good. I thought I'd propose
> an alternative (if there's support)?
>
>
> Here's a close-up of the dilation blender does -->
> http://jbit.net/~sparky/blender_dial/bakezoom_BI_dial.png
> Here's a close-up of the dilation I was able to do outside of blender using
> diff. code -->
> http://jbit.net/~sparky/blender_dial/bakezoom_other_dial.png
>
> The bumped visual you get using the first one is this (ugly filtering scar)
> --> http://jbit.net/~sparky/blender_dial/scr_BI_dial.png
> The visual you get using the other method is this (significantly more
> subtle) --> http://jbit.net/~sparky/blender_dial/scr_other_dial.png
>
> The blend file to produce the texture is up there -->
> http://jbit.net/~sparky/blender_dial/bmake.blend
>
> This is the full-res baked result you get with dilation using blender -->
> http://jbit.net/~sparky/blender_dial/bake_BI.png
> and this is using the alternative dilation -->
> http://jbit.net/~sparky/blender_dial/bake_other_dial.png
>
> I dumped everything here http://jbit.net/~sparky/blender_dial/ incl. a
> blender file.
>
>
>
> Let me know what you think.
> Cheers,
>
> Morten.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
||-- Instant Messengers --
|| ICQ at 11133295
|| AIM at shatterstar98
||  MSN Messenger at shatte...@hotmail.com
||  Yahoo Y! at the_7th_samuri
||--
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patches Submitted

[Scott Giese]

My reasoning for assuming this was a bug:

1. Previously working scripts (2.49) broke.

2. m1 *= m2 is equivalent to m1 = m1 * m2, where m1 represents the Base
matrix and m2 represents the Influencing matrix.  This is more intuitive to
me.
There is no equivalent shorthand for m1 = m2 * m1.

e.g. Apply a series of transforms to produce a single transformation
matrix
contextMatrix = mathutils.Matrix()
for part in parts:
contextMatrix *= data.tran.matrix[part.matrix_index]
contextMatrix *=
data.tran.matrix[part.parent.matrix_index]
...
newObject.matrix_basis = contextMatrix

3. Treating leftMatrix as the Base and rightMatrix as the Influencing
facilitates a hypothetical method of varying argument counts.
e.g.  resultMatrix = Matrix.Combine(baseMatrix, translateMatrix,
rotationMatrix, scaleMatrix, ...)

The above outlines my thought process.  I was not aware that the change was
intentional.  In light of the "... stop breaking APIs?" discussion, we may
be better served by leaving it as-is.

Scott

-Original Message-
From: Campbell Barton [mailto:ideasma...@gmail.com] 
Sent: Wednesday, July 20, 2011 2:16 AM
To: bf-blender developers
Subject: Re: [Bf-committers] Patches Submitted

On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese 
wrote:
> Hi Gang,
>
>
>
> FYI. I submitted 3 patches for your review.  I'm new to the list and I
> wanted to give back to the Blender community.
>
>
>
> 28030  SCONS Build: Build Date reflects
>
 d=9&atid=127> "1" instead of actual date of build
>
> 28031  Minor typo in Blenlib
>
 d=9&atid=127>
>
> 28032  Python Mathutils: Matrix Multiplication Error
>
 d=9&atid=127>
>
>
>
> Great work guys!  Appreciate the great product.
>
>
>
> Scott

Thanks for the fixes, committed all patches however you're changes to
mathutils effectively only change the order of multiplication,

http://projects.blender.org/tracker/index.php?func=detail&aid=28032&group_id
=9&atid=127

In you're example
>>> print (m1 * m2)

Change to...
>>> print (m2 * m1)

This is a bit confusing because in C we have
mul_m4_m4m4(m1, m2);
 which is the equivalent to "m2 * m1" in python.

A while back Benoit Bolsee was concerned our matrix multiplication
order was wrong so we switched it (between 2.4x and 2.5x)

What makes you think the order in blender is wrong? what's you're reference?

Just checked and we're currently doing matrix multiplication
differently to numpy which doesn't bode well :S - test:

# --- snip
m1 = ((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0,
0.0), (0.6, 0.0, -0.05, 1.0))
m2 = ((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0,
0.0), (0.0, -0.02, -0.1, 1.0))

from numpy import matrix
n_m1 = matrix(m1)
n_m2 = matrix(m2)
print("\nnumpy\n%r" % (n_m1 * n_m2))

from mathutils import Matrix
b_m1 = Matrix(m1)
b_m2 = Matrix(m2)
print("\nmathutils\n%r" % (b_m1 * b_m2))

# --- output

numpy
matrix([[ 0.  ,  0.  ,  1.  ,  0.  ],
[-1.  ,  0.  ,  0.  ,  0.  ],
[ 0.  , -1.  ,  0.  ,  0.  ],
[ 0.6 , -0.02, -0.15,  1.  ]])

mathutils
Matrix((0.0, 0.0, 1.0, 0.0),
   (-1.0, 0.0, 0.0, 0.0),
   (0.0, -1.0, 0.0, 0.0),
   (0.62, 0.1, -0.05, 1.0))


# --- switch m1/m2 order for both mathutils and numpy. re-run

numpy
matrix([[ 0.  ,  0.  ,  1.  ,  0.  ],
[-1.  ,  0.  ,  0.  ,  0.  ],
[ 0.  , -1.  ,  0.  ,  0.  ],
[ 0.62,  0.1 , -0.05,  1.  ]])

mathutils
Matrix((0.0, 0.0, 1.0, 0.0),
   (-1.0, 0.0, 0.0, 0.0),
   (0.0, -1.0, 0.0, 0.0),
   (0.6, -0.0, -0.15, 1.0))


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers