I read your description about the gripnodes. The snapping didn't sound too good... if they snap on when they are close, it might take too much force to unsnap them cleanly... leading to jerky movement, vibrations, etc.
If you look at any real-world tracks or conveyor belts, there is no snapping going on, the track or belt is held over the sprockets or rollers just by the fact they will not drop thru them. I think that a limited-length beam would do just that. Controlling the sideways motion of the track is simply done by triangulating the limited-length beams, like in the example using shocks. I know you'd like to simulate the tracks as they are in the real world, without animations. The problem with the track system I suggested is that there are no visual wheels or rollers, they would have to be added as props and would be just visual candy. But still the track system would behave as if there were wheels, because if you wrap the track around a point with beams holding the track out the same distance from the point, it forms a perfect circle. And it's much lighter computationally than using wheels.
The snapping action could be though used to drive the track... but I think there should be a more clever way to unsnap track from the sprocket than just by pulling force. What if you could specify a sector of the wheel in relation to the body of the vehicle in which the snapping occurs? In a caterpillar style tracks the snapping sector would be about 180 degrees, when a track node moves out of that area, it unsnaps cleanly. If you think real world, that is what happens when the track moves into one direction and a sprocket tooth rotates away from the track. There is a problem though if the track geometry changes a lot with suspension movement... but usually it doesn't change that much, you could just set the snapping sector small enough to still get good transfer of power without jerky movement.
Edit: I just took a look at the shortbound code, it is calculated as a length ratio... it could be easily changed into absolute length instead of ratio... then you just parse the absolute shortbound length instead of length ratio. I would like to test how my tracked vehicle goes with the lengths perfectly set, instead of calculated ratios, which seem to be off a little, because it rolls smoothly when the track is near it's starting position, but starts to vibrate when the track rolls around, and then goes smooth again when near starting position.
Edit: I changed the code so it reads the shock shortbound as a length, not a ratio. Compiled and tested it. For some reason, beams that have a much longer starting length than the shortbound length tend to explode (=bounce back violently and break)... but the beams with a starting length near the shortbound length don't break. Strange... maybe it's caused by the sudden change of the beam's rigidity to the default values, when reaching shortbound length.
Edit: I implemented and tested freely extending beams using rope code. Same problem. When long beams reach the set shortbound value, they break. But only if they start long... if they start short, and are (freely) extended and then returned to the shortbound, they don't break. Can anyone tell me why this happens?
Could someone comment what is happening in this piece of code in Beam::calcForcesEuler? Especially the if-else part.
Edit: I got it working! I'll post a video later to the Applied Development section.
if (beams[i].isrope && dislen<beams[i].L)