Just tested on macOS and it looks like it has been resolved. Have checked on 3.0 and 2.93, both render fine 👍

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.

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?

Thanks guys. Hopefully I’ll have some time this weekend to put together a sample that better illustrates the problem.

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.

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.

If you think that's the best way to go, it sounds good to me :)

Hi Dalai,

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 ?

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...

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?

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...

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.

Sometimes it takes a couple of frames to render before crashing, but it's basically as simple as hitting the render button.

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.

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...

I ran into it on a real production, it's how I found it...

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:

Fantastic. Thank you guys :)

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).