Jon3de again made good use of his Patreon special privileges, and asked if I might write something about rest. I'll give it a go!
At it's simplest, rest lets you store the position of geo as an attribute. But lets start from first principles.
Store initial P with a wrangle
Say we had a static mesh, and we wanted to store its position before transforming it. You could use a point wrangle immediately after the loading the mesh, and copy @P to a new attribute:
v@initP = @P;
Or use a rest sop
If you put down a rest sop, you can see it does exactly the same thing, only naming the attrib @rest instead. Simple!
Why rest? Why not! Rest is another one of those Houdini attribute special names like @P, @Cd, @v etc. You could make the case that Houdini treats some attrib names as more special than others. @P is of course the most important, if its not set you have no meaningful position. From there its a sliding scale; @Cd is of course important but not mandatory, same with @N and @v, and and the more esoteric the attribute names get, the more they become useful within very specific circumstances.
@rest is halfway down that spectrum. You won't get renders crashing if you don't have @rest, but there's a reasonable number of sops, vop and dop nodes that expect to find @rest, or if they see it, will behave in different ways.
For a lot of those nodes you'd probably be able to manually wire in @initP if that's what you decided to use that name instead of @rest, but why make work for yourself? Also, other Houdini artists know what rest is and what it's for, if you name your rest attribute @staticpositionreferencepose instead, you'll get dirty looks from those other artists.
Download scene: File:rest_to_stick_textures.hipnc
Noise is usually driven by @P, but if you deform your geometry, it'll swim through the noise. Drive it by @rest instead, and it'll stick.
Can measure the distance between @P and rest with a wrangle like
@d = distance(@P, @rest);
And use that to colour the surface, or enable a displacement map to drive wrinkles, or push points along their normal to do hacky squash and stretch.
You might have to do a bunch of operations to surfaces, then need to get them back to their original positions. Can do that with
@P = @rest;
The ripple solver users @rest to drive the initial state (even an animated initial state). Watch the fantastic Entagma video for details:
When to NOT use rest
(or an alternate title...)
Understanding time dependency
In the network editor menus choose View -> Show if nodes are time dependent. This will put a little green clock next to some nodes, to tell you that they're updating every frame. Usually this isn't an issue, but as your networks get more complex, having lots of nodes process lots of geo on every frame can start to hurt performance.
At this point it can be worth taking a step back and analyzing your workflow. If you have animated noise as one of your first nodes, then 20 nodes after it, then all those nodes have to process every frame. Could you move the noise to be the last node in your graph, so you have 20 nodes that just cook once, and then a single node at the end that updates every frame?
A related technique is dealing with animated geometry, often generated by another department. Rather than run a complex sop network every frame, a timeshift node will be used to freeze the animation on frame 1, stopping time dependency. Do all your setup, texturing, whatever else you need to do, then as a last step use something like a point deform or attrib lookup, to copy the animation from the original input to your modified geometry. This can often have huge speed gains.
Why mention this on a rest attribute tutorial? Requiring rest is often a warning sign that you're mixing time dependent and non-time-dependent ideas. Not to say rest is bad, but often rest is used to get around animating geometry issues, which means its worth investigating if other methods might be faster.