Map scaling introduces artifacts

[martinlindhe]

Running cargo run --example ortho_main and zooming out with Z, there is visible artifacts between tiles, as can be seen in attached video (Windows 10). Same issue is seen on macOS.

Using git master from today (bevy 0.5)

The issue starts to show in the video about 4 seconds in.

https://user-images.githubusercontent.com/181531/113852082-70e9e080-979c-11eb-916a-86ea451d484f.mp4

[dmtaub]

@martinlindhe I believe this is related to how the camera zooms relative to the meshes on which the tiles render.

If you round the camera zoom to less problematic values, you should be able to reduce or eliminate this behavior.

[martinlindhe]

@dmtaub thanks, that could work too. I'll try to work something out

[StarArawn]

Make sure you set the texture atlas filter to nearest as well. Example:

  atlas_texture.sampler.min_filter = bevy::render::texture::FilterMode::Nearest;

[martinlindhe]

Make sure you set the texture atlas filter to nearest as well. Example:

  atlas_texture.sampler.min_filter = bevy::render::texture::FilterMode::Nearest;

Thanks, but how would I go about accessing this, assuming we have some code that looks like https://github.com/StarArawn/bevy_tiled/blob/7dc64e5213d8b1338f578763ecd4be10c603cb39/examples/ortho_main.rs#L14-L19

[dmtaub]

@martinlindhe example added to ortho_main

[martinlindhe]

I have been testing this for a bit now and something is still off. Using the example ortho_main, when launched the issue still remain randomly. That is, on one launch the problem goes away, but in another launch the problem is back.

Closing the app and re-running cargo run --example ortho_main eventually leads to the problem going away. But on another launch the problem is back again.

It seems to work correctly like 25% of the times.

Windows 10, Nvidia drivers.

[martinlindhe]

Just a speculation, but could the issue I see now be because the set_texture_filters_to_nearest() system maybe is run in nondeterministic order?

[dmtaub]

That seems likely....

@martinlindhe if you replace the line that adds the system with .add_system_to_stage(PreUpdate, set_texture_filters_to_nearest.system()) after adding use bevy::app::CoreStage::PreUpdate; does it fix the issue for you?

[StarArawn]

Ideally a better way to fix this issue is to have some GameState for loading. You have a system check to see if the texture has been loaded and if it has edit the texture to set the filtering to nearest. Then you just change your game state to playing or something.

[dmtaub]

Indeed- that's exactly what we do in our game. We have a loading state where we listen for these objectReady events. My goal in adding this system is to demonstrate a quick and dirty way of achieving the same result. It looks like we'll have to demonstrate something about ordering as part of that. For the purposes of demo, I figure a PreUpdate system is ok--though we should comment that a better way is to use a GameState resource. If someone wants to make a simple demo that uses GameState, I'm all for it, though.

[martinlindhe]

That seems likely....

@martinlindhe if you replace the line that adds the system with .add_system_to_stage(PreUpdate, set_texture_filters_to_nearest.system()) after adding use bevy::app::CoreStage::PreUpdate; does it fix the issue for you?

Yes! This now works 100%, thank you very much :)