Using properties does sound like the right track for creating the kind of behavior which I picture being described.
I think I could come up with some planetary gear thing just using properties controlling their rotation on each. By using drivers that read from the property variables on the moving parts of the model, it should be fairly simple to get the correct behavior by animating either or both property values at the same time.*
Since the variable inputs are independent of the driven animation, it should work simple enough without any cyclic dependency problems.
Unless somebody beats me to it, I probably wont have this on pastebin right away. But it might be a quickie weekend project.
*(I’m still too much a noob at scripting though. Any more than two or three properties as inputs for a basic gear chain, and my way of doing it would look dumb. Just don’t know enough about Python, but just what bit is good for scripted expressions in the drivers themselves. At some point it would be necessary to call functions and stuff or have an automated script that generates another script controlling drivers. If you’re clever enough with that, it should be possible that a property on any gear could control all the other gears. Just a matter of passing a variable into the ratio functions that control the driver on each gear. At that point, may as well make it an add-on.)
Hmmm… I can not get my file to give me the ‘invalid python expression’ error… To be honest, I hadn’t tested it very well, but it doesn’t matter. It was my second attempt at solving your problem.
I read your first posts about this, and just passed it over, not something I was interested in looking into. Then @norvman asked me to take a look at this. I read every post in this thread 3 times, but I admit to skimming thru the ‘philosophical’, ‘theory’, and ‘in a Utopian world’ parts of the discussion. I like to solve problems, not debate the nature of the world. And as such, my example file was, as I said, my 2nd attempt at solving the problem. Using pydrivers then got me to thinking of just controlling everything via python. Then I got to thinking, how are you controlling this animation? You are not keyframing it, or you wouldn’t be posting such a problem, you’d just keyframe it. So how are you controlling this? User input or external input?
Since I was unsure of the input, this is why I wrote this:
The more I think about it, if it’s keframed animation, I would go a different route with python… maybe…
which was a typo… it should have read, ‘The more I think about it, if it’s not keyframed animation, …’ and my thoughts on if it’s not keyframed is to use a python frame change event, like you have done. Yea, it’s more tedious this way, but looks like you have a handle on blender python. I’m impressed with the file you posted! You’re more skilled than I am in this area,
I’m trying to make it modular so I can chain elements together. The driving force may be keyframed, input from a driver, or input from a rigid body simulation.
The problem with trying to keep the examples simple is that I can’t really clarify what the overall goal is, so I’ll expand a bit:
I’m trying to create modules that I can then combine to create a larger mechanism. What’s being passed between modules is, usually, rotation: one axle connects to another. The simplest modules are 1-function gear trains: There’s one input and one output – I hook up the input to a “power source” (something that’s rotating) and connect the output to some other module. Both of these things are done using either constraints or simple drivers.
A very complex example would be a vehicle where an engine connects to a transmission, which is connected to a differential, which is connected to the wheels. Of course, this is enormously complicated to pull off, but it’s a good example of a series of separate mechanisms that are hooked up in series.
Here’s a much simpler example: a motor which is connected to one wheel (maybe it’s a toy tricycle). The scenario which immediately comes to mind is the motor driving the wheel, but the reverse is also possible: With the motor turned off, place the vehicle on a slope, and it will roll down it. Since the wheel is still connected to the motor, it’s now the wheel that’s the driving element, and the motor the driven one. This is why I keep emphasizing bidirectionality – the driving and driven elements can change places.
As has been pointed out, this isn’t what the constraint system in blender is designed to do. Also, drivers, though they can be scripted to do very diverse things, are always one way. Once you drive a property, its value will always be defined by that driver – you can’t turn a driver on and off. What you can do is turn a constraint on and off, meaning that you can create two copy constraints and switch between them, but then you introduce the “skipping” problem that all copy constraints have (they can’t extrapolate forever, unlike drivers).
What’s left is to control everything using python, which work well, but it’s not modular: I can’t just append a module into a system and hook it up, I have to specifically add the code and modify it every time.
I know I’m trying to do something which most blender users would never need or want to do. The reason it’s frustrating is that so many of the tools to get there are already in blender: As long as it’s a one-way mechanism, it’s possible to pull this off using drivers and constraints. The “only” problem is the one-way part.