Thaumaturge said:
reRenderedSourceImagePixel = smoothstep(min(0.9989, 0.999 * dt), 0.999, inputPixel);

hmmm… is that basically an exponential moving average with constant alpha?

Not sure (also about the correct term), but if so, you can get this much simpler, and probably more robust as well:

const float alpha = 0.02f;
newValue = previousValue * (1-alpha) + curentValue * alpha;

If values fluctuate over time, you get some stable average (hopefully). I guess that's what you have in mind, but then your code would be overcomplicated.

Calin said:
sidenote: I don`t think that`s too much relevant if it does not relate to the reason/problem why you`ve created this post (like it`s not related to what you`re currently trying to achieve ). You should focus on explaining the problem you`re trying to solve. If it bears relevance to the issue for which you`re seeking help than you should copy past that code in this thread.

If it's true that mentioning the shader wasn't relevant, then your comment isn't either ;P

I think i know better now how they did the example.

Probably the brush creates particles, and new particles only appear at a min distance from existing particles, giving us a Poisson Disk distribution of particles.

Then they use Delaunay triangulation to create a mesh, using the particles as vertices. It's pretty low poly.
(The shown algorithm is slow, but adding few vertices to an existing mesh is not, and neither is making an already existing triangle mesh Delauney using a queue of edge flips)

For some fake simulation, they nudge the vertices, so it looks fluidy and dynamic.
And they were a bit sloppy, explaining the artifacts.

Because the surface is flat, uv parameterization and texturing is as easy as with using terrain height maps.

I bet that's what they did. : )

If it's true that mentioning the shader wasn't relevant, then your comment isn't either ;P

If you really mean it why are you not using a serious tone? (this could end up as a flame war no room for jokes)

[later edit]

I`m not saying what he did is a serious mistake, it`s not even a misdemeanor for this reason I have marked my observation accordingly (as a side note)

JoeJ said:
Not sure (also about the correct term), but if so, you can get this much simpler, and probably more robust as well:

Well, I do want a time component, in order to account for variations in frame-rate. Still, it might be interested to try both, and see which works the better.

JoeJ said:
I guess that's what you have in mind, but then your code would be overcomplicated.

As I see it in my head, at least, it seems like a fairly minimally complicated approach. The line that I gave should be the only operation performed on the input texture in order to produce the next stage of said texture (aside of course from actually rendering it). And drawing a fuzzy circle to a texture is fairly straightforward, I do think.