Being able to choose the texture-atlas sprite index over time

[cBournhonesque]

Looking at your example texture-atlas sprite-sheet, it looks like it could be useful to have another way to choose the TextureAtlas index: have it change over the time elapsed in the particle. (for example for some 'explosion' particle that turns into a cloud of dust).

I'm guessing the input would be a Vec<f32, usize>:

• the first number if the percentage of the particles life (between 0.0 and 1.0)
• the second number is the sprite index to use between the current percentage and the next

(maybe a better data structure would be more appropriate)

[abnormalbrain]

@cBournhonesque That's a good idea. Btw, that's pretty much exactly how the Gradients work, with the only difference being that it lerps between the current and next value instead of just choosing the current.

As far as implementation, another option would be to go with a pattern closer to traditional sprite animation like this: https://bevyengine.org/examples/2d/sprite-sheet/ and just have it rotate between the values with an even timeframe. This is probably a bit more efficient, particularly if there are many frames in a particles animation since the stated approach requires a linear-time iteration through the potential indexes each frame. The gradients technically have this problem as well. If you were to use a system with a gradient that had a ton of states, you'd probably start to see a performance impact, particularly at high particle counts. I don't know how common of a use case that would be though.

I would guess the average use case would be that the lists are small, like 2-5 states. In that case, the linear iteration is likely not an issue until you're into the thousands of live particles (depending on hardware).

The usability tradeoff would be that it'd be a little bit easier to define using the animation timer. You can specify the indices and a single frame time. But then all of your frames have to be displayed evenly.

It also means using fixed timing instead of it adapting to the lifetime of the particle. Which I'm not sure which is better, in that regard, as animations often need pretty specific timing to look right, and having to mess with percentages and lifetimes may be a bit of a pain, especially if you have to end up adjusting the lifetime later and need to then recalibrate the percentages, but it is technically less flexible.

In the duration-specified approach, it's a little less ergonomic to set up as you have to specify each frame individually, but you have the customizability if you want it. However I suppose that could be solved with a helper function. But also you can't have a repeating pattern without defining it yourself (which may potentially exacerbate the linear-iteration problem).

Of the two, I'd lean slightly more to the timer route based on potential ergonomics and performance advantage, but open to your thoughts or other ideas as well.

[Rayoule]

Here is how the texture atlas example looks with these modifications !

[abnormalbrain]

Closed by #45