Klaim - Joël Lamotte wrote:

Hi, some comments on your remarks Micheal:

On Sat, Mar 2, 2013 at 10:28 AM, Michael Marcin <mike.marcin@gmail.com>wrote:

...

How do you do looping tweens? (Both N and infinite loops)

How do you do relative tweens, i.e. instead of tween from -> to, tween by. I guess this might not matter as it seems the tweener only tweens its own internal value. In many cases it would seem nice to update a memory location directly. For instance a member variable of the class that owns the tween.

Looks to me like advanced features that are not necessary for a first version. In particular, in my experience checking a value in memory have been less useful (and harder to make safe) than keeping a copy of the target value, but allow it to be updated from user code.

Tweening a copy and then assigning from it every update is acceptable as this is pretty easy to accomplish from user code. The looping behavior is something that is not easy to implement in user code. For example HOTween supports N or infinite loops of these types: // When a tween completes, rewinds the animation and restarts (X to Y, repeat). Restart, // Tweens to the end values then back to the original ones and so on (X to Y, Y to X, repeat). Yoyo, // Like <see cref="LoopType.Yoyo"/>, but also inverts the easing (meaning if it was <c>easeInSomething</c>, it will become <c>easeOutSomething</c>, and viceversa). YoyoInverse, // Continuously increments the tween (X to Y, Y to Y+(Y-X), and so on), // thus always moving "onward". Incremental

...

domain_type feels awkard. It's used as both a time_point and duration to borrow boost::chrono terminology.

I think you assume that tweening/interpolation is relative to time. It is not. This library should never depends on time. It could provide extensions later to work with time but I feel it's unnecessary.

Sorry I don't mean actual time, although internally it uses time terminology. Using duration as a [0,1] ratio or as a 0 to int numItemsToLoadForProgressBar is just as valid. I only mean to imply that the difference type of domain_type - domain_type might not necessarily be domain_type. If the interface reflected this it would then be easier to tell when something is a relative change (delta) vs an absolute value. And as a plus you could use chrono types directly I think as even though time isn't the only domain_type it's certainly a common one. I think you can just get domain_difference_type from domain_type using result_of or typeof.

...

Why does base_tweener have a virtual destructor, virtual do_clone and virtual do_is_finished members? It seems you could easily just use CRTP here.

Not sure it's possible in this case, but that would be cool.

It seems like it's all for the sake of tweener which is I believe essentially type erasure for tweens. I don't think this virtual overhead should be paid for every tween just for this sake. The only time you should need type erasure is if you're making a tween group or tween sequence composed of single_tweeners with different value_types. Or if you're compositing single_tweeners, tween_sequences, and tween_groups.

...

I think tweener_sequence/tweener_group should be a container adapter or at least switched to use a std::vector. I know I wouldn't want to pay for a std::list here in any use case I can imagine.

FWIW if you're using a std::list (like in tweener_group.ipp) instead of: const iterator_type tmp(it); ++it; m_tweeners.erase(tmp); you can do: it = m_tweeners.erase(it);

I think the order of tween updates for sequences/groups can be important. There should be a guarantee of first-in first-update order and I think the name insert should change to push_back to reflect the ordered nature of the operation.

I agree that vector instead of list would be far better.

...

It seems all tweeners are one shot in that you cannot restart them. tween_sequence and tweener_groups do_update is destructive and prevents being able to restart the group.

I'm not sure to understand what you mean here.

If you look inside their do_update calls they remove things from the lists as you're going through them. This means you can't for instance create a tween group that scales a menu button and changes it's color and play it every time the user does a mouse-down event. You'll have to recreate it every time.

...

Why are all the callbacks boost::functions? It's already a template can't I just use my own callback type without paying for the type erasure and dispatch of a boost::function if I don't need it?

I think the functions should be template but inside they still have to use boost::function for storing the callback.

I don't think that's necessarily true. You can just store a copy of the callback in the tweener so long as the type of the tweener depends on the type of the callback. Although I could be convinced it might just be easier and cleaner to pay the overhead for the type erasure here.

...

There appears to be no interface to set the current time_point (m_date) directly you can only move it a relative amount. There is also no interface to query it. This is a very useful feature, it allows you for instance to bind your tween to a slider and scrub back and forth through it.

