Alright, so, I have to come up with a rigging pipeline for tank treads. This will be a bit tricky and interesting, but good. I've been doing some research on different forums, which all give basically the same solution: Attaching Geo to a motion path, and using time or some attribute to drive the uValue of the motionPath node. This seems fine and good, and can yield the necessary results, but there's an issue. You can't make the treads slow down to a complete stop.
Since the controls effect the uValue, by slowing speed on many of the controls, the uValue declines as well, so the treads reverse course along the length of the path. So, I'm trying to create a system of some kind that will allow the user to drive the uValue in some intelligent way. So that when keyframed, you can bring the treads to a complete stop, smoothly. I'll update with progress as I flesh this one out. I'm thinking of using some kind of SDK, but we'll see. I've already tried messing with blend shapes, but he linearity of them kills that hope. Setup would be heavy and complex anyway. So, here we go...
Alright, I've managed to figure out the control aspect for this. Its pretty simple in hindsight. After I spoke with a programmer here at work, and explained the functionality I needed, he asked about using a module.
In the case of MEL Scripting, it was the 'fmod' command. This will take two values, divide them, and give you the remainder in a float (decimal point) value. So, we can take the input of the control, use its value as the first input for the fmod function, and our upper limit as the second term. This will always keep the value below the upper limit. In this case the upper uValue, which was 0.394 (since my working units was in cm. If you work in inches, the uValue would be 1). Then, I had to do a bit of magic to tweak the control istelf, and make it work in reverse for negative numbers.
So, the final functionality is that if you raise the value on the control to positive integers, the object moves around the curve in a clockwise manner. If you decrease the value, or go into negative values, it runs counter-clockwise. Just the functionality I needed.
Once I pump out the remainder of the script, namely duplicating geo, attaching it to the path, and offsetting the uValues, I'll post what I can to explain the process as well as the script. So stay tuned...
Things have really picked up at work here lately. So, I've been poking around at this when I've had free time. Its nearly done. I have the script running pretty smoothly with lots of options for the users. All I really have yet to add, is the creation of the control expression... the one that will actually drive the objects around the curve. Everything else is basically made, and just needing to be assembled.
As I kept playing with this, found I kept needing to add features. So now, you can specify which local direction of the tread object faces down the curve, whether the geometry is instanced or copied, if you want the geometry controlled by joints (for export into game engines), and you can specify how many treads you want along the curve, or have it detect the proper amount automatically based on the length of the object and the length of the curve. Its pretty neat.
I've also kept a lot of descriptive comments in the script itself so future users can easily pick through and decipher what's going on. There are also 'About' and 'Instructions' menus in the UI. The 'About' menu will describe how the script works in a general way, with notes on how to potentially change it if desired. The 'Instructions' menu tells you... well, how to run the script. I'm hoping to have this done in a couple weeks, work permitting. I'll keep you up to date with what's going on.
So, after my last post, things at work did pick up and have been running pretty fast ever since. I have been able to 'finish' the script. Meaning, it can run fine in a scene... twice, then it breaks, and some of the code it actually generates for the expressions to control the treads is funky. It's leaving out = signs, and variable declarations, but they still work in the scene. I'm still not sure why this is happening. So, aside from some trouble shooting on those accounts, it seems to be working fine.
Now that all the logic and math is figured out, I may rewrite it more concisely and try to eliminate those errors that are happening. But again, in due time, with ample time.
If there are any questions, ask away and I can try to help.