Only background color is visible in repo examples on my system, tilemaps are not visible

[EzraMoore65]

I have loaded in the map and can see with bevy-inspector-egui that the tile entities exist. I can also see in the assets section that the tilemap texture has also loaded, but nothing is showing up in the window. Have tried enabling different features like render, default, and atlas, but this shows no change. Only the background color shows, have also tried playing around with the translation and scale, but cannot get the tiles to show under any circumstance.

Code to set up world (Camera is created in another startup system which runs before this one

pub fn setup_world(
  mut commands: Commands,
  asset_server: Res<AssetServer>
) {
  commands.spawn(LdtkWorldBundle {
    ldtk_handle: asset_server.load("project.ldtk"),
    transform: Transform {
      translation: vec3(-(CANVAS_WIDTH as f32 / 2.), -(CANVAS_HEIGHT as f32 / 2.), 0.),
      ..default()
    },
    ..Default::default()
  });
}

Showing the tile entities are created

Showing the tileset texture has loaded

[Trouv]

Hmm that's strange. Could you show your Cargo.toml? And also, could you try running one of the examples in this repo?

[EzraMoore65]

Tiles do not load in the example project either.

I'm using Windows 10 with an intel i7 and rtx 3060 if that helps, cargo toml below:

[dependencies]
bevy = "0.10"
bevy_ecs_ldtk = { version = "0.6.0", features = ["default"] }
bevy_rapier2d = "0.21"
bevy-inspector-egui = "0.18.1"

[Trouv]

Hm okay it's not an issue with your repo then. Could you try running examples in bevy_ecs_tilemap? That repo handles all the rendering so the issue is likely there too.

Also it might be worth updating graphics drivers if you haven't recently just to eliminate that variable

[EzraMoore65]

Took forever to get graphics drivers updated since geforce experience is garbage, ended up having to do it the old fashion way. But they're updated now, bevy_ecs_tilemap examples work perfectly, but bevy_ecs_ldtk still does not render the tiles

[Trouv]

This is kind of a long shot, but what happens if you disable level backgrounds:

app
    .insert_resource(LdtkSettings {
        level_background: LevelBackground::Nonexistent,
        ..default()
    })

[EzraMoore65]

Yes! Setting the level background to nonexistent solved the issue. Is there an explanation as to why this works?

[Trouv]

So I think the actual level was rendering "behind" the background. It shouldn't be actually behind it, just rendering behind it because of some weird z-indexing issues. As of #171, the background color is rendered using a sprite instead of a single-tile tilemap from bevy_ecs_tilemap, which was mostly done to fix a similar z-indexing issue introduced by https://github.com/StarArawn/bevy_ecs_tilemap/pull/406, but it's also just a better design tbh. I'm guessing there's a weird bug with z-indexing between sprites and tilemaps now, and maybe a windows-specific one? That also fits with your platformer example screenshot only showing the background color and other sprites

[EzraMoore65]

Hmm okay that makes sense. Should I leave this issue open since that does seem to be a problem with the crate?

[Trouv]

Yes, I'll file an issue with bevy_ecs_tilemap w/ a minimal example later if I can create one, but if it's a problem upstream it's still good to keep this open for bookkeeping until it's resolved

[Trouv]

There have been some z-indexing changes to bevy_ecs_tilemap since the 0.10 release. Do you think you could check if this happens if you patch in the main branch of bevy_ecs_tilemap and re-enable level backgrounds? You can add this to your Cargo.toml:

[patch.crates-io]
bevy_ecs_tilemap = { git = "https://github.com/StarArawn/bevy_ecs_tilemap", branch = "main" }

[EzraMoore65]

Did not resolve the issue. Same thing happened.

[anefil]

I have noticed that the issue is not present in WASM builds, but is present in builds for windows. Also, setting level background did not resolve the issue for me.

PC specs: AdapterInfo { name: "NVIDIA GeForce MX230", vendor: 4318, device: 7441, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "511.23", backend: Vulkan } SystemInfo { os: "Windows 10 Enterprise LTSC 2021", kernel: "19044", cpu: "Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz", core_count: "4", memory: "7.9 GiB" }

Cargo.toml:

# (...)

[dependencies]
bevy_kira_audio = "0.15"
bevy_ecs_ldtk = "0.7"
bevy_editor_pls = "0.4"

[dependencies.bevy_ecs_tilemap]
version = "0.10"
features = ["atlas"]

[dependencies.bevy]
version = "0.10"
default-features = false
features = [

# (all default features without audio)

]

[cscorley]

For me, I see a similar issue on 0.11.0 in my private project.

However, running the example platformer reveals maybe a helpful hint. The first room loads fine, but the second room (going up the ladder) loads in blank.

2023-08-13T00:24:04.996148Z  INFO bevy_winit::system: Creating new window "Bevy App" (0v0)
2023-08-13T00:24:04.996516Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1
2023-08-13T00:24:05.460269Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce GTX 1070", vendor: 4318, device: 7041, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "530.41.03", backend: Vulkan }
2023-08-13T00:24:05.608443Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux 23.05 NixOS", kernel: "6.1.36", cpu: "Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz", core_count: "4", memory: "31.1 GiB" }
2023-08-13T00:25:16.501443Z  INFO bevy_window::system: No windows are open, exiting
2023-08-13T00:25:16.512203Z  INFO bevy_winit::system: Closing window 0v0

[Trouv]

What if you use this patch?

[patch.crates-io]
bevy_ecs_tilemap = { git = "http://github.com/StarArawn/bevy_ecs_tilemap", version = "0.11", branch = "main" }

[cscorley]

That works for both my private project and the platformer example. Sorry, I misread your original post in this thread as applying to the previous version only. Thanks so much for the rapid response!

[Trouv]

I misread your original post in this thread as applying to the previous version only.

Well you were kind of right - the new patches in bevy_ecs_tilemap are different from the ones mentioned earlier. Though, I am curious if the new patches resolve the original issue as well - @EzraMoore65 @anefil, sorry I didn't follow up with you folks.

[elenakrittik]

Having the same issue as the OP.

What if you use this patch?

[patch.crates-io]
bevy_ecs_tilemap = { git = "http://github.com/StarArawn/bevy_ecs_tilemap", version = "0.11", branch = "main" }

Did not help unfortunately.

[Trouv]

@elenakrittik Do the tilesets appear if you turn off level backgrounds in the LdtkSettings resource?

[elenakrittik]

Yes, it does help. Not sure if related, but player sprite still does not render when loaded via AssetServer.load() by default, and requires it's z index to be set to negative value to start displaying (default value is 1.0).

[elenakrittik]

Some more debugging info for those looking into resolving this issue. While working on #119, at some point in example creation i added a custom scale for OrthographicProjection when .spawn()ing Camera2dBundle and all sprites magically and instantly disappeared. Reverting to Camera2dBundle::default() got sprites back, but keeping scaling and tweaking LdtkSettings like proposed above for some reason did not help and sprites were all still invisible.

[focustense]

This is apparently still ongoing:

• Any levels loaded when the world is first spawned (i.e. starting level and neighbors) load correctly.
• Subsequent levels also load, spawn background, entities, etc., but do not render tile maps.
• Setting OrthographicProjection.scale is definitely not the cause, confirmed with A/B test.
• Level backgrounds are also not the cause, disabling them makes no difference.
• Patching in the main branch of bevy_ecs_tilemap does fix the issue (thanks).

It's a little surprising that whatever fix is in the main branch has not made it into the release. Last release of bevy_ecs_tilemap (0.11.0) was in July, and the main branch apparently contained the fix all the way back in April? Does anyone know what the specific bug in bevy_ecs_tilemap is, or have a link to the bug or fix commit, so that we can point our cargo manifests to a specific commit in case the master branch has other issues?

[elenakrittik]

• Setting OrthographicProjection.scale is definitely not the cause, confirmed with A/B test.

Would appreciate a MRE here. In my case it "definitely was" the cause, which i also "confirmed" with A/B test.

• Level backgrounds are also not the cause, disabling them makes no difference.

Same as above, a MRE would be very useful. This point sounds especially strange, since disabling backgrounds solved the problem for a lot of people.

• Patching in the main branch of bevy_ecs_tilemap does fix the issue (thanks).

It's a little surprising that whatever fix is in the main branch has not made it into the release. Last release of bevy_ecs_tilemap (0.11.0) was in July, and the main branch apparently contained the fix all the way back in April? Does anyone know what the specific bug in bevy_ecs_tilemap is, or have a link to the bug or fix commit, so that we can point our cargo manifests to a specific commit in case the master branch has other issues?

I'm not sure i understand what "fix" are you talking about?

[focustense]

MREs are not a trivial amount of work for this type of library, but seeing as how the issue seems to periodically reappear, I went to the trouble anyway in case it's useful for future incidences: bevy_ecs_ldtk_mre.zip

• Uses Camera2dBundle::default() and never changes the projection.
• Set to start in the center of the map, level 23.
• Neighbor levels (13, 22, 24, 33) all load and display correctly.
• Navigate the 5x5 grid by pressing any arrow keys.
• No levels render after the first selection.
• LevelBackground::Nonexistent only masks the issue by hiding the background; the tiles are still not there.

Maybe there was a different, background-related issue, back in April. bevy_ecs_tilemap did get a new release between then and now.

bevy_ecs_tilemap has zero references to OrthographicProjection so I'm pretty skeptical about that. Maybe you had some indirectly related problem, such as with FrustumCulling which is not enabled by default.

I'm not sure i understand what "fix" are you talking about?

If I knew the answer, why would I have asked the question?

But alright, rule 15. I went through the issues myself, and tried to narrow it down. Most likely it is StarArawn/bevy_ecs_tilemap#450, or StarArawn/bevy_ecs_tilemap#453 which is the same issue from a different perspective.

I guess Bevy 0.11 broke some things in the tilemap crate.

[Trouv]

Maybe there was a different, background-related issue, back in April. bevy_ecs_tilemap did get a new release between then and now.

You're right, the main confusion here is that there are two (maybe three?) different bugs that look visually similar being discussed in this issue. That's my bad, I could have managed this better, and I'll start now.

The bugs..

1. The original bug experienced by @EzraMoore65, where even examples weren't displaying tilemaps on their system.
2. The bug where spawning levels a second time seemed to break the rendering of that level's tilemaps.
3. The bug described by @elenakrittik where even player sprites weren't displaying, probably related to the camera.

Bug 1 seems to still be a problem as far as I am aware. I wanted to create a minimal example of this in the bevy_ecs_tilemap repository, but I didn't get around to it (sorry). I might not be the best person to create this example anyway since I can't reproduce it on my system. I'll rename this issue so that it's more clear that this is about bug 1.

Bug 2 has been resolved in the main branch of bevy_ecs_tilemap. I believe this was fixed in the following PR: https://github.com/StarArawn/bevy_ecs_tilemap/pull/451. The confusion about the date of this fix is understandable, given that I've suggested patching in main twice in this issue. The first patch suggestion was an attempt to fix bug 1, not bug 2 which appeared in bevy_ecs_tilemap 0.11. I have decided that this issue is not where the discussion of this bug belongs and have re-opened #233 to take that role.

Bug 3 seems like it is different from bug 1, since @EzraMoore65 is experiencing bug 1 in the repo examples. I appreciate you debugging this @elenakrittik. I think it may be worth creating a new issue out of this, if you'd like to do that, or I can do it myself if you're busy.

Sorry again for the confusion, I hope this clears things up a little bit.

[elenakrittik]

It seems my "bug" is not a bug at all. Apparently, Camera2dBundle::default().projection is NOT the same as OrthographicProjection::default(): Camera2dBundle's impl Default is:

impl Default for Camera2dBundle {
    fn default() -> Self {
        let projection = OrthographicProjection {
            far: 1000.,
            near: -1000.,
            ..Default::default()
        };
        // --snip--
    }
}

While OrthographicProjection's impl Default, however, has near: 0. as it's default. I'm not sure where and how exactly this starts affecting bevy_ecs_ldtk/bevy_ecs_tilemap, but what's clear is that this is a inconsistency in bevy itself, not here.

EDIT: Here's a simple patch to this repo's master to test youself:

--- a/examples/platformer/systems.rs
+++ b/examples/platformer/systems.rs
@@ -7,7 +7,14 @@ use std::collections::{HashMap, HashSet};
 use bevy_rapier2d::prelude::*;

 pub fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
-    let camera = Camera2dBundle::default();
+    let camera = Camera2dBundle {
+        projection: OrthographicProjection {
+            far: 1000.,
+            // near: -1000., // uncomment this to fix
+            ..default()
+        },
+        ..default()
+    };
     commands.spawn(camera);

     let ldtk_handle = asset_server.load("Typical_2D_platformer_example.ldtk");

[ck2244hk]

I ran into the same issue as @anefil a couple of days ago. I'm just putting a note here for anyone who has come across the same issue, and the above solutions did not help. Try changing your rendering backend to DX12 instead of using Vulkan. With PowerShell $Env:WGPU_BACKEND="dx12" cargo run It fixed the problem for me. I also own an old window laptop that uses the MX series GPU, and Vulkan has no support on it. The tilemap rendering lib will fail silently, as if nothing happened. It is more likely to be an issue on the bevy_ecs_tilemap repo, but since there is no one talking about this, I will put my comment here.