There is no way to display an image without a sprite sheet.

[CBenoit]

I investigated to build a game featuring a destructible world on a per pixel basis.
This requires to somehow get an ImageBuffer on the world texture. Using the current way of loading and accessing assets I could not find a way to get that.
Also, when the user only want to draw a texture there is no need for a full sprite sheet. A simple component holding the handle to the texture would suffice as the full texture should be rendered.

[Moxinilian]

You can create a quad Mesh and add a Material to it with an associated Texture. It was the old way of displaying sprites.

[DoumanAsh]

Also turns out there is dedicated UiImage

You can use it with transform to render some image (https://github.com/DoumanAsh/pong/blob/master/src/game/components/utils.rs#L17) for images, though it is a bit limit

[AnneKitsune]

Mesh + Material is the way to go usually. I'm currently trying to find solutions so everything is using Material instead of having 3 different ways to render images

[Moxinilian]

Material will not be suited for all sprite rendering FYI.

[AnneKitsune]

How so?

[Moxinilian]

Because you don't want a 2D workflow to reason in materials.

[eira-fransham]

Surely that's also an argument to have a simple way to deal with non-spritesheet images too, though? That you don't want a 2D workflow to have to deal with materials?

[zakarumych]

Mesh is unnecessary overhead for sprite rendering.

[zakarumych]

You do want 42 ways to render images in 42 completely different situations if this means more performance.

[Moxinilian]

@Vurich Ah yes totally. I thought I mentioned it here, but this should be improved in the new sprite pass with the new renderer.

[torkleyy]

@omni-viral While I think the possibility to do that is great, there should always be a way that is simple and just works.

[happenslol]

Hi! I'm super interested in working on this. Before I start and go off in the wrong direction, here's how I would go about it:

• Make a component similar to SpriteRender, that works on an entire Texture instead of a SpriteSheet called TextureRender?)
• Provide methods to easily build a TextureRender in the same way that a SpriteRender is built. I'd use chapters 7.2 to 7.4 of the book as a reference here and try to make the process as similar as possible.

Any thoughts on this? Would I be required to write tests/add to the documentation for this? I'd document the code itself of course.

[AnneKitsune]

@happenslol I made a design for this. I'll be opening an rfc in a few hours. I will list the tasks inside of it, so you know what goes where if you want to work on it ;)

[Moxinilian]

I don't think this requires an RFC. @happenslol's approach is what I would have advised to do, so I'd like to know what is your idea first.

@happenslol if you are going to do it, I'd recommend extending the current DrawSprite pass. I think you should be able to use the current shader as is on top of the spritesheet stuff.

[happenslol]

I'm fine with either way, I just wanna make sure we don't do unnecessary work/anything twice. I'll have a look at @Jojolepro's RFC, no matter how I do it it will probably give me some insight since I haven't worked on this project yet. If I do start something, I'll do it tomorrow and check back here before.

[AnneKitsune]

I didn't get to finish it yesterday. I'll try to publish it today.

[happenslol]

I'm working on it now. So far I've only familiarized myself with the relevant parts of the engine and set up a simple example for testing. I'm calling the new type for a full texture Image for now, if you guys have any better ideas let me know. I see 2 ways of going about this:

1. Implement a custom render pass for simple images. This would be a strongly simplified version of the DrawSprite pass, not drawing in batches and instead just rendering the texture out with the same shaders DrawSprite uses.
2. Implement ImageRender on top of the DrawSprite pass, always just passing in one sprite without offsets that corresponds to the whole texture. This would probably result in a lot less code, but I don't know how much overhead it has and it doesn't feel intuitive to add a DrawSprite pass to render an image.

I'll probably try 2. and see how it feels. Any thoughts?

[AnneKitsune]

I published the rfc here amethyst/rfcs#5

[happenslol]

Ah, I see what you're going for. Makes sense to do that, but I feel like this is a little out of scope for this issue, since providing an easier way to render images is definitely a step in that direction, but more of a quick fix than a rework of the 2D passes in general.
I guess that means I'll just extend the DrawSprite pass (maybe rename it to something like DrawTexture pass to reflect that it does both now?) and then the rework can happen in a separate issue.

I also realized that extending the DrawSprite pass means that as long as we're drawing unordered, we're already getting batching for drawing multiple instances of the same full texture for free, since the sprites are sorting by their texture anyways. So that's a plus.

Is that alright with you guys?

[Moxinilian]

Sounds good to me. Thanks!

[happenslol]

I'm about done with the code itself, so I'm opening a PR for this. Not quite happy with the naming and I'm unsure how you guys handle "breaking" API changes (e.g. changing the naming for DrawSprite), but I think we can discuss that in the PR.