Hi everyone,
I’d like to make some changes to class and interfaces responsible for animations.
- Making Track an interface. This way all kinds of tracks will have something in common
Here is how it would look.
[java]
public interface Track<T> extends Savable {
public abstract void setTime(float time, T target, float weight);
void setKeyframes(float[] times, Vector3f[] translations, Quaternion[] rotations, Vector3f[] scales);
Quaternion[] getRotations();
Vector3f[] getScales();
float[] getTimes();
Vector3f[] getTranslations();
}
[/java]
T is the target type that the track will affect.
This will cause changes in the current tracks implementations:
[java]
public final class BoneTrack implements Track<Skeleton> {/** … /}
public final class PoseTrack implements Track<Mesh[]> {/ … /}
public class SpatialTrack implements Track<Spatial> {/ … */}
[/java]
At this moment the ‘Track’ is a class and only PoseTrack is extending it.
When ‘Track’ is turned into an interface its functionality will be moved to PoseTrack.
- Animation interface changes:
[java]
public interface Animation<T extends Track<?>> extends Savable, Cloneable {
String getName();
float getLength();
void setTime(float time, float blendAmount, AnimControl control, AnimChannel channel);
T[] getTracks();
Animation<T> clone();
}
[/java]
This way we will ensure that the animation will be dependant on the Track implementing class.
So then we will have changes in current animation implementations:
[java]
public final class BoneAnimation implements Animation<BoneTrack> {/* … /}
public class MeshAnimation implements Animation<PoseTrack> {/ … /}
public class SpatialAnimation implements Animation<SpatialTrack> {/ … */}
[/java]
These changes are intended to give more abstraction to animations.
The good news is that it will not cause (or at least should not cause
) many problems with already existing code.
Tell me what do you think about it.
Especially you Kirill You’re the author of these classes.
Cheers,
Kaelthas