Open Giwayume opened 3 years ago
The texture atlas feature in general is designed to work with low-end mobile platforms, where using normal maps is expensive in the first place. Therefore, I'm not sure if this will be implemented, especially in 4.x where support for atlas textures may be removed (or at least left in maintenance mode).
It's also useful for web on lower end laptops. Sure normal maps can be expensive depending on the hardware. All the more reason to optimize...
Also don't forget game development includes progressive enhancement for multiple platforms. If normal maps truly is too performance intensive I could easily remove them by replacing the shaders. But does that mean I should also have to modify my entire project to re-import everything a different way just because I'm building for mobile - normal maps vs desktop + normal maps?
I think an alphabetical sort as an easy option would be simple to implement.
This would also make adding normal maps to AnimatedSprite easier... just 1 atlas file to reference in the shader as opposed to hundreds of sprite frame images.
@Calinou Actually, using a texture atlas / sprite sheet is pretty much the only practical way to add a normal map to AnimatedSprite. I don't see how atlases could reasonably disappear in 4.0 because of this.
Godot version
3.3.3.stable
System information
Windows 7 64 bit
Issue description
Let's say I have 3 images for an animation, 000.png 001.png 002.png
I create a texture atlas from these 3 images and call it "atlas.png".
Each of these images has an equivalent normal map version, 000_n.png 001_n.png 002_n.png
I create another texture atlas from these 3 images and call it "atlas_n.png".
Now in this simple example, the atlas for the diffuse animation and the normal map probably line up exactly so "atlas_n.png" could be used in a shader as a normal map for "atlas.png".
The problem is when I have a bigger project with several animations. The order in which I generated "atlas.png" from all the different animation images could vary wildly from the order I generated "atlas_n.png" by selecting all the files and clicking "import". Which leads to the normal map version of the atlas no longer matching the original.
I guess what I would like to request is either some consistency in generating atlas texture files in the editor, e.g. sort all the file names alphabetically before sending to the atlas generating algorithm so you can expect consistent results from atlas map generation.
Or, build in some native feature into the import settings to specify which file is the corresponding normal map for that image, so this can be taken into account when generating an atlas.
Steps to reproduce
Assuming an animation with 3 frames: 000.png 001.png 002.png
And normal map versions of each of those images: 000_n.png 001_n.png 002_n.png
Your "atlas.png" and "atlas_n.png" do not match up. This simulates a common use case where new animations were added for testing (perhaps without normal maps), or frames were added/deleted and the normal map version wasn't re-imported in exactly the same way.
Minimal reproduction project
No response
Bugsquad edit (keywords for easier searching): AtlasTexture