FR: Methods to loop, pause, & randomize animated textures

[Durandal-Thoth]

I've put a lot of thought into this request over the past year or so as there are a couple of different ways to go about implementing it. What I've landed on which makes the most amount of sense to me is a combination of .eff file format enhancements and a couple of new sexps.

1. Addition of randomization flag to .eff file format

This would be a flag which allows us to define a range of frames in an animation to be played in a random order. A potential use case would be a particle effect which has a consistent startup and cooldown animation sequence, but a series of frames which play in a random order in the middle. Below is an example of how this may be formatted. If no range is defined, the entire animation would play in a random order.

$Type: DDS
$Frames: 40
$Rand: 10-20
$FPS: 60

2. Addition of a loop flag to .eff file format

Here's where things get a little complicated.

The loop flag would allow a range of frames, much like the $Rand flag, to be played in a number of loops defined either by the file format OR for infinity. In the infinity case, the loop could be terminated and the animation concluded via sexp. If the infinity/sexp part of this sounds niche, I can assure you that I have a very specific case necessitating it. Example below once more. For an infinite number of loops in the defined range, I would omit $Loop Count entirely.

$Type: DDS
$Frames: 40
$Loop Count: 4
$Loop Range: 10-20
$FPS: 60

3. Addition of stop-anim, start-anim, and stop-loop sexps

The first two new operators here should be straightforward. Stop-anim would cause an animation to stop on whichever frame number is defined. Start-anim would do the same but backwards, causing the animation to start on whichever frame is defined.

Stop-loop is a little more specific, and would allow the current loop to continue to the end of its loop range (using the example above, play to frame 20), and then continue on to the end of the animation (in the example above, frame 40). Stop-loop should probably include a boolean to either continue the animation from Frame 0, or stop the animation once it hits the end frame (again, 40 for the example above.)

IDEALLY we would be able to choose the mission objects affected by these operators, but it's understandable if that's not possible, and there exist workarounds to handle that in case it isn't.

I sincerely hope I've done an adequate job of explaining this request, and I am more than happy to elaborate and answer any questions.

[Goober5000]

The .eff format, on its own, would be effectively ignorant of these options. In some places .eff animations loop; in some places they don't. The treatment of the animation depends on the place it is used. So this issue really needs to be specific in scope for the use case -- I'll assume all of the requests are for animated textures. The good news is that any of the features would then also apply to all animation formats, including .apng and .ani, not just .eff.

Changing the behavior of an animation mid-stream is not practical, but these requests would make sense if they are thought of as options for the entire animation that could be then used as building blocks. For example, an entire animation could be randomized, or an entire animation could loop. Then different aggregate animations could be built by playing building block animations in sequence.

The bad news is, even taking all that into account, the render code does not currently have the ability to treat textures differently depending on custom settings. The only relevant field in use is base_texture_anim_timestamp. It might be possible to add similar data structures in ship to store timestamps on a per-texture basis (e.g. a SCP_map of texture names to timestamps) and to store flags for things like looping, reversing, pausing, and randomizing.

[Durandal-Thoth]

To clarify, the specific use cases I have for this are animated textures on the subspace warp effect (the 3d "bowl", not the tunnel or flash), and on textures used by the particle system and laser bitmaps.