simple scenario:
I have a cube with a wave modifier and I would like to get the vertex positions with python.
I'm trying with bpy.types.MeshVertex.co
, but it gives me exactly the same as bpy.types.MeshVertex.undeformed_co
.
I even tried with the new dependency-graph....all the same.
Any ideas?
1 Answer
As far as I know you can not do it that way. You can make a temporary mesh and find the transformed coordinates, seen as a wave modifier doesn't scramble the Vertex indices. Using obj.to_mesh
is a reasonable way to do it and it's fast.
A commented example of Obj.to_mesh
import bpy
def get_verts_edges(obj, use_modifiers=True, settings='PREVIEW'):
scene = bpy.context.scene
obj_data = obj.to_mesh(scene, use_modifiers, settings)
verts = [v.co for v in obj_data.vertices]
# or..use a copy to avoid dereferencing due to the .remove()
# verts = [v.co.copy() for v in obj_data.vertices]
edges = obj_data.edge_keys
bpy.data.meshes.remove(obj_data)
return verts, edges
obj = bpy.data.objects['NameOfObject']
verts, edges = get_verts_edges(obj)
print(verts, edges)
If you aren't looking for faces, or edges you could drop the edges return value. The indices of obj.to_mesh
will match the indices of the original object (if it's just a wave modifier..).
Here the image draws a blue line between initial position and output of the obj.to_mesh function
responding to some of your questions
i've never used bpy.types.MeshVertex.undeformed_co , and can't for certain say what it's used for or how. But i suspect it's not used for getting the vertex coordinate "post modifier"
Stick a subsurf modifier on a cube, and then do
len(obj.data.vertices)
, it will say 8 (the original 8 and vertex locations). I understand where you're coming from, but that isn't the caseuntil you apply modifiers, the data returned by
obj.data.vertices
will reflect the object pre-modifiers. so doing anundeformed_co
can't mean what you think it does, then it would bedeformed_co
surely? -- And i would expect that only to produce useful corresponding coordinates if the total number of coordinates didn't change due to the modifier stack..- Q Why does a Displacement modifier's post-modifier vertex index not correspond with pre-modifier?
- A Without peaking at the code I can't say for certain, but the reality of algorithm design is that sometimes algorithms that break this vertex order perform much faster than if extra bookkeeping has to be done to retain expected indices. Because most operations and usecases don't even need this consistent index, only very few people (such as yourself) consider it a problem.