Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request to refactor THREE.Interpolant to make it more flexible, less tightly coupled. #8747

Open
4 of 12 tasks
bhouston opened this issue Apr 26, 2016 · 2 comments
Open
4 of 12 tasks

Comments

@bhouston
Copy link
Contributor

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
  • Dev
  • r76
  • ...
Browser
  • All of them
  • Chrome
  • Firefox
  • Internet Explorer
OS
  • All of them
  • Windows
  • Linux
  • Android
  • IOS
@tschw
Copy link
Contributor

tschw commented Apr 26, 2016

@bhouston
Sounds good.

Change it around as much as you like. Please just make sure that existing functionality, in particular automatic smooth interpolation, is kept.

On the design issues:

I considered going the Unity way and using loop modes for the line endings, but ended up not doing so, because they are not the same...

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.

....and would cause confusion. Like here, I guess. They're not at all about finding indexes:

When using smooth interpolation, the line endings (which really really are not loop modes, regardless of Unity's pragmatism on that) determine whether to establish continuity to wrap back to the start or whether to stop. A third line ending mode is to extrapolate, which doesn't equate to a loop mode.

I don't insist on you keeping the line ending automation. OTOH I guess, you may want to, even with tangent data: It allows you to smoothly start/loop/stop a single clip. Without you'd always need three (starting round, repeating round, stopping round).

@donmccurdy
Copy link
Collaborator

The main features of Unity3D's Animation Curve is that each keyframe has a value, and an inTangent and an outTangent...

We're implementing something like this for GLTFLoader in #12907, by creating a new GLTFCubicSplineInterpolant class and overriding createInterpolant. If that could be reused for any other formats, perhaps it's a starting point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants