Particle flags for texture repeats and offsets
Fenix Eldritch
This is a refiling of BUG-5307
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:
- PSYS_SRC_TEXTURE_REPEATS: (vector) repeats. XY range +/-0.0 to +/-100 (Negative value flips, and Z is ignored)
- PSYS_SRC_TEXTURE_OFFSETS: (vector) offsets. XY range from -1.0 to 1.0 (Z is ignored)
- PSYS_SRC_TEXTURE_ROTATION: (float) rotation expressed in radians
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:
- `PSYS_SRC_ANIM_MODE: (integer) ANIM_ON | LOOP | REVERSE | PING_PONG | SMOOTH | ROTATE | SCALE
- PSYS_SRC_ANIM_SIZEX: (integer) horizontal frames. Ignored for ROTATE & SCALE
- `PSYS_SRC_ANIM_SIZEY: (integer) vertical frames. Ignored for ROTATe & SCALE
- PSYS_SRC_ANIM_START: (float) start position/frame number or radians for ROTATE
- PSYS_SRC_ANIM_LENGTH: (float) number of frames to display or radians for ROTATE
- PSYS_SRC_ANIM_RATE: (float) rate of frames per second
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!
Log In
Maestro Linden
Merged in a post:
Feature Request: Texture Slice in Particle effects
Journey Bunny
I'd like the particle system updated with a tiny, incredibly powerful addition: the ability to draw just part of a sprite as the particle texture.
For creations that need to produce multiple particle effects, this will improve asset management, loading, and drawing performance.
Simply, you would add optional parameters:
PSYS_PART_TOPLEFT_COORD
PSYS_PART_BOTRIGHT_COORD
These parameters are vectors. The topleft coordinate is the x and y coordinates of the "top left" corner where the particle image should start, and the "bottom left" vector is the x and y coordinates where the particle image ends.
These parameters default to the actual top left and bottom right (0,0, image_width,image_height) if unspecified, so no behavior changes in existing particle systems (since the whole texture would be used). If just one parameter is defined, the other remains the default. The third vector component is unused here.
I promised infinite benefits. Here's what I mean!
At present:
- We need to use a whole image per particle effect, and whenever we need to make complex effects that change particles, or setups with multiple particle systems, the end user experience is poor. Low-resolution, blurry grey images shoot out for a while until the images load.
- To "hack" this, we can sneak a copy of the particle texture into a part of a build, but we can only preload one texture per face.
- If we want to make a set of particle effects that all go together, we must create many image resources and keep track of lots of texture UUIDs. There's no way to group all the particle effects together.
- Particles are usually small images; they don't need to be lots of pixels! But in SL for now, we need use lots of pictures--one per effect sprite--to make effects.
- Tools for animated effects commonly create "cell animation" types of texture atlases, and if we want to cycle through those, we'd have to chop them all up and upload separately.
With this feature:
One single texture loads. It's cached by the region simulator and by the viewer. Many particle sprites can be stored on a single texture atlas, putting all the effect needed into one single loaded image. Switching particle sprites or firing particles from multiple systems happens instantly! Since all the sprites are on one image file, there's no more waiting for textures to load every time a new particle effect starts. Fewer loads on the simulator, fewer loads on the viewer, fewer GPU texture swaps, better experience. We win!
See attached image~ This could be a texture set for a variety of particle effects--in a game for example--all loaded in a single image! Instead of loading each image at the moment the particle system tries to use it (which is what we have now), all 16 particle sprites are loaded at the start, and ready to use on-demand.
Toothless Draegonne
This combined with the existing request for animated particles which has been waiting for implementation for years at this point would be an absolute win, at least in lieu of an llParticleSystem2 with a radically different approach to the whole thing.
Wulfie Reanimator
This kind of atlassing for particles would be really useful, currently we have to do all kinds of silly workarounds (as mentioned) to get a similar effect. Many particle effects need more than a single sprite.
A simple example might be a gunshot, which can be complex (flame, sparks, smoke with different lifetimes) and the effect should be immediate and consistent. A shared texture for each emitter would keep everything consistently loaded.