[GymAPI Question] why new render api was introduced?

[Denys88]

Question

Previously I was able to use same config with env configuration to create environment and then render it when I want to.
Now I need to pass render_mode to the constructor.
It is very inconvenient right now because I need to have different configuration setup for training and testing.
I don't any good reason why this parameter should be passed to the constructor. I am not even talking about a lot of broken environments because of the backward compatibility.
is there any way to turn on/off rendering now?

[younik]

Hello @Denys88,

All the reasons can be found in these discussions: #2540 #2671

TL;DR
The new render API was introduced because some environments don't allow to change the render mode on the fly and/or they want to know the render mode at initialization and/or they can return rendering results only at the end of the episode.

If an environment can work with single render calls, it should provide a custom mode for single rendering, e.g. single_rgb_array. In this way, the environment will not perform the computation during training, and you can call render() only when you need, as before.

I hope this answers your question; please let me know if there are other major issues with this new API.

[Denys88]

thanks for the answer @younik it explains your motivation.
A lot of environments have configuration which impacts training which we can set in gym.make call.
But passing this argument to the make is still pretty controversial. Something like enable_render() would be more convenient.

[younik]

thanks for the answer @younik it explains your motivation. A lot of environments have configuration which impacts training which we can set in gym.make call. But passing this argument to the make is still pretty controversial. Something like enable_render() would be more convenient.

Can you provide a use case when enable_render() is more convenient than single rendering mode?
Thanks, your comments are helpful for doing the right implementation choice

[Denys88]

one of the examples:
Imaging I have my own vectorized env wrapper. Now I pass env name + additional parameters and it calls gym.make with same parameters in each process. If I want to enable rendering for onyl one env I need to have pretty hacky code wich changes config for one env and doesn't change for other.
Second one is similar to first: some envs have different parameters in make which impacts training.
For example: dm2gym library gym.make('dm2gym:FishSwim-v0', environment_kwargs={'flat_observation': True}). And it is it a good idea is to store {'flat_observation': True} somehwere and make sure I dont change it but now again I need to touch this config just to turn on rendering when I want to. If add that there are other non-gym envs where I dont need to do it.

But if I have enable_render call I dont need to have different construction code for envs.

[younik]

one of the examples: Imaging I have my own vectorized env wrapper. Now I pass env name + additional parameters and it calls gym.make with same parameters in each process. If I want to enable rendering for onyl one env I need to have pretty hacky code wich changes config for one env and doesn't change for other. Second one is similar to first: some envs have different parameters in make which impacts training. For example: dm2gym library gym.make('dm2gym:FishSwim-v0', environment_kwargs={'flat_observation': True}). And it is it a good idea is to store {'flat_observation': True} somehwere and make sure I dont change it but now again I need to touch this config just to turn on rendering when I want to. If add that there are other non-gym envs where I dont need to do it.

But if I have enable_render call I dont need to have different construction code for envs.

In these examples, you will be able to use the single rendering mode, and everything will be as before. For example, you can pass single_rgb_array to the vectorized environments and then call render() on one of them only.

The real limitation of this new API is that it doesn't natively support render mode changing on the fly. For the rest, this will remain pretty general, we allow the different environment to define their supported behaviour.