Tag Info

0

of course not, because you just added a "track to" contraints to your cube, which tracks to your empty. So the cube rotates in that way, that it tracks to the empty. And there is no copy rotation constraint at all...

2

The other answers are good solutions, but nobody (so far) has answered your explicit question, which is why this happens. Here's what Blender does when it figures out a copy rotation constraint: It reads the f-curves. It runs any f-curve modifiers. It applies any drivers to these values. It turns these values into a 4x4 transform matrix. In order to ...

3

As the rotations are calculated in radians (degrees are shown only as helper), the correct driver formula to get 0.0 - 1.0 range from 0 to 90 degrees is: 2*var/pi. Check theese answers for more infos. About driver rotation Degree and Radian

1

I might try using the object as a texture coordinates and lining that up with the material alpha value, and then maybe throw in some back face culling so it is not visible from the inside.

0

The trick is to select the curve then in Object data properties change the Twist Method from Minimal to Z-Up (screenshot). Thanks to Christopher Bennet for posting the response here.

3

You can parent the leg to the body so it moves automatically when the body moves, then with the leg selected, in the Numbers Panel right-click on the X rotation, Copy as New Driver, select the body, right-click on the Z location, Paste Driver. The body will now drop down to Z = 0, because that's the current rotation of the leg (at least in my case). Now you ...

0

As mentioned by Denis, a child-of constraint would be easier. But it's still possible to answer your explicit question, "How can I set the empty rotation in such a way that the hand will have the correct resting rotation when I add the copy transform to the hand ik?" Get the hand posed how you'd like, without the copy transforms constraint. Give ...

1

The mysterious invisible force is 12 copies of your ragdoll. They are not in your scene but in your blend file. It looks like these lost objects are still used for collision detection. To get rid of the copies, select Blender File as Display Mode for the outliner. Look for Objects and expand it. If you select everything in the viewport, then you can easily ...

0

Path-following Camera - Use a cube, either visible or invisible as the path object. Add a line between two diagonally opposed corner vertices and subdivide that. Set the cube's Origin point to that. (with SH-S) (Shouldn't be necessary, but... ) Parent the camera to that vertice ONLY. Select the cube, then the camera, go into Edit mode and select the ...

0

FWIW, the simple answer for my question is that the constraints between objects are fine as they are. There is some physics force or bug (yet to be determined) that causes this to happen. Why? Because if I move the whole ragdoll to somewhere else, this doesn't happen. Added a followup question trying to identify what's that mysterious force, but the ragdoll &...

1

Something with an off-center center of mass doesn't fall any differently in real life (disregarding air resistance, which is not simulated by Blender's RB physics). It won't rotate as it falls unless it has some rotational inertia from some other cause; all parts of the object will experience the same acceleration due to gravity. Rigid body physics places ...

0

Ok, maybe this is not the best answer but it worked: I duplicated the skeleton (just the deform bones from the original skeleton, NOT the rigify stuff). Then I added copy-transform constraints to all these new bones, mapping them back to the original. Now on the new skeleton I can bake and everything works. I suspect the issue is that "clear constraints&...

0

This looks like a pretty simple setup. In this case, the division into Source (control)-> MCH (mechanism) ->TGT (deform) is not necessary. It looks more like a lesson about how rigs can be divided into multiple layers like this, which is often necessary, even if it's not necessary here.

-1

My theory to answer the question - which problem MCH solve in this situation.

2

As the cube's Z rotation is supposed to be influenced by the empty's Y location, you need to set the Z Source Axis to Y:

2

Create an empty, set it child of the moving object, set the camera track to constraint to the empty, then add some noise to the Z loc of the empty. To do this set a starting loc keyframe, then in the graph editor select the Z loc channel of the empty and add a graph noise modifier.

3

Arc distance. Before it rolls off the edge, can use the arc distance formula $$d = r \theta$$ Where d is the distance travelled, r the radius of the cylinder (half y (or x) dimension) and theta the total angle in radians. An empty is added the scene at location of cylinder at frame 1. Or as demonstrated in callback "hack" (one of my favourites) ...

3

The .to_euler() function of transformation matrices allows passing an euler_compat argument that acts as a reference rotation from which new Euler values are generated. Thus, as long as the object in question doesn't rotate more than 180° in any one step, it should be possible to always get the valid rotation by passing the known valid Euler rotation from ...

0

You've given a Follow Path constraint to your object as if it would act as a third modifier but it won't, it will just move the object along the path and the object will be affected by the modifiers independently. So I guess you have 2 possibilities: Either remove the modifiers, convert your star to mesh, give it modifiers again, and keep the constraint so ...

2

The UI for the constraint has changed, but the features are still there. Each axis has an alterable “source” option, which is equivalent to “mapping.”

4

Matrices store rotations as quaternions (to_euler is only a method converting them), so if you get your data from a matrix, you know you lost information about the number of rotations. I don't think there's a way to read the euler values. However, because 360° range is quite big, as long as your object is rotating slower than 180° per frame (or per ...

0

First, I changed your coat tail bones from Quaternion rotation to Euler XYZ because you won't ever need quaternions if you don't also have 3-axis rotations (and you don't have them because the local Y of your coat tail bones is not of relevance to any motions). This change wasn't essential to the solution which appears below, however, so while my version of ...

0

The hand bone you're trying to constraint is a connected child of another bone, so it isn't free to move. Try to do the opposite, and make the main gun bone a constrained child of an appropriate hand bone. After settign up the constraint, press its "Set inverse" button.

Top 50 recent answers are included