Random texture offset per particle

[rich_is_bored]

I have a material with a scrolling texture. I have a particle effect. At present the texture scrolls across all the particles in unison but I need to offset the texture randomly on a per particle basis.

 

I thought shaderparms would be the solution here but it appears they are only applicable on a per entity basis. I tried looking through the source code to be sure but I don't see anything specific to particles that would help.

 

This experiment also happens to use a vertex/fragment program. I bring this up because if shaderparms are not an option perhaps there is some vertex or fragment properties I can use to derive a static value unique to each particle?

 

[Bikerdude]

Afternoon fella

 

Well I never thought I would be giving you advice , but I think the the way to approach this is to have multiple stages and then use the particle editor to offset them -

 

 

 

 

 

 

 

[rich_is_bored]

That setting repositions the particles where I only mean to offset the texture applied to them.

 

At any rate I've got an idea I'm going to try later. If that fails I'll post a video or some screenshots so it's more clear what I'm after and why.

[SteveL]

Interesting problem. We fixed a similar issue for 2.04 in #4132, where adjacent weather patches looked identical. The problem is you want a different setting for each weather patch or particle quad, but it can't be random. It has to persist for that patch or quad from frame to frame. For weather patches, I took the centre of the particle effect's bounding box as part of the random number seed. That persists from frame to frame but will be different for each weather patch.

 

That won't fix your situation. You need each individual quad to have a different offset to its scroll. There's no way to fix that at the entity level as you found out. And you can't fix it in the material definition either, because all the quads for a particle stage are a single draw call -- so any vertexparms or scroll parameters that you set would be shared by all quads in the particle stage.

 

A fix in the vertex shader program would work, if we can think of a number that would (1) differ for each particle quad, and (2) be constant at every vertex of the quad. Tricky. You could take the vertex position and add it to the texcoord, but the vertex positions will differ across the quad and from frame to frame as the quad moves. You might get away with that approach depending on the texture and the quad movement speed, but it'd be a stroke of luck if you did.

 

The only vertex properties set by the engine for entity particles are: vertex position, vertex color, and texcoord. Texcoord is fixed at 0/1 unless you're using an animation strip. Position we've already talked about.

 

That leaves color. Vertex color is set by the engine and it's used to fade out particles over time. Good news: it's constant for all verts of any given quad. Since you're using your own fragment program, you could co-opt vertex color for your scrolling instead, using it in the vertex shader to scroll the texcoords, and ignoring it in the fragment shader. All particle quads of a given age would have the same vertex color, but as long as your particle quads are spawned one at a time, they will all have different ages.

[rich_is_bored]

Yep. I arrived at the same conclusion although my journey was more trial and error. I can confirm that vertex color works and your explanation improves my understanding a great deal.

 

On a side note, the textures loaded in my fragment program are cyan as if the red channel was missing. I've bypassed the issue for now by copying from a known working channel.

 

EDIT: It looks like the red channel is ignored once I call TEX a third time.

Edited February 22, 2016 by rich_is_bored

[SteveL]

EDIT: It looks like the red channel is ignored once I call TEX a third time.

Weird, I've never had that problem. I've no suggestions what could be causing it but if you want a second pair of eyes on it post or PM me your shader assembly code and I'll see whether I can spot anything awry.

 

On the scrolling fix, I had this in mind for your vertex shader:

MAD result.texcoord, vertex.color, 2.4, vertex.texcoord;

where the 2.4 is a constant you'd tweak to set the scrolling speed. You could use a standard vector of values instead of a single number if you needed to scroll in a different direction e.g. { 2.4, -1.5, 0, 0 }. You'd set your particle stage to fade from 1.0 to 0.0 over its entire lifetime. Is that similar to what you did?

 

You could still use vertex color in the fragment shader to fade out the particle, come to think of it, provided that you do want the particle to fade throughout its lifetime.

[rich_is_bored]

This is the code for the particle effect.

 

 

!!ARBvp1.0
OPTION ARB_position_invariant;

MOV    result.texcoord[0], vertex.texcoord[0];
MOV    result.texcoord[1], program.local[0]; # scroll rate expression for x and y
MOV    result.texcoord[2], program.local[1]; # scale
MOV    result.texcoord[3], vertex.color;

END

!!ARBfp1.0
OPTION ARB_precision_hint_fastest;

# Texture 0 is tiling perlin
# Texture 2 is a mask

TEMP IMG, UV, TMP;

ADD UV, fragment.texcoord[0], fragment.texcoord[1];
TEX    IMG, UV, texture[0], 2D;
MOV TMP, IMG;

MUL UV, fragment.texcoord[0], fragment.texcoord[2];
ADD UV, UV, fragment.texcoord[1];
TEX    IMG, UV, texture[0], 2D;
MUL TMP, TMP, IMG;

ADD TMP, TMP, TMP;
TEX IMG, fragment.texcoord[0], texture[1], 2D;
MOV IMG.r, IMG.g;    # <---- FOR SOME REASON THE THIRD TIME I CALL TEX I GET A CYAN IMAGE.
MUL    TMP, TMP, IMG;
MOV TMP.a, TMP.g;

MOV    result.color, TMP;

END