I have been trying to get data from an animated mesh to drive another object. Consider a subdivided plane with a displace modifier. The displace modifier has a clouds texture applied to it and the displace is being controlled by an Empty that is animated.
In the viewport, I can see the mesh is animated and fine. So I vertex parent an empty to one corner. Sure enough, the empty is following movement of the plane. But this is only a visual representation. The location of the Empty never changes internally.
Because the information is never truly propagated into the system, I can never get the actual location of a vertex that is in motion. I have tried hooks, vertex parenting, I have setup a pydriver and wrote script to examine the vertex values on a frame-by-frame basis and the values are never changed!
This leads me to the conclusion that the modifier stack is not written correctly. The current state of an object should be available to the API. And while we can accept the 2.4x series as flawed, I don’t think we should accept that 2.5 should work this way.
This is a huge problem when you start writing python script against a mesh that does not relay its information back to the system.
I created the test scene in 2.49 and then imported it into 2.5 and the problem remains. This seems like big news to me. That is why I posted here.
In general anything that ‘modifies’ an object’s position in blender actually modifies it matrix, not the Loc/Rot/Scale (which are used in calculating the matrix).
To get the position of the vertex in your first example (in world space) simply get the Matrix of the empty.
So in 2.5 the location is the first 3 elements in object.matrix[3]
Lets go back to the animated displaced plane without any empty’s involved. It is being displaced and the vertices are moving in the viewport, but how would I get the “TRUE” z-position of any vertex in the mesh using the 2.49 API? I really don’t want to vertex parent an empty to every vertex in the grid just to so I can use getMatrix on it.
Is this really the only way to do it?
There does not appear to be a getMatrix just for the verts.
It makes more sense, especially in 2.5, that the display parameters should already provide the Matrix calculated output for us. That way we can drive things with the values from our objects as they appear truly in space.
Modifiers don’t change the original data of the mesh, only a copy, otherwise subsequent changes to the modifier parameters would be cummulative and not work.
Internally it’s ok to think of Blender as making a copy of the mesh for each modifier that gets passed down the stack. To ‘fill’ a mesh block with the result of all modifier calculations in 2.49 use the getFromObject method of meshes.
original = Blender.Object.Get(“Original”)
baked = Blender.Mesh.New()
baked.getFromObject(original)
Also, remember (and as per the API docs) the baked mesh you create will be in ‘local’ space… to get its coordinates in the space of the original object you need to multiply each of its coordinates by the object matrix.
Thanks for explaining it. I can see now, that if a companion getFromObject exists in 2.5 it would be possible to write a new panel for the tools section that shows the modified location of say, an object on a path.