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 1


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

    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..).

enter image description here

Here the image draws a blue line between initial position and output of the obj.to_mesh function

responding to some of your questions

  1. 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"

  2. 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 case

  3. until you apply modifiers, the data returned by obj.data.vertices will reflect the object pre-modifiers. so doing an undeformed_co can't mean what you think it does, then it would be deformed_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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .