2
$\begingroup$

I have vertex and face data loaded from a cube that was subdivided many times, with a total of 26138 vertices and slightly fewer faces.

I am loading the object in a script, and whenever I try to load it with mesh.from_pydata, I get a segmentation fault (core dumped) error.

mymesh = bpy.data.meshes.new(mesh_name)
myobject = bpy.data.objects.new(mesh_name, mymesh)


bpy.context.scene.objects.link(myobject)
print('loading from pydata...')
mymesh.from_pydata(vertices,[],faces)

vertices is either a numpy array or a list object. I've tried both, and the segmentation fault occurs in both. faces is a standard list of tuples corresponding to vertex indices.

Here is the log from /tmp/blender.crash.txt # Blender 2.78 (sub 0), Commit date: 2017-02-24 14:33, Hash e92f2352830 bpy.context.space_data.bookmarks_active = 0 # Property # backtrace ./blender(BLI_system_backtrace+0x1d) [0x19aad1d] ./blender() [0x104e2e6] /lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f720bccf4b0] ./blender() [0x19abc88] ./blender() [0x19ab12d] /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f720d2df6ba] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f720bda13dd]

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

The method from_pydata appears to be surprisingly brittle for something in Python. Something as simple as using a vertex index number that is out of bounds (number higher or equal to the number of vertices) will result in odd results followed by a segfault shortly after (for example by going from object mode to vertex mode).

Calling validate should at least prevent a segfault from happening. You'll have to look for what is exactly invalid with your parameters when calling from_pydata):

my_mesh.validate()

Edit: I spent a bit of time chasing segfaults with from_pydata myself until I eventually found reports such as the ones below. I don't imagine the use of it without validate since segfaults taking the whole process down are quite annoying.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Speculative at best. Never had an issue. Please add some evidence to back your claim. Quite possibly the answer is within the missing detail in question. For example if a list is made of object locations coords = [o.location for o in objects]. Using the list after removing an object will create a reference error, since the location vector is bound to the deleted object. (linking to scene after loading mesh could also help) $\endgroup$
    – batFINGER
    May 2, 2021 at 5:03
  • $\begingroup$ A good number of answers contain a speculative element, don't they? For example each time the answer to the question may depend on hardware, OS, how blender was built, how blender was installed, and the environment in which it is running. Otherwise the issue of calls to from_pydata resulting in segfaults is unfortunately all too real in my experience. Since you seem unsure about it happening I added references showing that it seems known to devs. $\endgroup$
    – lgautier
    May 2, 2021 at 14:20
  • $\begingroup$ Thanks for the info. Agree "speculative" is probably not the word I'm after. The method is built for speed, much of which will be lost if it also has to validates data. (The python code is available to peruse and uses foreach_set) As stated in both reports, not a bug and clearly documented. If you are unsure that you are using valid data, eg using vert index 10 in a face when there are only 10 or less verts, yep agree, would pay to validate first. (or make a wrapper etc). $\endgroup$
    – batFINGER
    May 2, 2021 at 15:02

You must log in to answer this question.

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