I don't understand why you are talking about time and then about non-time based interpolation. Do you mean a way to set manually the interpolation state from outside?

The actual type of the domain_type (be it time or otherwise) is irrelevant. I just mean a way to set the value of the internal m_date member and get the appropriate value out of the tween. I think the example makes the desired behavior pretty straight forward. Come to think of it there is also no support for playing the tweens backwards. A negative delta passed to update doesn't work correctly.

...

Supporting multiple callbacks for on_finished seems unnecessarily expensive an inconsistent (only one update callback supported).

Not sure about this.

iTween, HOTween, TweenLite don't have multiple callbacks, never felt limited without them. Also it's a pretty easy feature to add from user code but it's impossible to avoid the cost of multiple callbacks if you're only using one when it's implemented internally. The cost is much higher than I would want to pay, for instance: template<typename S> void boost::tweener::base_tweener<S>::notify_finished() const { // If one of the callbacks deletes the tweener, then m_on_finished will not be // available. Since we still want to execute all the callbacks, we iterate on // a copy of it. const std::list<finish_callback> callbacks(m_on_finished); for ( std::list<finish_callback>::const_iterator it=callbacks.begin(); it!=callbacks.end(); ++it ) (*it)(); } // base_tweener::notify_finished()

...

init/end seems like a strange name pairing. Maybe from/to, begin/end, initial/final? Although using end here at all seems a bit dubious as it is so often used in the as a semi-open interval [begin,end) whereas here it is a closed interval [init,end].

I quite agree, I'm just not sure begin/end wouldnt be misleading. I tend to prefer "target" as the end value name, as it should be modifiable (moving target).

I'm not sure how mutable target works. If t=0.5 with a linear tween from from 0 to 10 (so current position is 5), what happens when I change the target to 20? Does my t stay at 0.5 and my position change to 10? Does my position stay at 5 and my t change to 0.25? Does something else happen? Thanks for the comments.

Le samedi 02 mars 2013 à 03:28 -0600, Michael Marcin a écrit :

Julien Jorge wrote:

...

Hello,

I would like to propose the Boost.Tweener library for preliminary submission.

The purpose of the Boost.Tweener library is to provide solutions to interpolate the intermediate values between two given values during a time interval. Various easing functions can be applied to control the computation of the intermediate values. I felt the need of such a library while developing games but I have also seen this need in various animation softwares.

The library provides the following functionalities: - Interpolation is done on the value of a given variable or using an user-provided callback function, - The interpolated values are computed using a predefined easing function or any user-provided function respecting the contract, - Several tweeners can easily be executed simultaneously or in a row, - The type of the interpolated values are user defined.

Please follow this link to download a Zip of the library: http://sourceforge.net/projects/libclaw/files/boost/boost-tweener-rc1.tar.gz...

Can you check that the library works as expected or tell me what should be fixed before submitting for review? There are various example programs in the archive.

I would prefer Boost.Tween to Boost.Tweener.

That's a change I can do.

How do you do looping tweens? (Both N and infinite loops)

Currently I would do an N-iterations loop by inserting the tweener in a tweener sequence N time, and an infinite loop by creating a new tweener on the on_finished() callbacks. I think I can add a tweener_loop in the library.

How do you do relative tweens, i.e. instead of tween from -> to, tween by. I guess this might not matter as it seems the tweener only tweens its own internal value. In many cases it would seem nice to update a memory location directly. For instance a member variable of the class that owns the tween.

A tween "by" is can be done by using the single_tweener. It has a constructor that takes a reference to a variable (that would be the member variable of the class in your example). Nevertheless it is very limited since the initial value is stored in the constructor. For example, it cannot be done during a sequence on the same variable. The workaround is currently to convert the "by" to a "from -> to" and to use the on_finished() callbacks to create the tweeners with the fresh values. Adding this functionality is not obvious, so I would prefer not to add it to the library yet.

domain_type feels awkard. It's used as both a time_point and duration to borrow boost::chrono terminology.

I agree on the awkwardness of the terminology here. I needed a type T that can multiply the value_type of the tweeners; scalar_type may have been a better name? Actually there is no need for time-related types. All the single_tweener needs to know is the percentage of progression between the initial and final value. Their duration in the groups and sequence is more a weight in the container but "duration" seems a more classic vocabulary. I am still open for suggestions here.

