Hello, I wrote a C++ library to create tweeners and I'm thinking about porting it to Boost. The purpose of the tweeners is 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. 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 documentation of the library is available at http://libclaw.sourceforge.net/tweeners.html and the source code is available at http://sourceforge.net/projects/libclaw/files/libclaw/1.7.1/ as part of a larger library named Claw (check the claw/tween and claw/code/tween folders) Is there an interest to add this tweener library to Boost and what would be the adaptations to do? Regards, -- Julien Jorge
Looks nice, very useful for attractive and dynamic UIs. I would like to see it in boost ;) -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Julien Jorge Sent: Friday, July 13, 2012 12:07 AM To: boost@lists.boost.org Subject: [boost] Interest in a tweener library Hello, I wrote a C++ library to create tweeners and I'm thinking about porting it to Boost. The purpose of the tweeners is 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. 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 documentation of the library is available at http://libclaw.sourceforge.net/tweeners.html and the source code is available at http://sourceforge.net/projects/libclaw/files/libclaw/1.7.1/ as part of a larger library named Claw (check the claw/tween and claw/code/tween folders) Is there an interest to add this tweener library to Boost and what would be the adaptations to do? Regards, -- Julien Jorge _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, Indeed, this library is very interesting, in particular in my domain (video games and other interactive and animated softwares). I used cpptweener before and wanted to update it to get more modern, but didn't found the time to in the end. I have some questions after having read the documentation page and some of the API doc: 1. Why does these types always accept double only? Is there a specific reason? I think this is greatly limiting the potential use of the library, because most use I've seen and done don't use double and sometime use custom value types. So I think it needs to be templatized to allow the user to provide the value type. 2. If you templatize, then I would like to know the kind of concepts accepted by each ease function. This kind of library is very useful when you can use the same code to interpolate, for example, 2D and 3D vectors, instead of just a value. So it is important to says clearly which operations have to be implemented for the value type to work with the ease. 3. My understanding of the tweening concepts isn't complete, but maybe you can light me up: isn't there special maths that need to be supported if you want to "tween" an orientation value? (I mean any object that represent an orientation). Interpolation of orientation/rotation is as useful as other values to me. 4. I see in tweener_group/sequence that the insert function take a const reference to a tweener. This is a bit obscure: does it imply a copy of the tweener or does it mean that I have to keep the lifetime of the tweener during the existence of the group/sequence? If it is a copy (I hope it is) then making the copy in the interface would be both useful and explicit. If not, using smart pointers would be necessary (to me at least). 5. Why is the clone function in base_tweener needed? 6. I suppose that there is no problem using lambdas to define update functions? 7. On performance side, shouldn't ease functions be inlined or template instead of implemented in the cpp file? 8. The difference between single_tweener and tweener isn't clear to me. Can you explain? Thanks Joel Lamotte
Le Fri, 13 Jul 2012 17:29:47 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
Hi,
Indeed, this library is very interesting, in particular in my domain (video games and other interactive and animated softwares). I used cpptweener before and wanted to update it to get more modern, but didn't found the time to in the end.
I have some questions after having read the documentation page and some of the API doc:
1. Why does these types always accept double only? Is there a specific reason? I think this is greatly limiting the potential use of the library, because most use I've seen and done don't use double and sometime use custom value types. So I think it needs to be templatized to allow the user to provide the value type.
Since the goal of the tweeners is to compute intermediate values in a range, I guessed that floating point values would be enough. Even if the user wanted to interpolate on an other type, like integers or my_custom_number_type, I supposed that he would convert the bound values to double and cast the intermediate values from double to his final type in the callbacks. I never felt restricted by the double but I can think about using templates.
2. If you templatize, then I would like to know the kind of concepts accepted by each ease function. This kind of library is very useful when you can use the same code to interpolate, for example, 2D and 3D vectors, instead of just a value. So it is important to says clearly which operations have to be implemented for the value type to work with the ease.
In the case where the tweener classes are templatized, I think that the main requirement for the type is to support substraction and multiplication. The easing functions are agnostic with regard to the domain of the interpolated values. They just take the fraction of the interpolation duration represented in [0, 1] and tell "where" the tweened value is in a fraction of the distance between the origin and target values. So I think that the templatization would need two types: the user type T used in tweener classes and an other type E used in the easing functions. E should be a type that can represent values in [0, 1] and T must accept a multiplication by E. For the case of more complex types like 2D and 3D vectors, I think they could be used for T but, as a user, that is not the way I would use the library. Instead, I guess that I would write a helper function that builds a tweener_group containing a single_tweener on each dimension of the vector.
3. My understanding of the tweening concepts isn't complete, but maybe you can light me up: isn't there special maths that need to be supported if you want to "tween" an orientation value? (I mean any object that represent an orientation). Interpolation of orientation/rotation is as useful as other values to me.
When I use the tweeners in my games, I interpolate the position, the orientation and rotations independently. In this situation, there is no need for special maths. If the tweened components were not independent, I suppose I would apply the interpolation on some of them and adjust the others in the callbacks. The math would not appear in the tweener library this way.
4. I see in tweener_group/sequence that the insert function take a const reference to a tweener. This is a bit obscure: does it imply a copy of the tweener or does it mean that I have to keep the lifetime of the tweener during the existence of the group/sequence? If it is a copy (I hope it is) then making the copy in the interface would be both useful and explicit. If not, using smart pointers would be necessary (to me at least).
Indeed, the group and sequence store a copy of the tweener. I did not want to expose pointers on the interface, thus the tweener class stores a pointer to a base_tweener and duplicates the instance when copied. The goal of the const& is to avoid some copies but I do not mind to remove it. I think that the interface of tweener_group and tweener_sequence is cleaner with methods arguments declared as tweener and I do not have to handle the pointers in them. One of the other reasons I used the tweener class in the interface was that I did not want the user to be able to insert several times the same pointer in a tweener_group or tweener_sequence. For example, the following code would cause problems: single_tweener* t = new single_tweener( /* … */ ); tweener_sequence s; for ( std::size_t i=0; i!=n; ++i ) s.insert( t ); Because when you will call s.update(), it will update every occurrence of t at once. But this one is OK: single_tweener t( /* … */ ); tweener_sequence s; for ( std::size_t i=0; i!=n; ++i ) s.insert( t ); Because a copy of t is inserted at each iteration.
5. Why is the clone function in base_tweener needed?
The clone function is used by the tweener class to copy the underlying base_tweener when copied (See 4).
6. I suppose that there is no problem using lambdas to define update functions?
The update function is declared as a boost::function. I guess that it guarantees that it works with lambdas this but I never tried :)
7. On performance side, shouldn't ease functions be inlined or template instead of implemented in the cpp file?
For the templates, see answer 2. For the performance, I don't think they should be inlined. First, I have no measure to tell that there is a performance bottleneck in the use of the ease functions. Then, the functions are passed as an argument to the constructor of single_tweener. I don't see how the compiler could inline a function used this way.
8. The difference between single_tweener and tweener isn't clear to me. Can you explain?
The single_tweener computes the intermediate values between two bounds according to an ease function. The tweener class does nothing but carrying an instance of base_tweener and providing an interface to update it. I use the tweener class to simplify the interface of tweener_group and tweener_sequence and for the cases where I want a tweener but do not care about its implementation. Regards, Julien Jorge
2. If you templatize, then I would like to know the kind of concepts accepted by each ease function. This kind of library is very useful when you can use the same code to interpolate, for example, 2D and 3D vectors, instead of just a value. So it is important to says clearly which operations have to be implemented for the value type to work with the ease.
In the case where the tweener classes are templatized, I think that the main requirement for the type is to support substraction and multiplication.
The easing functions are agnostic with regard to the domain of the interpolated values. They just take the fraction of the interpolation duration represented in [0, 1] and tell "where" the tweened value is in a fraction of the distance between the origin and target values.
So I think that the templatization would need two types: the user type T used in tweener classes and an other type E used in the easing functions. E should be a type that can represent values in [0, 1] and T must accept a multiplication by E.
To me it sounds like your T is a vector in an abstract vector space and your E is the associated scalar type. You just happen to have 1-dimensional vectors called "doubles" right now.
For the case of more complex types like 2D and 3D vectors, I think they could be used for T but, as a user, that is not the way I would use the library. Instead, I guess that I would write a helper function that builds a tweener_group containing a single_tweener on each dimension of the vector.
I could see wanting to perform operations against the abstract vectors directly. This would permit using SSE-like instructions on long vectors (through some suitable abstraction, of course). - Rhys
On Sat, Jul 14, 2012 at 9:17 PM, Julien Jorge <julien.jorge@gamned.org>wrote:
Le Fri, 13 Jul 2012 17:29:47 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
3. My understanding of the tweening concepts isn't complete, but maybe you can light me up: isn't there special maths that need to be supported if you want to "tween" an orientation value? (I mean any object that represent an orientation). Interpolation of orientation/rotation is as useful as other values to me.
When I use the tweeners in my games, I interpolate the position, the orientation and rotations independently. In this situation, there is no need for special maths.
What I meant isn't that they would be done in the same time, but that interpolation for rotation required different kind of interpolation, in 3D at least (I don't know if it can be generalized).
4. I see in tweener_group/sequence that the insert function take a const reference to a tweener. This is a bit obscure: does it imply a copy of the tweener or does it mean that I have to keep the lifetime of the tweener during the existence of the group/sequence? If it is a copy (I hope it is) then making the copy in the interface would be both useful and explicit. If not, using smart pointers would be necessary (to me at least).
Indeed, the group and sequence store a copy of the tweener. I did not want to expose pointers on the interface, thus the tweener class stores a pointer to a base_tweener and duplicates the instance when copied. The goal of the const& is to avoid some copies but I do not mind to remove it.
I would have done the same without recent mindshifts due to the new standard, it was just not clear to me if there was a copy (maybe just documenting is enough). I agree using pointers here would have been a bad idea. For the case of more complex types like 2D and 3D vectors, I think
they could be used for T but, as a user, that is not the way I would use the library. Instead, I guess that I would write a helper function that builds a tweener_group containing a single_tweener on each dimension of the vector.
I see but I think it is overkill compared to a vectorized aproach, as Rhys Ulerich suggest, that is more generic and I think easier to use. I'm just not certain what would be the concept of a vectorized type.
For the performance, I don't think they should be inlined. First, I have no measure to tell that there is a performance bottleneck in the use of the ease functions. Then, the functions are passed as an argument to the constructor of single_tweener. I don't see how the compiler could inline a function used this way.
I don't know what you mean exactly, but i'm not a specialist either and I didn't benchmark anything. By the way, you suggest that the library would not be header-only? Or you don't mind if it is asked to be? Thanks, your answers are helpful. Id
Le Sun, 15 Jul 2012 11:29:06 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
On Sat, Jul 14, 2012 at 9:17 PM, Julien Jorge <julien.jorge@gamned.org>wrote:
For the performance, I don't think they should be inlined. First, I have no measure to tell that there is a performance bottleneck in the use of the ease functions. Then, the functions are passed as an argument to the constructor of single_tweener. I don't see how the compiler could inline a function used this way.
I don't know what you mean exactly, but i'm not a specialist either and I didn't benchmark anything. By the way, you suggest that the library would not be header-only? Or you don't mind if it is asked to be?
I don't mind if it is asked to be header only, and actually a template implementation using the the vectorized approach suggested by Rhys Ulerich seems interesting. What I say however is that I do not see how the compiler can inline the function f() in the following situation (that represents how the ease functions are used): inline double f( double ) { // … } void g( boost::function<double (double)>& func ) { double t = /* … */; double d = func( t ); // … } int main() { g( &f ); } Since the address of f is used in the call to g, I suppose that the compiler cannot inline the call in g. Regards, Julien Jorge
I see. Did you consider copying the value instead of keeping a reference to it? Also, what do you think about allowing the user to use one or the other? Joel Lamotte
Le Sun, 15 Jul 2012 13:37:06 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
I see.
Did you consider copying the value instead of keeping a reference to it? Also, what do you think about allowing the user to use one or the other?
Sorry I made a mistake in the code that results in a misunderstanding. The argument of the function g() should not be a reference: void g( boost::function<double (double)> func ) { double t = /* … */; double d = func( t ); // … } int main() { g( &f ); } Thus, it is a copy of the function object. There is no reason to keep a reference to the boost::function here. Julien Jorge
Julien Jorge wrote:
Le Sun, 15 Jul 2012 13:37:06 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
Did you consider copying the value instead of keeping a reference to it? Also, what do you think about allowing the user to use one or the other?
Sorry I made a mistake in the code that results in a misunderstanding. The argument of the function g() should not be a reference:
void g( boost::function<double (double)> func ) { double t = /* … */; double d = func( t ); // … }
int main() { g( &f ); }
Thus, it is a copy of the function object. There is no reason to keep a reference to the boost::function here.
From what you've posted, there's no need to copy the boost::function object. Anyway, if g() were a function template, then the compiler could inline the call to f(): double f() { // ... } template <class F> void g(F _function) { double const t(/*...*/); double const d(_function(t)); // ... } int main() { g(f); } _function(t) would actually be f(t), with no boost::function object, and it could be inlined. That, however, requires that the caller create boost::function objects when those are needed to bind arguments, including this pointers. If g() would be bloated because most of the code is not dependent on F, then factor out code before and after calling the function argument into non-template helper functions called by g(). _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Thu, Jul 12, 2012 at 11:07 PM, Julien Jorge <julien.jorge@gamned.org>wrote:
Is there an interest to add this tweener library to Boost and what would be the adaptations to do?
Are you planning to work on this library soon? As I said before, I'm really interested into this library. I think I'll need something like it for my new project soon (not sure when, but it might be in 2 or 3 weeks) . So if you have an online repository where this library would be isolated, and at least would be templated as asked, I'm willing to try it ASAP and help it's development. Joel Lamotte
Le Thu, 19 Jul 2012 11:37:52 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
On Thu, Jul 12, 2012 at 11:07 PM, Julien Jorge <julien.jorge@gamned.org>wrote:
Is there an interest to add this tweener library to Boost and what would be the adaptations to do?
Are you planning to work on this library soon?
As I said before, I'm really interested into this library. I think I'll need something like it for my new project soon (not sure when, but it might be in 2 or 3 weeks) . So if you have an online repository where this library would be isolated, and at least would be templated as asked, I'm willing to try it ASAP and help it's development.
I had no plan to work on it before September but since you are willing to help I will try to start the transition before the end of the next week. Is there some guidelines to write code for boost, especially in the directory structure? Should I put the code of the templatized classes in the .hpp or can I keep the .hpp/.tpp separation? Julien Jorge
On Thu, Jul 19, 2012 at 12:03:01PM +0200, Julien Jorge wrote:
Le Thu, 19 Jul 2012 11:37:52 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
On Thu, Jul 12, 2012 at 11:07 PM, Julien Jorge <julien.jorge@gamned.org>wrote:
Is there an interest to add this tweener library to Boost and what would be the adaptations to do?
Are you planning to work on this library soon?
As I said before, I'm really interested into this library. I think I'll need something like it for my new project soon (not sure when, but it might be in 2 or 3 weeks) . So if you have an online repository where this library would be isolated, and at least would be templated as asked, I'm willing to try it ASAP and help it's development.
I had no plan to work on it before September but since you are willing to help I will try to start the transition before the end of the next week.
Is there some guidelines to write code for boost, especially in the directory structure? Should I put the code of the templatized classes in the .hpp or can I keep the .hpp/.tpp separation?
FWIW, the convention in the tree seems to be .ipp for secular templates. There might be some guidelines you wish to look at, like tab style, macro naming, casing, license directives, detail namespace naming, etc. -- Lars Viklund | zao@acc.umu.se
On Thu, Jul 19, 2012 at 12:03 PM, Julien Jorge <julien.jorge@gamned.org>wrote:
I had no plan to work on it before September but since you are willing to help I will try to start the transition before the end of the next week.
Nice! Don't rush though, I don't want you to compromise on quality.
Is there some guidelines to write code for boost, especially in the directory structure? Should I put the code of the templatized classes in the .hpp or can I keep the .hpp/.tpp separation?
I think you will find all required information on the website, starting with this page: http://www.boost.org/development/requirements.html Looks like it answer your questions. Joel Lamotte
Hi, I have created a git repository to receive the Boost.Tweener library. It is currently located at git://libclaw.git.sourceforge.net/gitroot/libclaw/boost-tweener (gitweb: http://libclaw.git.sourceforge.net/git/gitweb.cgi?p=libclaw/boost-tweener;a=...) I have started the templatization of the classes. Most easing functions are not template yet (only easing_none and easing_bounce are template) but will be in a few days. single_tweener has two template parameters, which are the type V of the tweened values and the scalar type S associated with V. All other classes do not need V and use only S. There are some points on which I would like to have a feedback: 1. single_tweener takes a reference to std::swap<V> (see line 90 of single_tweener.ipp): boost::bind( &std::swap<value_type>, boost::ref(val), _1 ); On the non-template version, value_type was double and this line caused a compilation error on Mac: error: no matching function for call to 'bind(<unresolved overloaded function type>, const boost::reference_wrapper<double>, boost::arg<1>&)'* The workaround was to use a custom non-template swap function. Do you have an idea on how to avoid the same issue in the new code? 2. The current directory structure looks like this: . ├── include │ └── boost │ └── tweener │ ├── detail │ │ └── impl │ │ └── easing │ └── easing └── test There is also a doc and examples folder but they are currently empty and thus not in the git repository. I'm not sure about the detail/impl/easing tree. Should I put the implementation of the easing functions in boost/tweener/easing/detail/impl instead? 3. Is there a prefered place to store the git repository? Regards, Julien Jorge
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Julien Jorge Sent: Monday, July 23, 2012 7:19 AM To: boost@lists.boost.org Subject: [boost] Progress on the tweener library (was: Interest in a tweener library)
Hi,
I have created a git repository to receive the Boost.Tweener library. It is currently located at git://libclaw.git.sourceforge.net/gitroot/libclaw/boost-tweener (gitweb: http://libclaw.git.sourceforge.net/git/gitweb.cgi?p=libclaw/boost-tweener;a=...)
I have started the templatization of the classes. Most easing functions are not template yet (only easing_none and easing_bounce are template) but will be in a few days. single_tweener has two template parameters, which are the type V of the tweened values and the scalar type S associated with V. All other classes do not need V and use only S.
There are some points on which I would like to have a feedback:
1. single_tweener takes a reference to std::swap<V> (see line 90 of single_tweener.ipp):
boost::bind( &std::swap<value_type>, boost::ref(val), _1 );
On the non-template version, value_type was double and this line caused a compilation error on Mac:
error: no matching function for call to 'bind(<unresolved overloaded function type>, const boost::reference_wrapper<double>, boost::arg<1>&)'*
The workaround was to use a custom non-template swap function. Do you have an idea on how to avoid the same issue in the new code?
2. The current directory structure looks like this: . ├── include │ └── boost │ └── tweener │ ├── detail │ │ └── impl │ │ └── easing │ └── easing └── test
There is also a doc and examples folder but they are currently empty and thus not in the git repository. I'm not sure about the detail/impl/easing tree. Should I put the implementation of the easing functions in boost/tweener/easing/detail/impl instead?
3. Is there a prefered place to store the git repository?
You will probably save time later (and help acceptance) by following the file structure recommended. http://www.boost.org/development/requirements.html#Directory_structure (These Boost structures may seem a bit odd but there are reasons too complicated to discuss here). Examples should go in the /examples folder and tests in the /test folder ;-) HTH Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Mon, Jul 23, 2012 at 8:18 AM, Julien Jorge <julien.jorge@gamned.org>wrote:
3. Is there a prefered place to store the git repository?
AFAIK you are free to use whatever you want. However, I'm not sure if it is still in motion but all the boost libraries will be found on gihub in the future, at least as official clones or something like that. There have also been talking about private repositories but I don't know more about it. Anyway I think that it's not important until it is included in boost and distributed officially. At this stage, don't worry about this. Joel Lamote
I have a suggestion: Having tests that check compatibility of Tweener with Boost.Geometry would be very nice. I am not exactly sure about this because I didn't use Boost.Geometry yet but I was thinking about trying it instead of writing my own spatial position types (for non-graphic purposes). It seems to me that Boost.Geometry concepts would work well with your library. Joel Lamotte
Le Tue, 24 Jul 2012 17:02:09 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
I have a suggestion: Having tests that check compatibility of Tweener with Boost.Geometry would be very nice.
I am not exactly sure about this because I didn't use Boost.Geometry yet but I was thinking about trying it instead of writing my own spatial position types (for non-graphic purposes). It seems to me that Boost.Geometry concepts would work well with your library.
It seems interesting indeed. I have just finished the templatization and I wrote a sample program that applies a tweener to a structure representing a coordinate. It works :) The single_tweener class is templatized with the vector type V and and the associated scalar type S. It needs the following operators: V operator+( V, V ); V operator-( V, V ); V operator*( S, V ); I had a quick look at Boost.Geometry and I am not sure that those operators are always defined for the point concept. I will need to look further at this library. Also, it would be nice if the type S could be determined from V. My next step will be to write the documentation of the library, to make the test programs to run with Boost.test and to have a look at Boost.Geometry. Julien Jorge
On 24-7-2012 23:25, Julien Jorge wrote:
Le Tue, 24 Jul 2012 17:02:09 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
The single_tweener class is templatized with the vector type V and and the associated scalar type S. It needs the following operators:
V operator+( V, V ); V operator-( V, V ); V operator*( S, V );
I had a quick look at Boost.Geometry and I am not sure that those operators are always defined for the point concept.
Indeed, there are no operators defined for the Point Concept in Boost.Geometry. I did not have a chance to look at Tweener yet so cannot say more about this. Regards, Barend
I believe that most tweener required operators implementations are available in boost geometry as algorithms? I think everything related to (Bezier) curves is missing though. Otherwise, using boost algoritms as implementation for unknown types looks like the way to go? Joel Lamotte
Le Wed, 25 Jul 2012 01:44:48 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
I believe that most tweener required operators implementations are available in boost geometry as algorithms? I think everything related to (Bezier) curves is missing though. Otherwise, using boost algoritms as implementation for unknown types looks like the way to go?
I have finally implemented single_tweener with the algorithms of Boost.Geometry, and it works well; except for the simple case where only a double value is tweened. It seems that the double type does not fulfil the point concept of Boost.Geometry. Otherwise, I have been able to apply a tweener to a custom coordinate structure and to a boost::geometry::model::point<…>. For the case of the double type, I guess I can find a workaround by providing a specialized implementation for Boost.Geometry and keeping the previous implementation for the general case. I'm not sure to understand your comment related to Bézier curves. Do you want to be able to use an equation of Bézier as the easing function? Also, if we go in this direction, is there anything related to Bézier curves in Boost already? Julien Jorge
On Wed, Jul 25, 2012 at 7:55 AM, Julien Jorge <julien.jorge@gamned.org>wrote:
For the case of the double type, I guess I can find a workaround by providing a specialized implementation for Boost.Geometry and keeping the previous implementation for the general case.
Oh I see, the Point concept can work with types like double if it is wrapped as bg::model::point<double, 1>. Not sure it's the best strategy to deal with it but that's a possibility you could use for any type that is not accepted by boost geometry, as a last resort conversion. I guess you'll have to try different strategies see what's efficient.
I'm not sure to understand your comment related to Bézier curves. Do you want to be able to use an equation of Bézier as the easing function? Also, if we go in this direction, is there anything related to Bézier curves in Boost already?
Boost Geometry currently doesn't provide bezier curves AFAIK even if there have been work in this direction. I'll use this kind of algorithms, combined with steering behaviours, so it's part of my specific needs, but if you don't provide it from the beginning it's not a problem I can implement it myself. The use would be to move something on a bezier curve (in 3D) using a tweener. It don't seem hard to implement once you have something like tweener. Joel Lamotte
Le Wed, 25 Jul 2012 11:39:05 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
On Wed, Jul 25, 2012 at 7:55 AM, Julien Jorge <julien.jorge@gamned.org>wrote:
For the case of the double type, I guess I can find a workaround by providing a specialized implementation for Boost.Geometry and keeping the previous implementation for the general case.
Oh I see, the Point concept can work with types like double if it is wrapped as bg::model::point<double, 1>. Not sure it's the best strategy to deal with it but that's a possibility you could use for any type that is not accepted by boost geometry, as a last resort conversion. I guess you'll have to try different strategies see what's efficient.
I finally managed to make the tweeners to work with both Boost.Geometry and double by selecting the implementation using bg::tag<P>::type. If the tag is not void, the implementation uses the algorithms of Boost.Geometry. Otherwise it falls back to the default computation using the default operators. However, if the user of the library has a custom coordinate type that cannot be adapted to bg::point and for which the arithmetic operators are not defined, then he won't be able to use the single_tweener as is. There is still the solution for him to use a tweener_group on each dimension of the type but maybe the library should provide a way to pass the operators to the tweeners (through some kind of point_traits?). Julien Jorge
Hi Julien, On 26-7-2012 7:54, Julien Jorge wrote:
Le Wed, 25 Jul 2012 11:39:05 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
On Wed, Jul 25, 2012 at 7:55 AM, Julien Jorge <julien.jorge@gamned.org>wrote:
For the case of the double type, I guess I can find a workaround by providing a specialized implementation for Boost.Geometry and keeping the previous implementation for the general case.
Oh I see, the Point concept can work with types like double if it is wrapped as bg::model::point<double, 1>. Not sure it's the best strategy to deal with it but that's a possibility you could use for any type that is not accepted by boost geometry, as a last resort conversion. I guess you'll have to try different strategies see what's efficient. I finally managed to make the tweeners to work with both Boost.Geometry and double by selecting the implementation using bg::tag<P>::type.
Great to hear!
If the tag is not void, the implementation uses the algorithms of Boost.Geometry. Otherwise it falls back to the default computation using the default operators.
However, if the user of the library has a custom coordinate type that cannot be adapted to bg::point and for which the arithmetic operators are not defined, then he won't be able to use the single_tweener as is. There is still the solution for him to use a tweener_group on each dimension of the type but maybe the library should provide a way to pass the operators to the tweeners (through some kind of point_traits?).
Because I cc this Geometry list now, I copy here your earlier info to access the library: http://lists.boost.org/Archives/boost/2012/07/195216.php and the first message: http://lists.boost.org/Archives/boost/2012/07/194979.php Regards, Barend
participants (8)
-
Alexander Stoyan -
Barend Gehrels -
Julien Jorge -
Klaim - Joël Lamotte -
Lars Viklund -
Paul A. Bristow -
Rhys Ulerich -
Stewart, Robert