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
I even tried with the new dependency-graph....all the same.
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 case
until you apply modifiers, the data returned by
obj.data.verticeswill reflect the object pre-modifiers. so doing an
undeformed_cocan't mean what you think it does, then it would be
deformed_cosurely? -- 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.