Closed fentanes96 closed 5 days ago
Regarding similar Issues, I've checked this one #1043, but my question is still open:
... when I used the "human" or the "rgb_array" render mode to visualize the trained policies interacting, the animation seemed very odd to me ...
Yeah, it's odd but I believe what you are seeing is the intend behaviour. That behaviour may or may not be a good choice - but that's a different issue. I haven't looked at this env for a while so I may be mistaken on some of this.
If there is a zoom out / zoom in mechanism to keep the animation centralized, shouldn't the size of the particles change?
As I recall, the The "zoom" isn't actually zooming in or out on the image, it's changing the scale of the display box to fit all the items. However, the display size of the objects shown does not scale along with the box size as you expect. So they aren't drawn to scale. They are drawn with a fixed radius in pixels, which can be misleading.
In my results, I've detected sometimes a variation in the distance between the obstacles. I think this shouldn't happen if we are only moving the "camera".
Yes, this shouldn't happen if the obstacles don't move. Can you give an example of the distances between obstacles changing? The results you includes look like the obstacles are fixed, so the distances should be fixed too. If that isn't the case, that's something that needs to be investigated.
Thank you for the answer.
Can you give an example of the distances between obstacles changing? The results you includes look like the obstacles are fixed, so the distances should be fixed too.
Yes, I wasn't very clear on this part. I meant the obstacles appear to be moving, when we look at the rendered frames. For instance, we can see it happening on the GIF I used as an example above.
However, this effect can be explained by the way the display scaling works. As you mentioned, if the objects are not being scaled together with the display, I think we can wrongly perceive the obstacles getting closer to each other, when in fact it's just the display.
These environments have had some pretty serious design flaws for a long time and are basically only kept around because people find them useful for benchmarking, I could see potentially updating rendering (to scale accurately for example) at this point I don’t think it’s worth the dev hours from our end
I could see potentially updating rendering (to scale accurately for example) at this point I don’t think it’s worth the dev hours from our end
Is this a desirable change? We had an intern with the same confusion as the OP. I remember looking at this and thinking it could be a simple change. If this is valuable, I might be able to add a PR at some point.
Would that require bumping the version number on all impacted envs?
It would but I’m not an expert on the envs so can’t comment much on it, would have to talk with Ben Black or Jordan or someone else for confirmation. How exactly would you approach it, would it be sizing them dynamically so you can see the scale better?
I can try tackling this. I narrowed down the code that rescales the window and its present within simple_env.py. This environment is used as a base class by almost all the mpe simple environments so this is not specific to simple_tag
@elliottower @dm-ackerman I have pushed a PR for review that implements dynamic resizing of entities in the simple MPE environments. A demo can be seen below:
Notice how the zoom out effect is more intuitive in the dynamic resizing case
Before dynamic resizing:
After dynamic resizing:
Describe the bug
I'm using the Simple Tag scenario to run some MARL algorithms. However, when I used the "human" or the "rgb_array" render mode to visualize the trained policies interacting, the animation seemed very odd to me. It does not seem to be behaving as described on the MPE docs page.
From the Render section in the MPE docs, "Rendering displays the scene in a window that automatically grows if agents wander beyond its border". I do not see this happening in my results.
Also, when I look at the generated animation, it seems the landmarks are actually moving. I've even confirmed that the landmarks are not moving by checking their positions and velocities from the unwrapped env, just to be sure (in the code below):
Here's a GIF generated with the code below using the standard loop with random agents:
Code example
System info
Installation pip install pettingzoo[mpe]
Versions PettingZoo version: 1.24.3 PyGame version: 2.3.0
OS Ubuntu 22.04.4 LTS
Additional context
No response
Checklist