Thanks @Nathan Vasil (vasiln), it was a commercial project that ended a while ago :) We did some kind of workaround, think it was having several instances of the object being picked up with constraints based on if they were being held or not, then animated the visibility to switch between them. We did consider baking out the meshes, but didn't in the end.
Oct 8 2020
Aug 25 2020
Apr 7 2020
As it turns out, the eyelid on our characters isn't the only thing causing this render bug to occur. It's been marked as "known issue", would it be helpful if I dug into the problem further and uploaded more files experiencing the bug?
Apr 6 2020
Feb 14 2020
Thanks guys. Hopefully I’ll have some time this weekend to put together a sample that better illustrates the problem.
Feb 13 2020
Thanks Richard. Unfortunately we can't share anything from the project, but I'll look into duplicating the issue in another example that shows a bump in render times, will send it over as soon as I get a chance to put it together.
If I put this into context of the current project I'm working on, maybe this will convince you that this is something that needs to be looked at further.
Thank you for looking at this and also for merging the bugs, I wasn't quite sure if they were the same issue or not.
Feb 12 2020
Dec 31 2019
I'm finding it hard to replicate the bug with a shareable file unfortunately, the default cube render must have been a different issue. It's probably best to just close this bug report.
Dec 3 2019
If you think that's the best way to go, it sounds good to me :)
Nov 20 2019
Nov 16 2019
Nov 4 2019
Jan 31 2019
Sep 22 2017
No problem at all, I'd already converted the image sequence into a ProRes clip to finish off the shot, just wanted to report the bug ?
Sep 21 2017
Apologies, I was trying lots of different things (packing/unpacking) to figure out what specifically was causing the problem, so the .001 may be a bit of a red herring...
Yes, sounds plausable. The project was originally made on a Ubuntu machine, no problems. The image texture node was referencing an image sequence. Opening on macOS, without any changes (I was going to set it rendering), it was pink. Importing a single JP2000 image on macOS worked ok...
Sep 20 2017
Apr 24 2017
Feb 21 2017
Feb 3 2016
Jul 5 2015
Agree with you there Aaron, now I know about it, I can certainly work around it. Can't say things not working is solely within the realm of Blender though. The latest Premiere CC2015 feels like alpha software. Terribly buggy, almost feels like a waste of money...
Thank you Sergey, really appreciate the response and all of the hard work that you guys do.
Ah, sorry, I just re-read your response and understand now.
Um... You won't accept the bug report from me, but if I get the addon developer to submit the bug, you'll accept it?
Jul 4 2015
I've done a bit more testing and narrowed down the problem further. The text that's being animated by the addon needs to have an armature modifier, set to envelope, with the envelope of the bone covering the entirety of the text.
Ok. Finally got it, the addon 'Typewriter Text Effect' is causing the crash, can be downloaded here:
Clearing the preferences has stopped it crashing. Going to investigate what setting/addon is causing the crash...
Jul 3 2015
Yes, that's the button I enabled to turn on locked interface.
Would it help if I made a screen recording of the crash? What other information should I provide?
I'm not sure if that's causing the problem on my end. I often have Blender rendering for days with both GPUs and the CPU without it crashing. The GTX580 will be between 90 - 98 degrees for the whole of this period, but it doesn't fall down. With this scene, the GPU doesn't get a chance to even warm up before crashing...
As far as the high poly count, that's related to a separate bug that I haven't had a chance to submit yet where if I have very simple planes (low poly) I get black artefacts appearing in the renders. Will submit that when I get a good example and have time.
Jul 2 2015
Sometimes it takes a couple of frames to render before crashing, but it's basically as simple as hitting the render button.
Jul 1 2015
If it's all all relevant, the GPUs aren't connected to any displays (used purely for rendering), leaving the intel graphics to drive a monitor through Display Port
Sorry about the light details originally, pushing up against a deadline, ended up rendering without motion blur for the first draft.
Jun 24 2015
Jun 23 2015
Yes, good point. Ok. Here you go. Packed everything (tried rendering the packed version to make sure it crashes too). It's the scene that's active when you open. If you animate, it'll render a couple of frames, then crash with a segmentation fault...
Feb 10 2015
Nov 26 2014
I ran into it on a real production, it's how I found it...
Nov 24 2014
When I say "Seems to work fine", I mean that the bug I originally raised still happens, but Blender doesn't crash on the GPU when you try to bake.
Yes, I got a crash when I tried to bake on the CPU, but GPU seems to work fine. Maybe the issues are related?
Sure, here you go:
May 2 2014
Fantastic. Thank you guys :)
May 1 2014
Mar 28 2014
Ah yeah, build from builder.blender.org works fine. Sorry about that, must be something happening in the build I'm making from git. I'll be sure to check that next time before taking up your time. Also, the new bug tracking system is really nice, very fancy. Keep up the good work :)
Ah, just did a render and I can see that the masking is just not showing in the VSE preview window. See the attached screen shot (VSE above, render below).