Well, yes, if you have a screen then wether you enable background rendering or not will not matter. It’s when you render on a machine without a screen (or more precisely an X server on Linux) that the -b option will matter.
So I’ll suggest again: did you try rendering with the -b option as the first argument on the system where rendering otherwise fails with Unable to open a display?
So I tried as you suggested and moved -b at first, but still same result. blender -b "Dual#11.blend" -E CYCLES --render-output //frame_##### -F PNG -f -2
I tried the simple cube, in simple cube there is no Sync and Compositing required, but in the linked project there are some syncing and compositing that’s when the error shows up.
right after line 316 in windows output.
Strange. I tried the file you linked on a (Red Hat) Linux system without a GPU and without any X server running and it renders without errors using the command you use. This is with the slightly older blender 2.80.39.
And the position of the -b option indeed doesn’t matter here, apparently because the frame render with -f causes the UI to never get loaded as Blender exits after rendering.
Ah! Just tried the latest official binaries (2.80.75) and with those I also get the error you’re seeing! So it indeed appears that when the compositing step starts the text overlay is rendered (directly after rendering is Finished) an attempt is made to open a display, even when running with -b.
Quick guess after looking at the file: there’s two scenes in there, Scene and TEXT overlay. Both have their own setting of the renderer to use (set to Eevee in the file). When you use -E CYCLES from the command line it only sets the renderer on the current scene, leaving the other set to Eevee, which won’t be able to render headless as its directly tied to OpenGL.
Haven’t tried a workaround, but the above looks to be the issue.
Hi Paul,
Coming from the Sheepit Renderfarm we get the same error. Unable to open a display
Also with CYCLES projects and also with Blender 2.83.3.
I couldn’t find the settings of “the renderer to use” that you described. Could you please describe how you found it? Because we need to detect it, so we can block these kind of projects (that somehow use eevee) on headless machines.
Also sorry for reviving such an old thread but I detected these errors quite a lot recently.
@Devs: Could you please add something to the log output to see what is causing the Unable to open a display? I mean, the frame is finished and for saving Blender needs EEVEE? I’ve run --debug-all but I have still no idea why it is happening because Blender doesn’t tell anything. See the appended log log_2.90.txt (1.1 MB) log_2.83.3.txt (1.1 MB)
Maybe somebody else has an idea?
I now use the workaround with xvfb. sudo apt-get install xvfb xvfb-run -a "my command"
But the core problem persists. Blender still seems to use EEVEE somehow after the frame is finished with CYCLES. And I can’t find the reason… @brecht Should I open a bug report for that?
EDIT: The workaround is working for the strange cycles/eevee thing but is ■■■■■■■ up normal eevee projects. A frame that takes me locally 2 seconds takes 4,5 minutes on Colab.
@PaulMelis
Of cause you can’t reproduce it. With Xvfb your machine is not headless. But this im my whole point.
My machine is headless and should be fine rendering CYCLES. But it is not…
Okay, so how can we detect all the things that don’t work on headless machines?
Because as I said, I’m coming from a renderfarm and need to stop all unrenderable projects.
Also, for my project I couldn’t find any grease pencil things but I don’t exactly know what to look for.
I wish I were better at Blender and coding
The term “headless” is a bit overloaded, so what exactly do you mean by that?
A machine without a GPU
A machine with a GPU but without a display attached
A machine with a GPU, but that does not (or cannot) run an X server
Instead of blocking Blender scenes that contain display-related items, why not set up the renderfarm nodes to provide a software OpenGL implementation (i.e. Mesa) and X server? There used to be a blender-softwaregl binary included in the official binaries, precisely for the former purpose, but I don’t know how well it interacts with EEVEE (although I suspect Mesa supports a new enough OpenGL profile).
A machine with a GPU but without a display attached
That is exactly what I meant
Actually I never heard about an X server. Something I need to research…
Well, our “renderfarm nodes” are other peoples PCs. https://www.sheepit-renderfarm.com/
I’m not sure about things we need to install on their system. But we could put it in our tutorial section.
Right now is Xvfb causing a few problems. EEVEE frames that takes 2 seconds locally takes 4,5 minutes on Colab (on a Nvidia P100)