[0.9.15] issue with PythonAPI/examples/no_rendering_mode.py

Setup

Describe the setup you are using to run CARLA along with its version:

• CARLA version: 0.9.15 (also reproducible on master @ PythonAPI/examples/no_rendering_mode.py)
• Platform: Ubuntu 22.04 (Linux)
• Python version: 3.10
• GPU:
• GPU Drivers:

Describe the bug

PythonAPI/examples/no_rendering_mode.py caches the rendered top-down map surface to cache/no_rendering_mode/<Town>_<opendrive_hash>.tga and reuses it on subsequent runs. However, the cache key is derived only from the town name and the OpenDRIVE hash — it does not include the values of the --show-spawn-points, --show-connections, or --show-triggers flags.

As a result, once any run has written a cached .tga, all later runs load that image and skip the entire drawing block, including the conditional code that respects the --show-* flags. In practice this means:

• If the first run of the script for a given town omitted --show-spawn-points, no subsequent run with --show-spawn-points will ever draw spawn points until the user manually deletes the cache directory.
• Toggling any of the three --show-* flags between runs appears to have no effect, which is confusing and looks like the flag is broken.

The relevant code lives in MapImage.__init__ in PythonAPI/examples/no_rendering_mode.py (line numbers from current master):

• L470–L473: filename is built from carla_map.name and opendrive_hash only.
• L477–L479: if the file exists, self.big_map_surface = pygame.image.load(full_path) and the constructor returns without executing the drawing code below.
• L816 (if self.show_spawn_points: ...) is inside that skipped drawing block.

Steps to reproduce

1. Start the CARLA server:
   复制

   ./CarlaUE4.sh -RenderOffScreen -quality-level=Low

2. Ensure no prior cache exists (or run the script once without the flag to create one):
   bash复制

   rm -rf cache/no_rendering_mode
   python PythonAPI/examples/no_rendering_mode.py --map Town03

   This writes cache/no_rendering_mode/Town03_<hash>.tga.
3. Now run with the flag:
   bash复制

   python PythonAPI/examples/no_rendering_mode.py --map Town03 --show-spawn-points

4. Zoom in on the pygame window — no spawn-point arrows appear anywhere on the map.
5. Delete the cache and run the same command again:
   bash复制

   rm -rf cache/no_rendering_mode
   python PythonAPI/examples/no_rendering_mode.py --map Town03 --show-spawn-points

   Spawn-point arrows now appear as expected.

The same reproducer works symmetrically for --show-connections and --show-triggers.

Expected behavior

The --show-spawn-points, --show-connections, and --show-triggers flags should produce visible overlays regardless of whether a cached map surface exists on disk, and toggling them between runs should change what is drawn without requiring manual cache invalidation.

Logs

No errors are logged on either the server or the client. The bug is silent — the cache load path succeeds and the flags are simply not honored.

Server log (Unreal/CarlaUE4/Saved/Logs/CarlaUE4.log): nothing relevant. Client stdout: normal pygame startup, no warnings.

Scripts

Reproducer is PythonAPI/examples/no_rendering_mode.py itself; no additional script needed. For reference, the offending section:

# PythonAPI/examples/no_rendering_mode.py, MapImage.__init__
opendrive_hash = str(hash_func.hexdigest())
filename = carla_map.name.split('/')[-1] + "_" + opendrive_hash + ".tga"
dirname = os.path.join("cache", "no_rendering_mode")
full_path = str(os.path.join(dirname, filename))

if os.path.isfile(full_path):
    # Load Image
    self.big_map_surface = pygame.image.load(full_path)
    # <-- drawing block below is skipped, including `if self.show_spawn_points:`

Screenshots

N/A — the bug is the absence of overlays. Screenshots before/after rm -rf cache/no_rendering_mode would show an identical map surface with vs. without brown spawn-point arrows.

Additional context

Suggested fix: include the --show-* flag values in the cache filename so each flag combination has its own cache entry, and existing caches are not falsely reused when flags change. Minimal patch:

filename = "{}_{}_{}_{}_{}.tga".format(
    carla_map.name.split('/')[-1],
    opendrive_hash,
    int(bool(show_triggers)),
    int(bool(show_connections)),
    int(bool(show_spawn_points)),
)

Alternatively, invalidate the cache automatically when the flag set differs from the one recorded alongside the cached surface (e.g. by writing a small sidecar JSON next to each .tga).

A secondary usability issue worth noting while touching this code path: even when spawn points are drawn, they are rendered as small COLOR_CHOCOLATE_0 arrows without index labels, so users cannot correlate an arrow on screen to the integer index returned by world.get_map().get_spawn_points(). Adding a small index label next to each arrow would make the flag meaningfully useful for scenario authoring, which is the common reason people enable it.

Two things to double-check before you file it:

- Confirm your CARLA version and platform in the Setup block. The line numbers I cited are from current `master`; if you're on 0.9.15 they'll shift by a handful of lines but the same code is present. You can point to your installed version's copy of the file if you'd rather.
- If you want to hedge, attach a screenshot pair (cache present vs `rm -rf cache/no_rendering_mode`) so the maintainers can confirm at a glance. Not required, but it usually cuts triage time.

File it at https://github.com/carla-simulator/carla/issues/new with the "Bug report" template selected — the sections above map 1:1 to that template.