Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Remote rendering issue with env.render(mode='rgb_array') and env.get_image()

See original GitHub issue

This is an issue I typically have with Mujoco-based simulations when running remotely. Basically rendering is problematic, even in rgb_array mode where we want to access the image frames.

Is there a workaround for this issue? The OpenAI gym envs have the same issue and I only know DMSuite somehow bypasses this - where I can render in rgb_array mode.

So the errors you would get are the followings :

env.render(mode='rgb_array')

GLFW error (code %d): %s 65542 b'EGL: Failed to get EGL display: Success'
Creating window glfw
X Error of failed request:  255
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  136
  Current serial number in output stream:  137

env.get_image(width=84, height=84)

ERROR: GLEW initalization error: Missing GL version

Issue Analytics

State:
Created 4 years ago
Comments:8 (4 by maintainers)

Top GitHub Comments

1reaction

ryanjuliancommented, Dec 20, 2019

Are you rendering environments on a machine without a display (i.e. headless)?

If so, the way we get usually get around this limitation with gym (mujoco_py) is to introduce a fake display. This gives OpenGL an in-memory frame buffer to which it can render frames, so that they can later be read out when you call env.render(mode='rgb_array')

Our Dockerfile does exactly this so that we can run tests with rendering on the CI servers.

Some options, you can…:

…use our Dockerfiles directly by calling make run from the root of the repository.
…create your own Dockerfile derived from ours, which is based on the Dockerfiles from garage
…use headless rendering directly on your machine by installing xvfb and then calling your entrypoint with xvfb-run (see this example from the Dockerfiles)

Note: dm_control avoid this limitation by having a more sophisticated rendering backend, which choose a different rendering driver system if it detects the machine is headless.

0reactions

seolhokimcommented, Nov 9, 2022

I found how to solve this problem

import matplotlib.pyplot as plt
plt.imshow(env.render(offscreen=True))

Top Results From Across the Web

I'm getting an error with env rendering - Stack Overflow

I have figured it out by myself. The solution was to just change the environment that we are working by updating render_mode='human' in...

Rendering Environment Outputs & Q-Learning

In this article you'll learn how to render OpenAI environment outputs with env.step() functionality, which we refrained from using earlier in environments like ......

gym render in jupyter | The AI Search Engine You Control

(rendered indirectly using Ipython display). env = gym.make("CartPole-v0") env.reset() prev_screen = env.render(mode='rgb_array') plt.imshow(prev_screen) ...

DQN PER with Convolutional Neural Networks - PyLessons

So, here is the function to get rendered pixels: img = env.render(mode='rgb_array'). We'll see the following RGB image:.

Rendering OpenAI Gym Envs on Binder and Google Colab

Getting OpenAI Gym environments to render properly in remote ... state = env.reset() img = plt.imshow(env.render(mode='rgb_array')) done ...