Tilemap not spawned until window is resized

[will-hart]

Bevy Tilemap version

0.4

Operating system & version

Windows 10

What you did

Created a tilemap:

let mut tilemap = BevyTileMap::builder()
        .texture_atlas(atlas)
        .dimensions(24, 12)
        .chunk_dimensions(64, 64, 1)
        .auto_chunk()
        .texture_dimensions(16, 16)
        .auto_spawn(200, 200)
        .add_layer(
            TilemapLayer {
                kind: LayerKind::Dense,
            },
            0,
        )
        .finish()
        .unwrap();

Then added tiles using a loop (used println! to ensure loop was run). A iter of tiles is generated from these:

Tile {
    point: (x as u32, y as u32),
    sprite_index,
    ..Default::default()
}

The collected tiles are added to the tilemap:

 tilemap
        .insert_tiles(tiles)
        .expect("Unable to generate tilemap from tilemap data");

and then a TilemapBundle is created:

TilemapBundle {
    tilemap,
    visible: Visible {
        is_visible: true,
        is_transparent: true,
    },
    transform: Default::default(),
    global_transform: Default::default(),
}

What you expected to happen

Entire tilemap should be rendered.

What actually happened

The tilemap is built and component bundles spawned (verified by println!), but nothing is spawned until the window is resized.

Apr 14 22:41:39.174  INFO bevy_tilemap::system: Chunk (0, 0) spawned

Additional information

This is intermittent, maybe 25% of runs?

Here is an extracted repo - https://github.com/will-hart/tiles. Run the example with cargo run --example editor.

[joshuajbouw]

Ok, related to likely to the system order.

[will-hart]

I get a similar issue if I manually spawn chunks. The manually spawned chunks appear as expected, then:

1. when moving the camera, nothing changes
2. when resizing the window chunks are despawned and fewer a subset of chunks are spawned.

At this point in the code there are none of my custom systems running, its only default bevy plugins and the bevy_tilemap defaults.

P.S. 99% likely its user error, but I'm following the docs as best I can and the results are unexpected😁

[will-hart]

I just noticed the same thing happens for me in cargo run --example square_tile on this repo.

[eranimo]

Also getting the same thing when running cargo run --example hex_tile_even_cols . Is there a workaround? System order didn't seem to impact it.

[joshuajbouw]

Hmm, I know before Bevy 0.5 this wasn't an issue, I need to look into it more. It must be related to ordering. Thats the only thing that I can think of. I had fixed it, or so I thought before I released it. I guess I just got lucky with the order being right, or it behaves differently on Ubuntu.

[AlisCode]

Here to report that I have this bug as well (Manjaro, 64bits, WGPU renderer). Though no one mentions it, on my system I have a warning log "Can not get chunk at (X, Y), possible bug report me" when the tilemap show up first try. (warning issued from src/system.rs:85).

When the tilemap does not show up, not only does resizing the window show the tiles, but it also displays the bunch of warning.

For what it's worth, I tried fiddling around with the system order, but to no success. Any other pointer to fix this ?

[StarArawn]

I'm having somewhat of the opposite issue from everyone else where on resize of the window the chunks all move to zero zero which is bizarre.

[joshuajbouw]

@AlisCode Yeah, the there being a bug report me was a mistake to add in. It is supposed to do that check, but there was another one prior to it that would've prevented for even getting to the next point. Some later changes came in and removed that first bit altogether, which left that error in. I'll remove that.

@StarArawn Yeah, I realllyyy need to sit down on this. That is a totally new issue that I never seen before. So weird!

[B-Reif]

I'm also having this issue. I made a gist describing a basic setup that reproduces the problem. This problem still occurs even if the systems are re-ordered.

It seems like I can work around this issue if I spawn the camera entity immediately before spawning the TilemapBundle, in the same function (as it is in the bevy_tilemap examples). This is pretty inconvenient as I'd like to decouple the camera entity and the tilemap system.

[joshuajbouw]

Thanks that'll be helpful.

[AlisCode]

I think I've found the issue, or at least a part of it ! It's somewhat related to system ordering indeed ;)

The problem is in the chunk_auto_radius system. It's listening to window resize events, and will try to auto spawn chunks whenever a resize event has occured. This particularity is used to make the first spawn of the chunks of the tilemap happen on startup.

But if the entity containing the Tilemap hasn't been created yet, the spawn never occurs and only a "window resizing" event can trigger the spawn. This also explains why the problem is intermittent.

To fix this, I suggest setting a flag "requires_auto_spawn" on the tilemap, enable that flag when creating the tilemap, and enable it on every tilemap when a resizing event happens. I can have a go at implementing this, and I will, but if you have a better implementation idea let me know :)

[B-Reif]

We could also implement a separate system that queries on Added<Tilemap> and then reserve the resize system for only resize events.

[joshuajbouw]

I like the 2nd suggestion by @B-Reif

[AlisCode]

I also thought about that, but I'm not sure that this will solve the problem though. In the case of auto_spawning we still need the camera transform, and if no camera is available at the time the Tilemap is created, the problem is basically inverted but will remain, right ? It seems to me that we need some sort of flag to indicate "we must spawn chunks for this tilemap" ?

[zuiyu1998]

Is anyone solving this problem, if not, I can try to modify

[BrettWitty]

I hacked around this by creating a "balloon" entity (really a flag component) that had to be created every time I create a Tilemap. A system detects if any exist and "pops" them (despawning them), and sends a fake resize to every window (resizing to the same width and height).

I did it this way due to the system ordering and how events are scheduled with regards to app states. It's suboptimal but without library change, I couldn't see how to get around it.