Yes but bone length would be easier to implement, and would be more compatible with older files
If only bone length was implemented using shortcuts based on existing architecture...when it comes time to implement scaling, it'll have to be completely tossed aside or else become a mess to fold into the code. Better to lay a strong foundation, I think.
As for compatibility with older files, that's not an issue. Scale and movement are additional data blocks, so its absence just means it doesn't have the new stuff. A key in the anim8or file looks like this (bone01, axis Y):
jointangle { "bone01" "Y"
track {
floatkey { 0 0 10 10 "S" }
}
}A full rotate, scale, translate implementation can just add "jointscale" and "jointtrans" blocks, and look like this (thinking about it, shouldn't floatkey be pointkey?).
jointangle { "bone01" "Y"
track {
floatkey { 0 0 10 10 "S" }
}
}
jointscale { "bone01" "Y"
track {
floatkey { 0 0 10 10 "S" }
}
}
jointtrans { "bone01" "Y"
track {
floatkey { 0 0 10 10 "S" }
}
}Also, you guys haven't even described what animating the length of bones would do. Would it just translate the vertices or would it scale it? If one was picked then how would the other be implemented later on? Instead, going by the convention of scaling and movement of bones would be less ambiguous and more powerful. If scaling, vertices would be scaled. If moving, vertices would be translated.
