Tough stuff for me, Drivers. For years I’ve wished a space ship I make could just fire retro boosters or those little steering jets all by itself for appearances.
What Driver instruction would I pick or setup to affect the visibility of a “firing retro booster” when the main ship body turned in some direction? For example’s sake, let’s say a booster on the FRONT LEFT that fires when the main body of the ship pivots RIGHT or clockwise…
I’ve done a few amazing Driver things here and there but never got the hang of expressions or the var options.
This is a super simple setup, probably too simple, but it should get your started. “Rocket” is parented to an Empty. I’m using the Empty’s X rotation in this case to drive two drivers on two mix nodes - the driver gives “rotation_euler” as a variable, so one flame has “rotation_euler > 0” as the mix factor, and the other has “rotation_euler < 0” as the mix factor. Like this:
Is there a tweak in this setup where the Emission will only be visible during Empty’s rotation. No rotation = no glow and glow only in one of the empty’s rotational directions.
I really appreciate your lightning fast reply btw!
Ooh, that’s a tricky one… now you’re talking about velocity, which isn’t really something Blender keeps track of natively. Luckily, you can do this with Python scripting… I’m not 100% sure of the exact code, but I’d go through this process:
On depsgraph_update (the handler Blender Python uses when data is changed), check the current rotation against the last saved rotation. If it’s the same, glow is Off, if it’s different, glow is On and the saved rotation is updated to be the current rotation.
I’m just not sure if that’ll work with live transforms- @testure / @const , does depsgraph_update get fired during live transforms? I’m pretty sure it doesn’t. Is there a better way to approach this?
Any chance that a difference between two geometries (rather than the velocity of just one) would have the effect? I noted that there is some part of Drivers that look like I could use SHIP and the EMPTY; if the EMPTY rotated first thru animation and then the SHIP followed thru animation some frames later, that driver would do something.
Even that would be a knockout solution to this age old desire.
So, just chiming in to add that if all goes well, in 3.6 Blender will get simulation nodes -then, computing and passing velocity through an attribute to the shader system is going to become completely straightforward. You can already do it in the experimental branch ! (I mean you probably can, I haven’t tried that specifically) But in the meantime, perhaps this is something that could be animated. If there aren’t too many shots… I mean, sometimes you don’t have to automate stuff even if it’s tempting to do so.
Duplicate the object whose rotation you want to measure. Disable rendering on it. Duplicate the action, then offset it -1 frame (ie, move -1 in X axis in the timeline.) Measure rotational difference between the original and the duplicate. If it’s >0, then you rotated this frame. If it’s not, then you didn’t.
If you want this to remain live with changes you make to the animation, you can use the NLA to assign strips instead of duplicating the action-- the strip for the duplicate references the same action, it’s just offset in time.
live transforms yes, animation- no. not sure where drivers fit into that architecturally. If drivers change the dependency graph it will update. Easy way to find out, try this script and adjust your drivers- if nothing prints out then depsgraph won’t work for this.
import bpy
last_pos = None
def depsgraph_update(_):
if bpy.context.active_object is None:
return
global last_pos
current_pos = bpy.context.active_object.location.copy()
delta = 0
if last_pos is not None:
delta = (current_pos - last_pos).length
if delta > 0:
print(f"Movement delta: {round(delta, 2)}")
last_pos = current_pos
bpy.app.handlers.depsgraph_update_post.append(depsgraph_update)
I enjoy the -1 offset of the duplicate because I can animate first. The NLA is outside of my experience. Am I right in noting the difference is only calculated as a positive value? var is 5.4 at times and never -5.4?
Can I add a rotational qualifier or check or something to activate the effect on clockwise differences for one side and counter-clockwise difference on the other side?
I say in the kindest way, “I know.” Honestly I was a Blender Purist for a decade. It made me HAPPY - maybe a 3D purist even. Animation, procedural stuff, no megascan things, no photo textures, just me and my mouse kicking ass.
No ass was ever kicked. I got a lovely but microscopic YT channel with a tiny loyal following but never finished anything before the next idea came. (That’s my own problem to bear of course, not Blender’s) but now, I’m a Button Man.
Buttons on Gaea, Arbaro, City Generators, Blender Addons, Planet Generators, spaceships, quick fur, and OMG: GScatter… And Textures?! I’m still rather chasing the procedural stuff because it’s like solving a Sunday Crossword: fun; but now I have a modest library of photo textures. Everyday I give myself a daily speed challenge to find shortcuts. Most days I fail to accomplish even the most basic challenge because I love the process of animating and 3D.
But the one thing that always made me fall on the ground and whimper like a ninny was the reaper of having animate retro thrusters. I always wanted a button for those. I’ve only got a couple victories in Blender to show after a decade and now, although I agree with you that 3D purity is top-dog bragging rights, maybe I’ll be the Button Man to make that retro thruster “button” that others can use to accomplish their kick ass ideas even though I couldn’t. That’d make me happy too.
Yeah, it’s the difference between the two rotations. It’s like distance, always positive. (Maybe it even is quaternion distance, I dunno. Seems like that’s how you’d measure it.)
Clockwise vs. counterclockwise depends on your perspective: the earth rotates one direction when looked at from the north pole, the other direction from the south pole, and looking at the equator, its direction is undefined. So to talk about direction of rotation requires an arbitrary vector. I don’t know your specific situation, but I doubt that the arbitrary vector for you should be a world-space vector; it should probably be measured relative to something else, right, because there’s no such thing as upside-down in space. And certain kinds of rotational differences wouldn’t show in that analysis of direction-- there’s a part of the rotation that’s undefined.
Once you have an arbitrary vector, the mathy way to get the direction of rotation of two vectors is to take the cross product of them, in a fixed order, which gets you a vector orthogonal to both, and then take the dot product of your cross with your arbitrary vector. Is it >0? Then the two point in the same direction, and your rotation goes one way. Is it negative? Then the two point in opposite directions, and your rotation goes the other way.
This should be scriptable, but I can’t tell you how. I would do it with constraints instead of doing it the mathy way: I would parent a bone to one object and then locked track (lock X, track Y) a marker parented to the other object. Then I can read the X rotation of the bone as an XYZ Euler. Is it positive? Then our rotation goes one way. Is it negative? Then our rotation goes the other way. But notice again that there’s a component here that’s undefined.
Distance then! Borrowing your idea of copying an animated object and using the dupe to Drive action, I’ve placed an object that has the animation keys copied and offset - it’s placement is between driven objects.
With it’s Origin far away, that non-renderable object is swinging around a bit traveling between the Driven objects getting nearer and farther; the faster the movement, the farther it gets “faking” velocity and if Emission Strength is driven, the effect is brighter. Because the Driver is BETWEEN driven objects, it has a fake directional component assuming it doesn’t pass to the outside of the objects it drives.
This has actually worked out to be really interesting - not deeply accurate for retro thrusters but neat enough to pass the suspend-disbelief test because it’s fun.
Thanks to everyone who pitched in and for jogging my imagination on this! I’ve always loved the BA community.
