duckiebots, trees, traffic lights, etc., use their own files to define their colors. We can't change their texture as easily as we can do it for barriers, asphalt, duckies, etc.
The test_segmentation.py file found at the root is temporary. It's there to help the reviewers test this feature.
The way the new colors are generated for objects is by simply hashing their names into their ascii codes, and then chunking by groups of three, and then making sure these chunked numbers are under 255, so that it can work as a color code. This works though, and it's very simple to debug and implement. We might want to define other colors though, because right now, the colors are 100% based on the name of the files that describe the texture that the object uses when it is not segmented.
This feature, while neat, is kind of niche. So we don't want to assume the user is going to use it when the user runs the gym. For this reason, all the segmented textures are generated on the fly. They're still cached as normal, so they're not getting loaded twice into memory, but their non-segmented counterpart is indeed getting loaded too. Additionally, since the way we load them is lazy (we only load them if we need them), the first time each segmented texture is used, it has to get generated, so the simulator is slower while it does so. This is atomic from the point of view of the environment's steps though, so this won't mess up anything training-wise. It's just annoying for a human observer
Known issues:
test_segmentation.pyfile found at the root is temporary. It's there to help the reviewers test this feature.