KX_CameraActuator needs a full rewrite, as it is quite awfully coded, incomplete and unreadable... As for now, this patch attempts to fix T45207 by commenting out a couple of lines.
T45207 is about shaking of the camera whenever it is lower than the tracked object.
It seems that the height < 0 has never been thought as a possible/useful case for the Camera Actuator, but it actually is, according to the bug reporter.
There is a small probability that the feature deleted here would still be useful in some cases...
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- master
Event Timeline
Comment Actions
fp1 and fp2 represent the reference local axes (as defined by the actuator) of the tracked object resp. the camera. In the example given in T45207, they are both Y local axes.
inp is then the dot product of fp1 and fp2. In the example given, inp is negative as soon as the camera arrives below the other object (negative height -> camera below -> tracks to the object -> fp1 and fp2 have more than 90° angle -> negative dot).
"fp1[0] * fp2[1] - fp1[1] * fp2[0] > 0.0f" checks for the z component of the cross product fp1 x fp2.
In either case if inp < 0, the x and y coordinates of the new camera position get displaced by some amount.
I've just seen that this code is still useful in some cases, for example if we chose -Y in the given example. So I have to find a workaround...
Comment Actions
@Quentin Wenger (Matpi) Thanks for identifying the troublesome area. I've taken the liberty of disabling that code slightly less drastically using a threshold value. Could you review D1387 and see whether it's a good fix?
Comment Actions
@Sybren A. Stüvel (sybren): Thank you for your suggestion! I actually noticed that my "drastical" change is bad... I am trying to make it better...
Your patch seems good as far as the shaking is concerned.
But I see another problem here, which is that the behaviour of the camera with other reference axes (-X, +X, -Y) is modified.
Actually, I believe that the actuator already doesn't work well for those other axes atm, so I am trying to make that better at the same time. We cannot really split the patch for each correction, because both parts refer to the same code lines.
I nevertheless take your proposal in account, will see if that is the best way to go when solving the shaking problem.
Comment Actions
@Sybren A. Stüvel (sybren): ok, I think your method on D1387 is sufficient for now. As previously written, I consider that the whole file should be rewritten someday...
I close this revision, I'll comment further on D1387.