Repository: three.js
Issue: Request to refactor THREE.Interpolant to make it more flexible, less tightly coupled.
Labels: Suggestion

##### Description of the problem

I would like to refactor THREE.Interpolant to be a bit simplier base class that has less assumptions about how it will be used.  This would make it more flexible.

I would like to make the following changes:
- Remove the assumption in the base class that there is one sampleValues buffer, it has a sampleSize and it has a resultsBuffer.  Rather I would prefer if the base class made no assumptions on the storage structure.  We could then have a THREE.BufferInterpolant derived class that has these assumptions.  This is a coupling reduction change.
- I would like to create a separate findIndex( time, optionalSuggestedIndex ) function isolated finding the current index given the current time and an optional suggested start index for the search.  It will return a single integer, which is -1 if the time is before the range and T (where T is the size of the time array) if the time is after the range.  This will remove the idea that different types of interpolators are called based on the results of the search -- you can still do that based on the returned integer value but it won't be tightly coupled as it is now.
- I would also like to remove the loop type/extrapolator awareness from the findIndex() function - if someone is ping/pong or repeat, that can be determined before going into the findIndex() function as it is fully separable.
- I would like to move _cachedIndex out of the base class and have it as an optional parameter to evaluate() -- just as a means of speeding up the search (it would be passed to findIndex.)  The reason is I would like to share these Interpolants between multiple animations that may not be synchronized and thus I would be accessing the same Interpolant class in two or more ways, and thus I could use a different cachedIndex for each usage.  This is reducing the coupling.  THREE.BufferInterpolant could still have it if desired.
- Rename "ending" to "extrapolation" to be more consistent with other programs.  (The other term that is used is "wrap" type but "extrapolation" I feel is better.)
- I would like to synchronize the extrapolation names with Loop names as much as possible as that is generally what they support.  Right now we do not have an Extrapolation mode that matches up with LoopPingPong and the other two Wrap/Extrapolation names that do align with Loop modes are not that suggestive.  I am unsure what is the right solution here.  Here is what unity uses for both AnimationClips and AnimationCurves: http://docs.unity3d.com/ScriptReference/WrapMode.html
- Rename parameterPosition to time as that is the majority use case?  (This is just a personal preference.)

The reason is I would like to replicate the behavior of Unity3D's AnimationCurve more closely:

http://docs.unity3d.com/ScriptReference/AnimationCurve.html

The main features of Unity3D's Animation Curve is that each keyframe has a value, and an inTangent and an outTangent.  If you set inTangent and outTangent to 0 you get linear interpolation but if you set them to 1 each you get cubic interpolation.  This is really useful for precise control of keyframe animations.

There is another pattern that is often used in animation it is the TCB pattern used by FBX, Maya, 3DS Max and Softimage.  It uses on a per key basis a value (vec3, quat, etc.) + bias + continuity + tension - which is again is multiple bits of data per key that I would like to be able to support.

But I guess if we have baked all these flat animation primitives so deeply into mixer, can I do this decoupling so I can use more expressive animation curves and custom ones?

/ping @tschw 
##### Three.js version
- [x] Dev
- [x] r76
- [ ] ...
##### Browser
- [x] All of them
- [ ] Chrome
- [ ] Firefox
- [ ] Internet Explorer
##### OS
- [x] All of them
- [ ] Windows
- [ ] Linux
- [ ] Android
- [ ] IOS