Why does base_tweener have a virtual destructor, virtual do_clone and virtual do_is_finished members? It seems you could easily just use CRTP here.

That would be nice but it seems incompatible with the ability to insert any tweener class in the groups and the sequences.

I think tweener_sequence/tweener_group should be a container adapter or at least switched to use a std::vector. I know I wouldn't want to pay for a std::list here in any use case I can imagine.

OK to switch to std::vector. I never had the need to manipulate the groups and the sequences as containers, so I am not convinced that it would be interesting to go so far.

FWIW if you're using a std::list (like in tweener_group.ipp) instead of: const iterator_type tmp(it); ++it; m_tweeners.erase(tmp); you can do: it = m_tweeners.erase(it);

I think the order of tween updates for sequences/groups can be important. There should be a guarantee of first-in first-update order and I think the name insert should change to push_back to reflect the ordered nature of the operation.

I totally agree for the sequences. About the groups, I think that they should be understood as if all tweeners inside are updated on parallel, maybe with one thread for each. A guarantee of first-in first-update here is more a side effect of the current implementation than a conceptual behaviour.

It seems all tweeners are one shot in that you cannot restart them. tween_sequence and tweener_groups do_update is destructive and prevents being able to restart the group.

I think I can add a reset() function to the tweeners.

Why are all the callbacks boost::functions? It's already a template can't I just use my own callback type without paying for the type erasure and dispatch of a boost::function if I don't need it?

I use boost::functions to make the signature of the callbacks obvious in the interface of the tweeners. As you have noticed it stops the user of the library to use custom callback type and function objects. I can add a template argument to the tweener classes to select the type of the callbacks but the pros do not win the cons for me: Pros: - you use the type of callback that best fits your needs Cons - failing to use the right callback type will display a hard to understand error message on a line inside the implementation of the tweener classes - the callback type will be shared among the tweener classes, so the function objects won't be usable in practice. Globally I am not convinced that the lost in readability would be compensated by the flexibility. Nevertheless I am still open to comments and suggestions on the subject.

There appears to be no interface to set the current time_point (m_date) directly you can only move it a relative amount. There is also no interface to query it. This is a very useful feature, it allows you for instance to bind your tween to a slider and scrub back and forth through it.

OK to add this on single_tweener. I think I can add a similar feature on the tweener_sequence, maybe also on the tweener group. I do not know for the tweener_loop.

Supporting multiple callbacks for on_finished seems unnecessarily expensive an inconsistent (only one update callback supported).

I remember that I needed this but I do not remember why… I'm OK to remove it but I am not sure it is the best decision. It seems to me that it is usual to be able to add multiple callbacks. Maybe should I allow to have multiple update callbacks? Or replace the callbacks with boost::signals?

init/end seems like a strange name pairing. Maybe from/to, begin/end, initial/final? Although using end here at all seems a bit dubious as it is so often used in the as a semi-open interval [begin,end) whereas here it is a closed interval [init,end].

I totally agree. What about origin/target or initial/target?

I personally think a method chaining interface ala HOTween's TweenParms is very nice for configuring tweeners.

I will have a look at TweenParms but I am not familiar with HOTween.

As someone who has used TweenLite, iTween, HOTween, and AniMate as well as rolled his own (poorly) I'm very happy to have such a library proposed to Boost.

Thank you.

Thanks for the feedback. Julien Jorge

On Sat, Mar 2, 2013 at 1:28 AM, Michael Marcin <mike.marcin@gmail.com>wrote:

Julien Jorge wrote:

...

Hello,

I would like to propose the Boost.Tweener library for preliminary submission.

The purpose of the Boost.Tweener library is to provide solutions to interpolate the intermediate values between two given values during a time interval. Various easing functions can be applied to control the computation of the intermediate values. I felt the need of such a library while developing games but I have also seen this need in various animation softwares.

[...]

I would prefer Boost.Tween to Boost.Tweener.

[...] I haven't looked at the library, but just want to comment on the name. Is "tween" some kind of standard term? Because I'm only familiar with it in the context of the first wikipedia result when searching for "tween" or "tweener", and I don't see anything regarding interpolation save for "inbetweening" (standard animation term). Something like Boost.Interpolation might better convey the library's intent, I think. - Jeff

