Consistent pointer access error & crash

[node-]

Situation:

• streaming 16Gbs of OBJs
• crashes on different OBJs each time, even though they load in fine manually
• only when rendering (but I don't usually change the viewport keyframe to prevent too much caching, so might be able to reproduce without rendering)
• no memory issues, passes memtest

Since it's a pointer issue, it's likely outside the scope of the plugin, but I'm wondering if anyone has had similar behavior. My OBJ sequence is generated by a python script using some computational algebraic geometry. Can post the full crash report if necessary, but the important part is "EXCEPTION_ACCESS_VIOLATION".

I'm planning to run blender in a debugger to see how deep the rabbit hole goes.

[neverhood311]

Yes, this kind of sounds like an issue I've run into before.

First things first: which version of Blender and Stop Motion OBJ are you using?

Second, have you tried locking the interface during rendering (Render > Lock Interface)? There's an issue with Blender that sometimes makes it crash while rendering if a script is modifying the scene data between frames (like mine is doing). A well-known Blender addon, FLIP Fluids, has a similar issue and has posted some helpful guidelines for how to work around the issue. Locking the interface during rendering helps with this issue.

Third, have you tried rendering from the command line? (full disclosure: I haven't tried) If this is an issue with an interaction between the GUI/Viewport and the render engine, removing the GUI from the equation might help the issue. That being said, I haven't done a command-line render with Stop Motion OBJ in years, so I don't know how the latest version would handle it.

[node-]

Thanks! I'll try rendering from command line. Interface is indeed locked, but good to know the pointer issue could be between UI and render engine. Not very encouraging to see the post about how this issue might be a deep design flaw, but will let you knowif CLI rendering helps.

[node-]

No crashes yet, seems to be going further than before! Thanks for the help.

By the way, is there a way to potentially parallelize the disk reads? I find Blender spends a significant amount of time at the "Importing OBJ" step, meanwhile the disk is only reporting a short moment of reading happening, so blender seems to be spending a lot of time doing some OBJ parsing/caching. Obviously this is out of scope of the plugin since Python is limited by GIL, so maybe I'll take it up with some blender devs. Wondering how blender's multiprocessing API might look like - I'm worried I'm hitting the limit of what blender can do.

I'll report back when I chat with some blender devs.

[node-]

Looks like there is a build in the works! https://blender.chat/channel/blender-coders?msg=TQeYa8vc7RqCupBsq

[neverhood311]

No crashes yet, seems to be going further than before!

Good. Hopefully it goes all the way to the end with no problems. Let me know if it doesn't.

By the way, is there a way to potentially parallelize the disk reads?

Not without a significant amount of work. I'm just hooking into the built-in Blender OBJ, STL, and PLY importers, so I'm at the mercy of whatever they're doing. I know there have been several attempts at writing a C++ OBJ importer to replace the Python one, but I don't think anything is close to joining the main branch yet. Heck, I've even considered writing my own GPU-accelerated OBJ importer, but I just don't have the time. I've been closely following the latest C++ effort and it'll be a great day for Stop Motion OBJ users once it finally gets released.

By the way, I'm always looking for animations to feature on the project README. Do you have any of your work publicly-available somewhere?

[node-]

I'll share something soon! I'm building the branch soc-2020-io-performance after talking a bit with the author - hopefully that speeds up the render (though doesn't parallelize it).

Command line totally works by the way - no more crashing. Thank you for your help.