I've got the code that was using in the project I'm following on from as a guide, as well as the dissertation he wrote with some basic details on how the TLM stuff works, so I'm not working completely blind.
Having had a look at the code it looks like I'll be needing to perform 3 passes.
The first works out how much energy a given point should have in it, this is the sum of energy being reflected from surounding points (calculated in pass 2) plus any driving force put into the simulation (the orignal code has a sin wave being pumped into a spot). The driving force was orignally an extra value set after the 2nd pass had been done, however as we can't really poke the values from the 2nd pass (they will be stored in a texture and the calculation requires a readback) combining it into the first pass by using a texture seemed like the best idea.
The second pass is where we work out the values come in from the surounding nodes. These are then summed and biased to give the final vertex hight in the third pass.
A major consideration for this is texture reads and render targets.
Each node has four pieces of data associated with it, each a floating point value, so we are already restricted to FP texture formats, the big question is how many channels and thus how many textures are required.
It's natual to think that, as we have 4 values a 4 component texture would be a good way to go. And for the first pass this would be true as we could grab all our data in one texture read (well, 2 texture reads as we'll need driving data as well, but that was always going to be a single channel fp texture).
However, trying to use one for the 2nd pass source data would be wasteful as we are only ever intrested in one float value from 4; yep we've just used 4x the bandwidth we needed. So, the 2nd passes data would probably benifit from being single channel data.
The third pass requires the 4 components in order to sum them together to produce the vertex positional data.
This means, the first pass needs to output to 4 single channel fp render targets, and the 2nd pass requires as single 4 channel fp render target.
I'm still considering how to handle the 'normal' problem. As it's a varying surface the normals need to be recalculated each frame. If we want nice smooth normals for lighting we are going to have to perform alot of samples and maths in the 3rd pass in order to produce the correct per-vertex normals. This might well be best handled in a 4th pass to generate the normal information based on the calculated hights in the previous pass.
I'll have to look more into that as I hadn't given it a great deal of thought at this point.
Anyways, current state of play is that, in theory at least, I know how todo this... now it's just a matter of writing it all [grin]
