Don't make child object of new connector movable if its transform is currently affected by powered Keyframe
A decision on whether or not to make a child object of a new connector movable can go two ways: "make movable" or "don't make movable". Both have the potential to be wrong. Dreams always chooses "make movable", and in the case where the child object's transform isn't affected by any powered Keyframes, that "make movable" is more likely to be right than wrong. But in the case where the child object's transform is currently affected by powered Keyframes, that "make movable" is at best premature. The following steps illustrate why:
- Start a new scene/element.
- Delete the floor block.
- Start a new sculpt.
- Stamp a 0.5m x 0.5m x 0.5m cube centred at [-19.5, 0, 0]. [right cube]
- Exit sculpt mode.
- Create a clone of the cube centred at [-20.5, 0, 0]. [left cube]
- Group the two cubes together.
- Create and start recording a Keyframe.
- Animate the group 20m in the positive x direction - the midpoint of the cubes should now be at the origin.
- Stop recording.
- Open the Keyframe's tweak menu.
- Turn on the Keyframe's power.
- Close the Keyframe's tweak menu.
- Scope into the group.
- Create a bolt from the right cube (parent) to the left cube (child).
- Scope out of the group.
- Position the camera on the z axis looking at the origin in the negative z direction with the cubes filling most of the view.
- Write the current camera position to the Default camera bookmark.
- Save the creation.
- Exit the creation.
- Edit the creation.
Huh? Where did the left cube go? Look left. There it is at [-20.5, 0, 0].
So what happened? Well, it all started to go wrong when Dreams decided to make the left cube movable in step 15. That decision combined badly with the rule that changes made by powered Keyframes are never part of the initial state of the scene even if the Keyframe has power on frame zero, and the Keyframe moved the group 20 metres in the positive X direction but left the movable member of the group behind.
And these steps are an easy example of fixing a wrong "make movable". Harder examples may involve searching high and low for objects that have become too small to see or lost in the distance fog. And if the connector was only intended as a temporary constraint for getting an object to the desired position, it might not even be there any more to serve as a clue to what went wrong.
On the other hand, fixing a wrong "don't make movable" is always easy - just open the chid object's tweak menu and turn on its movable tweak.
It would be nice if the decision on making child objects of new connectors movable were smarter - make it movable only if its transform isn't currently affected by any powered Keyframes.
-
Interesting... if you rewind, does it fix itself? Could be a simple bug I think.
You could use the SHARE button to record a demonstration like this, upload to youtube or whatever, and include a link to it in the post. It can be a lot quicker to make, and easier to understand, with just a video. It also proves this problem can happen, and shows people 100% of what you do in case you missed anything that may contribute to the issue.
For example, I think followed your steps, but didn't have the problem. https://youtu.be/xtagxFMkQHU But maybe I missed something. Or maybe you forgot a step. But a video from you would make sure nothing is lost in translation and it's clearly possible for the problem to happen.
Iniciar sesión para dejar un comentario.