-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crashing After Rendering 1 to 2 frames #31
Comments
Same issue here (blender 3.6). There is a way to get around this by baking the wiggle first and then muting wiggle, before rendering, so that way you are basically just rendering an ordinary bone animation with no live physics, but it would be nice to be able to render without having to bake and disable the addon. |
this is unfortunately a hard limitation of the addon and the way blender handles data internally. you have to bake and mute the live effect before rendering. i had tried to add logic so it auto mutes itself when rendering, but i've found it still seems to get into a crashable state. i can at least look into that aspect of the issue. another way to usually avoid crashing is to use blender's 'lock interface' option for rendering. i welcome any input from developers experienced working with python frame handlers during render. the issue best as i can see has to do with renders creating a separate copy of data in memory that is differently evaluated than the viewport, and it is really difficult accessing and writing to the proper versions of data, especially when you get into dependencies of parenting, constraints, colliders, etc. i'd managed to get simple cases working for renders, but it would fall apart with any level of scene complexity. also worth noting, since the live effect is evaluated based on frame change updates, it doesn't work with motion blur which skips around during render evaluating previous and next frame motion vectors. it would need to maintain a cache of already evaluated frames, which, beyond a point, is just adding a whole bunch of data management complexity that basically is reinventing what baking would do. |
I think it would be a good idea to add some sort of warning into the add-on which tells the user to bake and disable before rendering, because I spent a very long time figuring out why my renders were crashing before I found out it was caused by the wiggle add-on 🥲 |
Same problem encountered. |
I had this problem too. Didn't think to bake it. I'll try that. |
I had the same problem and my workaround was adding |
Oh thanks for this! I’ll have to see if there’s any unintended consequences to adding that line to wiggle pre, but maybe it’s just something I overlooked! update: https://github.com/shteeve3d/blender-wiggle-2/releases/tag/v2.2.3 |
How do I get two chains to self-collide, and the simulation becomes extremely unstable when I put the chains in the collision set |
Yeah if anyone sees this, renders crash every time after a few frames in Blender 4.0. I'm using this on a client project so it's very scary and disheartening for it to not render at all near due date. I would buy this as an addon if it can work in Blender 4.0 and beyond though, it is brilliant and extremely useful. I tried all of the previous mentioned troubleshooting, the baking + muting the wiggle, disabling the addon, the lock interface in blender before render, and trying a the previous version of the addon (2.2.2 from 2.2.3). I'm surprised it still crashed after completely removing the addon (maybe it still lingers in the codes? IDK how this stuff works). There's another addon just like this but I refuse to switch because I immediately fell in love with this one, plus I already nearly completed a project with it and can't imagine starting it all over, especially near the due date. |
I rendered once in Blender 4.0.0 and 4.0.2 with Wiggle2 2.2.3 for a test but it was ok. But idk what if with other add-ons or in a bigger complicated project. Wiggle seems to leave some properties such as |
The add-on crashes blender when rendering, after a frame or two, the render has no problem after I disable the add-on
The text was updated successfully, but these errors were encountered: