that’s right, the left right should have been left if I had typed it right, which I did, but it was wrong.
Fixed now, thanks.
…Aaaaaaand now there’s coffee on my keyboard. And in my nose.
if one goes here (the Blender Road Map I believe it’s called)
and check under Blender 3.0… there is some mention of changing Data structures… and the fact the the Blender Data structure is some 20 years on now…
considering that we are in Blender 2.7… that might not to far off… well at least a couple of years I suppose but still not that far away I would think…
DruBan: Here’s a simple mechanism that would require bidirectional constraints. Load the file and press play. The cube will move to the left and rotate gearA, and then move to the right and rotate gearC. Now go back to the beginning but enable the last constraint on gearC – the one that makes it copy the rotation of gearB. Now when you hit play, gearC ignores the collision, because its only available reaction (rotating along the Z axis) is tied up by a constraint.
Obviously the simplest thing to do in this case is make the entire mechanism a rigid body simulation, but when you do that you add a whole lot of complexity where none is required. You already know exactly how the gears react to each other – it’s simple enough to define their reactions (to each other) with constraints/drivers, there’s no need to simulate it. Now suppose the 3 gears were, instead, a complex gear train. It would probably be impossible (or at least extremely impractical) to simulate a complex gear train using rigid body physics, and there’s no need to – the gear train’s behavior can be defined using constraints and drivers.
The way to script this using a switch would be to figure out when an object is about to react to a collision, and instantly switch that object to being the driver. But with a gear train you’d have to enable/disable a whole lot of constraints. There are also scenarios where there are more than 2 potential driving elements, and in that case you’d need multiple switches and a ridiculous number of constraint sets.
You guys are probably right that this would require an overhaul of the constraint system, and it’s a nontrivial change. In the meantime I’ll try to figure out workarounds.
Attachments
bidirectional_example5.blend (584 KB)
As I said you can impose conditions on yourself until you lock yourself into a corner. The stopper here is that you want some of your animation to be under the control of the rigid body system but want it to freely interact with the animation system.
As soon as you remove the rigid body requirement your desired animation becomes elementary, and the rigid body collision can easily be simulated with drivers.
Yu obviously know a lot about gears! But I can’t imagine a system in which two forces are simultaneously driving the same train… wouldn’t this just strip the gears?
Good luck with your project and post back if you figure something out!
very interesting problem… thanks for the blend file to help discribe what your talking about…
I at first thought that perhaps just using some parenting and switching back and forth the influence (either via keyframes or using drivers would do it) but no luck… when ever the influence is switched out the Gear returns to it’s origonal position killing the use of that idea…
The rigid body panel has an “animated” checkbox to allow just that, it was designed with that in mind. Think of a moving rigged vehicle – it has constrained parts, animated parts, and often some rigid body simulation occurring at the same time.
There are all sorts of mechanisms that allow for more than one point of entry for kinetic energy: planetary gears and differentials, for example. But the much simpler example is just a system where the points of entry and the points of exit are not predetermined.
Switching the influence almost always makes an object return to its rest position (or some other position that’s different than the one it’s in at the time of the switch).
I tried “fooling” the system using patenting in all sorts of ways, but I always run into the original problem – once a property is the driver, it may no longer act as a driven property. That makes sense – when you parent/child objects you make one set of properties (the child’s) reliant on another’s (the parent’s).
Yeah, to prevent skipping you would need an intermediate target that snaps to one of the controllers or the other. It gets pretty complicated pretty fast and it’s hard to avoid creating looping dependencies.
There’s question that I should have asked much earlier, but I was focusing on doing much of this with constraints rather than drivers to reduce complexity… The question is: can I enable/disable a driver in the same way that I can enable/disable a constraint? I don’t mean disable its influence, I can do that by adding a condition in the scripted expression (using if/else or just a multiplier), I mean either remove or disable it so that the property can now be driven by something else (potentially so I can enable a different driver)?
Man I wish it was so… but AFAIK only one driver per object… however… if you parent that object to another (sau am empty) then the parent can have another driver… and you can parent that one to another parent and thus have another driver… etc… etc… etc…
however the problem still remains… IMHO… if you turn off the driver that has effected the Rotation… then the Rotation it has caused is removed… what needs to happen is a transfer of the Rotation information to next driver at the time of the switch…
This video tutorial might have some ideas about doing this transfer or Locations and Rotations however this is done with Keyframes and switches so it might not be what your looking for…
… check around 15:00 to see the use of the constraints… (In this case Child of… ) note the use of the “Clear Inverse and Set Inverse options”… these options are only found in this constraint…
even still the video method used here is a bit clumsy at best… I’m having to search through some old notes as to how I did this some time ago… when I find them I will post…
Not quite so. One driver per property, not per object. So this is where custom properties come into play; you can abstract the driver away from the property you want to control by having the driver control a custom property, then create a switch which changes which custom property is altering the ultimate target property.
Hey guys,
NorvMan pointed me to this thread a while ago, but I’ve been super busy. Sorry!
Fundamentally, Blender’s constraint system is not a simulation system. It’s more like a simple language for programming behaviors. Each constraint is like a little program, and they have to be executed in a particular order. This makes it extremely flexible in some ways, but very limited in others.
To put it another way: the constraint system by nature is not bidirectional, and that stems from what it was built for: hand-crafted animation. If you did have two gears that each affected each other, imagine what would happen if you tried to set animation key frames on both of them. One of them would have to “win” over the other, and there would be no way for Blender to know which behavior the user wanted. And even without animation, Blender is supposed to obey the positions that the user specifies for each object, and thus would still need to know which gear should “win”.
Blender’s viewport isn’t meant as a means for interacting with an artificial reality, or for testing how a product would actually function. It’s meant as an artist tool for creating images, animations, assets for games, etc. And its feature set reflects that. Even Blender’s simulation systems are geared towards creating pre-baked, controllable simulations–it’s almost an accident that you can interact with them in realtime. The end goal is to create something that is controlled at every frame by the user, not to create a world to interact with.
It seems to me that what you’re looking for is more along the lines of a game engine. And that makes me wonder if maybe Blender’s game engine can help you out here…? I’ve hardly touched it myself, but perhaps that would get you the kind of interactivity you’re looking for, with more relationship-oriented constraints.
You could also look into Blender’s Bullet integration (though I’m guessing that Bullet’s constraints don’t handle this…?). You’ll have to have to be “playing” the animation to interact with it, but it’s closer to what you’re looking for, I think. Perhaps adding additional bullet constraints to handle cases like this would be a good way to address this.
Anyway… sorry I couldn’t be of more help.
@ Cessen Thanks guy for the look see and the input!
Not quite so. One driver per property, not per object. So this is where custom properties come into play; you can abstract the driver away from the property you want to control by having the driver control a custom property, then create a switch which changes which custom property is altering the ultimate target property.
Okay I think I’m getting what your saying… that is … I can have a driver on every keyframe able property… Translation X, Y, and Z… and Rotation X, Y, Z and W (I suppose) … so your correct…
and a custom property I suppose by using the “Custom Properties” menu that is in almost all the Attribute menus and then use the “Copy data path” selection by using a Right Click menu on any of the key frame buttons…
but when you say…
abstract the driver away from the property
I’m not sure I’m following you 100% on what your doing there…
I understand that this would require a reworking of the constraint system, but it doesn’t have to make the jump from what it is now to a complete simulation mechanism all in one go.
The simplest way to deal with the scenario you’re describing is the same way you would deal with an animation key when it comes up against a constraint – a hierarchical system. In the case of an animation contradicting a constraint, the constraint always “wins” because it’s higher up in the program’s condition loop. The same goes for when a rigid body simulation “collides” with a constraint – the constraint wins. The rigid body system has a built-in way of interacting with an animated object – there’a an “animated” checkbox which allows a rigid body object to be controlled by the animation system.
So really a hierarchy already exists, it just needs to be extended. In the case of drivers, you could give them an index value – the higher numbered driver will always take precedence over the lower numbered ones. By doing this you remove ambiguity. You could even drive the index values themselves and the system would keep working. If two drivers are assigned the same index value, the result would be the same as an invalid driver expression – they both become static (and you’d get an error message informing you of the conflict).
With copy constraints you can define the behavior to be whatever you decide makes sense. Maybe the constraint only comes into effect if nothing else it attempting to control the property (an animation, a driver, the rigid body system, another constraint, etc.).
Whether or not developers should be spending time on this is another matter entirely. I understand completely that this isn’t high up on the list of priorities with a project like this. But I do think that you wouldn’t have to do it all in one go – you could take small steps that would still be useful, even if they’re primitive at first.
Without actually targeting this particular problem I think developers would do well (and I think they might be working on it right now) to expose the hierarchy of dependence in the animation system and actually make it user editable, as in the user could reorder which items get evaluated first or take precedence.
A node type editor for precedence with IK, actions, constraints and physics nodes would be the best where you could hook this constraint node up to feed into that rigid body node and only then feed into that other constraint node… eventually producing a single ‘position’ output value for the object.
Ok, super late to the party…
Sorry about that…
I haven’t downloaded the file to look at it, but as I understand it, the basics are you are trying to control 1 gear by 2 or more other gears?
This can be done via python, I have a working example of 2 controls for 1 gear. To be honest, I haven’t tried keyframing the bones, but I think it would work.
The more I think about it, if it’s keframed animation, I would go a different route with python… maybe…
Anyhow, see the attached file. There will be 2 control bones, above and below the gears they control. There’s some lag in the rotation, but that can be fixed.
is this what you are looking for?
Randy
Attachments
gears_example.blend (566 KB)
I need 2 objects to effect each other. Even if it’s just 2 gears – turning gear A will turn gear B, and the other way around. It’s kind of difficult to give simple examples, the simplest one I could think of is the file I previously attached (with the 3 gears).
The actual mechanisms I’m trying to simulate “take turns” being the controller/controlled. In real life, think of a flywheel which is needed to store energy – first something spins it up to accumulate angular velocity, and then the flywheel’s angular momentum can be used to drive something else. So the flywheel starts by being the “driven” object, and ends up as the “driving” object.
Within blender the flywheel example would be much more complicated, of course – I’m giving this example because in real life it’s the simplest I can think of.
Many clockwork mechanisms require this (I mean actual mechanisms of clocks, not “clockwork” in the broad sense). In the simulations I’m working on, I want to leave as little as possible to the rigid body simulation to work out – anything I can do with drivers and constraints is preferable (in fact, it’s required, since the rigid body simulator gets unstable as you increase complexity).
The connection between the bones and gears stops after a few rotations, and I have to reload the file to get it working again. The driver which is using “simple_function(var, var_1)” gives an “invalid python expression” error.
This function uses “bpy.context.active_bone.name” to determine which bone is active, so like in the IK switch examples, the problem is that I don’t know in advance which object will be doing the driving.
In the end it appears you’re right and specific python scripting will be needed to solve this. This is kind of unfortunate because it makes the mechanism less portable/modular than one that just uses constraints and drivers.
I’m attaching something that’s tangentially related, in which I’m “leaving the timeline out” of the mechanism. I’m adding to the “bpy.app.handlers.frame_change_pre” function list so that any keyframe change will update the mechanism, and I can use the timeline for other things while this happens. I can use other things to trigger the updates, but using “frame_change_pre” means it will only calculate the new positions once every frame.
About the attachment: Press play to start the mechanism. Move the “Speed” slider right and left to control the speed of the rotation. Move the “Clutch Switch” to make the rotation effect the inner shaft, the outer shaft, or both.
Attachments
frame_tick.blend (723 KB)