On Mon, Mar 4, 2013 at 6:49 PM, Julien Jorge <julien.jorge@stuff-o-matic.com

wrote:

I am not sure that there is a standard for the tween/tweener terms.

Basically, as it's the term used by almost all (game-related) libraries out there providing these features, I think we can consider tween/er/ing the de-facto standard name for it. As Michael pointed: TweenLite, iTween, HOTween, AniMate, cpptweener, etc. all make reference to tweening. I'm not even counting libraries that have a sub library for tweening inside, like most game engines or frameworks - cocos2d(-X) for example. Jeffrey, the keyword you should have looked at is "tweening" not just "tween". See google results, in particular http://en.wikipedia.org/wiki/Inbetweening also check some stackoverflow questions related, all using the same words: http://stackoverflow.com/search?q=tween I think that the more generic term is not interpolate (as it is only the algorithm inside the operation), but animate (an object's value) /animation, as it is basically procedural generation of animation (be it graphic or not. But I would prefer tween/er/ing as it is clearer for people who worked with such kind of library in the past. Joel Lamotte

On Mon, Mar 4, 2013 at 8:40 PM, Michael Marcin <mike.marcin@gmail.com>wrote:

I first ran across the term in Flash. I'm not sure if that is the origin but I think it has a large role in its popularity.

http://www.adobe.com/devnet/flash/articles/concept_tween.html

I believe it is the origin of the name but not of the functionality. Indeed before doing some flash few years ago, I didn't know that name was used. Once I knew the name, I discovered tons of libraries. The thing is before that, to me, it was value animation, applied either on graphics positions, alpha, effects intensity, sound volume or other effects, etc. But when you say value animation it feels weird so I guess everybody felt having a name like Tween(ing/er) was easier to identify what we're talking about. value animation is also too generic as it include things like steering-behaviours that really are a different (and more reactive) way of doing procedural animation. Joel Lamotte

On Mon, Mar 4, 2013 at 9:49 AM, Julien Jorge <julien.jorge@stuff-o-matic.com

wrote:

Le Mon, 4 Mar 2013 09:27:05 -0800, "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> a écrit :

...

On Sat, Mar 2, 2013 at 1:28 AM, Michael Marcin <mike.marcin@gmail.com>wrote:

...

Julien Jorge wrote:

...

Hello,

I would like to propose the Boost.Tweener library for preliminary submission.

The purpose of the Boost.Tweener library is to provide solutions to interpolate the intermediate values between two given values during a time interval. Various easing functions can be applied to control the computation of the intermediate values. I felt the need of such a library while developing games but I have also seen this need in various animation softwares.

[...]

...

I would prefer Boost.Tween to Boost.Tweener.

[...]

I haven't looked at the library, but just want to comment on the name. Is "tween" some kind of standard term? Because I'm only familiar with it in the context of the first wikipedia result when searching for "tween" or "tweener", and I don't see anything regarding interpolation save for "inbetweening" (standard animation term). Something like Boost.Interpolation might better convey the library's intent, I think.

- Jeff

I think that Boost.Interpolation would be too generic and misleading because the library's interface is more about animating than general interpolation. For example, I think that someone searching to interpolate the colors of the pixels of a scaled image would not find the library really useful.

Has you have noticed, "inbetweening" is the right term in animation. In most libraries I have seen, the term "tweener" is used to name an object that computes the intermediate values during the movement and the verb "to tween" is used to describe the fact that an interpolation is done. I am not sure that there is a standard for the tween/tweener terms.

Sounds like everyone knows what they're talking about except me :) - Jeff

Gottlob Frege wrote:

And while I'm here: how about interpolators that only have a fixed value at one end or the other - ie count down or count up timers/clocks/counters. Maybe not really interpolators, but still value-animators, and useful to be able to have these work within the system.

I think in HOTween you could accomplish this with something like: HOTween.To(myObject, 1, new TweenParms() // tween fieldName of myObject by 1 // relative to its current value (i.e. x=x+1) .Prop("fieldName",1,true) // loop infinitely // incremental loops (i.e. x to y, y to y+*y-x) and so on) .Loops(-1,LoopType.Incremental) );