Philippe Hurbain Wrote:Tried again to understand a tiny bit more the animations... and failed miserably.
I tried to animate the attached model using groups, but top rotor doesn't rotate correctly (it starts rotated 90°). Suspecting (wrongly) it might be an interaction with submodels, I flattened the model... to get a result even worse. Looking at the propriety of the groups, I guess I understand what happens: their default orientation is not identity, so the setOri wipes out their initial rotation. I guess I could solve this with a matrix multiplication, but it's much more complicated than I expected...
Yes the setOri call is absolute and thus will only act as expected on groups/references using an identity matrix. To compensate for this you need to buffer the original orientation in the onStart function, like so:
Code:
function onStart()
--grp ori bug prevention
topRotorBaseOri=ldc.subfile():getGroup('TopRotor'):getOri()
end
And then apply it on a per frame like so:
Code:
local ax2=mainSf:getGroup('TopRotor')
ori:setRotate(-angle, 0, 1, 0)
ori:mulBA(topRotorBaseOri)
ax2:setOri(ori)
Note: I've flipped the sign of angle to make it spin the right way.
You could also buffer the group references in the start event, but this being a very small script it won't matter much speed wise.
Philippe Hurbain Wrote:Otherwise, I tried also something else: animate flexible parts. I hoped that if I included a flex part path point to a group, this path point would be animated too with the group... doesn't work!Not yet indeed, I need to make some adjustments path/spring generation stuff in order to make that useful (fast enough etc). This is something I hope to do for 1.6 as part of the animation/script improvements.