Add function to get Handle<Texture> from TextureAtlas

[Seldom-SE]

What problem does this solve or what need does it fill?

Currently, there is no way to get the Handle<Texture> at a given index from a TextureAtlas. This means that TextureAtlases can't be used in places that only accept Handle<Texture>s, such as ColorMaterials (I'm running into this issue because ImageBundle accepts a Handle<ColorMaterial>).

What solution would you like?

Add a way to get a Handle<Texture> from a TextureAtlas. Perhaps add a function, TextureAtlas::(&self, index: u32) -> Option<Handle<Texture>> or TextureAtlas::(&self, index: u32) -> Handle<Texture>.

What alternative(s) have you considered?

For any bundle, function, etc. that takes a Handle<Texture>, add an alternative that takes a Handle<TextureAtlas> and index.

Alternatively, if just a ColorMaterial could be generated from a Handle<TextureAtlas> and index, this would satisfy my particular use case.

Thank you!

[DJMcNab]

The fields of TextureAtlas are public, so you should be able to use the handles field.

However, the handles in a texture atlas are (generally) only set if the atlas was constructed using TextureAtlasBuilder.
These handles are also weak, so for the textures to stay alive, you must already have a reference to them somewhere. In which case, you should probably just use that reference instead

If you want to use individual textures, just use individual textures.

That being said, there is an actual issue here, which is that UI doesn't natively support rendering images from TextureAtlases. I'm not sure what a good solution is to that. It feels like this part of the rendering should be modular in some way, but I'm not sure.

[JaySpruce]

If I understand correctly, this was fixed by #5103, with the TextureAtlas::texture_rect method. It's not precisely Handle<Texture>, but I think it's equivalent (Option<URect> in main)

[Seldom-SE]

Yeah, the new API fulfills this use case