New parameters which would further manipulate the texture displayed on the particle polygon. Note that the SCALE of the particle itself is still in effect. It is analogous to the scale of a prim. At the same time, the texture repeats/offset of this suggestion is analogous to the prim's face. They would interact in the same way which currently happens with textured prim faces.

Static texture manipulation set:

Static texture parms act like those which govern the texture repeats/offset/rotation on a prim's face. In essence, it would allow a particle's displayed texture to be a subset of a larger image file. Same limitations as with prim faces, see http://wiki.secondlife.com/wiki/PRIM_TEXTURE .

Note that there are no start/end variations of these parameters because that would be better suited by supporting animated textures in particles. Animated textures have been suggested countless times before, but I'll briefly summarize them here (because I think under this implementation they would be very similar or related to what's proposed above).

Animated texture manipulation set:

This set largely resembles the existing texture animation function calls for prims, though without specifying any sort of face. See http://wiki.secondlife.com/wiki/LlSetTextureAnim . The animation mode parameter could accept the same flags used by llSetTextureAnim's mode parm. An important distinction to make: particles should not be synchronized, each burst's animation should play independently from the next. Alternatively, an additional PSYS_SRC_ANIM flag could be provided to toggle this behavior.

This feature is important to me because it expands what can be possible with particle effects. Additionally, it removes the implicit restriction that particles cannot reuse textures that were not explicitly designed to be used as particles. At the same time, it also has the potential to significantly reduce asset server load by encouraging consolidation of particle textures into one asset.

With this feature, users would be able to combine related images into a single asset and still allow different particle emitters to pick out unique looking texture data from that same asset. An experience within Second Life that uses multiple different particle textures could lump them into one asset and reduce the calls to the asset server to load them all. Even more interesting is the notion that these particle "sprite sheets" could themselves be subsets of an image file that includes other non-particle textures. For example, under this suggestion, a single texture could hold imagery for an experience's HUD, game pieces, and also particles. All within one asset!