Animation problem #2

For help with general CEGUI usage:
- Questions about the usage of CEGUI and its features, if not explained in the documentation.
- Problems with the CMAKE configuration or problems occuring during the build process/compilation.
- Errors or unexpected behaviour.

Moderators: CEGUI MVP, CEGUI Team

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Animation problem #2

Postby Nickenstein79 » Wed Jul 09, 2014 06:20

(I've marked my original animation-question thread as solved, as I found out what I needed to know. This is a new more complex issue)

Currently I am trying to set things up in this way:
1.) Cursor enters a button's area/surface.
2.) Enter-area-event triggers GrowButton animation, which causes button to grow by 10%.
3.) Cursor leaves button area.
4.) Exit-area-event triggers ShrinkButton animation, which causes button to shrink to original size.

Very simple in theory. I want the animation affector to interpolate between (BASE-SIZE * 1) and (BASE-SIZE * 1.1)

So my GrowButton animation code looks like this:

Code: Select all

      // Size (grow)
      {
         CEGUI::Affector* affector = pButtonMousedOverAnim->createAffector("Size", "USize");
         affector->setApplicationMethod(CEGUI::Affector::AM_RelativeMultiply);
         affector->createKeyFrame(0.0f, "{{1.0, 1.0}, {1.0, 1.0}}");
         affector->createKeyFrame(0.3f, "{{1.1, 1.0}, {1.1, 1.0}}", CEGUI::KeyFrame::P_QuadraticAccelerating);
      }


The above code snippet should give the effect I desire. A ten percent widget expansion on width and height. (Scalar component multipliers interp from 1.0 to 1.1, offset component multipliers fixed at 1.0 ).

But what actually happens is the button's size becomes {{0,0},{0,0}} on the first call to affector->apply().



On tracing into the animation system I've discovered the problem. It is because the interpolateRelativeMultiply() function within TPIInterpolators.h can only properly handle discrete float properties.

Basically, that interpolator only works correctly for discrete 'float' values (such as 'Alpha').
And utterly fails with higher types like 'USize' (required for Position/Size/Rotation properties).



For instance, in my example of wanting to interpolate the size of a button/widget, the following code goes wrong inside interpolateRelativeMultiply():

Code: Select all

        typename PropertyHelper<float>::return_type val1 = PropertyHelper<float>::fromString(value1);
        typename PropertyHelper<float>::return_type val2 = PropertyHelper<float>::fromString(value2);


This always results in 'val1' and 'val2' being 0.0f. As the USize values are being handled as discrete 'float' values. Which in turn causes all interpolated values between them to be zero (obviously).




I will look into modding the interpolateRelativeMultiply() code to resolve this issue locally so that it can handle USize values properly.
(I will then do a pull-request and all of that integration stuff, etc).


BUT: Before I get around to fixng this locally (real-life-shit keeps getting in the way), does anybody have any higher insights/knowledge on this topic to throw my way?

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Re: Animation problem #2

Postby Nickenstein79 » Thu Jul 10, 2014 06:27

OK. I think I've solved this one.

The problem boils down to class template clashes with the CEGUI::vector3f class and the interpolator templates. (Something going on with operator overloads not knowing how to multiply a float with a Vector3f, even though the method definition for that does exist within the Vector.h templates.)


I'm obviously not the the first person who has tried to tackle this problem, as I noticed the following comment in one of the "interpolateRelativeMultiply" methods:

Code: Select all

/* DISABLED CODE */

// there is nothing we can do, we have no idea what operators T has overloaded



I think I have found a solution for this by using a partial-template-specialisation to encapsulates/isolates the case of "CEGUI::Vector3f * float" operator overload method. This may require shuffling a couple of things around in the Vector.h file, so I won't be doing a pull request until I'm completely certain that it doesn't break other things.

But if it is robust, then the "interpolateRelativeMultiply" method will finally be usable by types higher than 'float'. Which will make the animation system a lot better. (EG my button-grow example from above will actually work.) :)

I will do a thorough local test tomorrow to be sure I've not broken anything. *Fingers Crossed*

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Animation problem #2

Postby Kulik » Thu Jul 10, 2014 08:55

Look into "sourceProperty". You can make 2 animations:

TransitionInto: keyframe 0 is sourceProperty "Alpha", keyframe 1 is 0
TransitionOut: keyframe 0 is sourceProperty "Alpha", keyframe 1 is 1

MouseOver: TransitionOut->pause(); TransitionInto->start()
MouseOut: TransitionIn->pause(); TransitionInto->start()

I think this is the best way to handle these cases as this will work correctly even if you frantically mouse over and out.

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Re: Animation problem #2

Postby Nickenstein79 » Fri Jul 11, 2014 21:40

Thanks, Kulik. :)

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Re: Animation problem #2

Postby Nickenstein79 » Fri Jul 11, 2014 21:41

I have fixed the problem outlined above, and submitted a mantis ticket for it.

http://cegui.org.uk/mantis/view.php?id=1036

I'm about to do a pull request on the mercurial repo with with my fix.

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Re: Animation problem #2

Postby Nickenstein79 » Mon Jul 14, 2014 17:02

I'm holding off doing a pull request with this fix.

Even though the interpolateRelativeMultiply() now does what it is supposed to do (on my machine), it causes the CEGUIGameMenuDemo to act weird. I am assuming the CEGUIGameMenuDemo somehow compensates for the broken version of the function.

I'm looking into it.

User avatar
Ident
CEGUI Team
Posts: 1998
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: Animation problem #2

Postby Ident » Mon Jul 14, 2014 18:40

Nickenstein79 wrote:I'm holding off doing a pull request with this fix.

Even though the interpolateRelativeMultiply() now does what it is supposed to do (on my machine), it causes the CEGUIGameMenuDemo to act weird. I am assuming the CEGUIGameMenuDemo somehow compensates for the broken version of the function.

I'm looking into it.

I wrote that demo and it relies really heavily on the animation features of CEGUI. Therefore it could easily be that something was "worked around" there by me, that is now fixed and needs to be adapted due to the fix. I don't remember specifics though, it has been a while...
CrazyEddie: "I don't like GUIs"

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Re: Animation problem #2

Postby Nickenstein79 » Mon Jul 14, 2014 18:45

That demo treats the Size of the extending blue lines as a single float. Something that happens to work with the old interpolateRelativeMultiply function purely because only the first float value in size is animated (The width-scale component).

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Re: Animation problem #2

Postby Nickenstein79 » Mon Jul 14, 2014 19:46

OK, I've generated a pull request with my fix for issue #1036, for review : https://bitbucket.org/cegui/cegui/pull-request/89/fix-for-issue-1036/diff

(This includes a slight mod to the XML in GameMenu.anims to correct for the new interpolateRelativeMultiply method.)

Changes made to the following files:

TplInterpolators.h
AnimationManager.cpp
datafiles/animations/GameMenu.anims

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Re: Animation problem #2

Postby Nickenstein79 » Wed Jul 16, 2014 19:23

For the attention of Kulik, Ident & Timootei.

OK, I have found a MUCH better way to fix this problem. (Without relying on a stupid duplicated interpolator class).

I have discovered the actual reason that a proper working TplLinearInterpolator::interpolateRelativeMultiply template could never be fully compiled against all the object types that use that template.

Basically: objects like Colour, ColourRect, UBox, had operator overloads for (Object * T), but they didn't have them for (Object * Object). This was confusing the hell out of the compiler when building the interpolator templates, which in turn is obviously why the original version of interpolateRelativeMultiply has been hard-coded to only actually work with singular floats (and never actually worked for higher types like UDims, UBox, Colour, ColourRect, Vector3fs, etc...)

I have rectified this by adding in the needed (Object * Object) overloads into the required object classes.

This has in-turn allowed me to remove the need for a duplicated TplLinearInterpolator method to house my interpolation fix.
So my fix is now inside the original TplLinearInterpolator method where it should be.

Testing everything now (on both my game and the CEGUIGameMenu demo) before doing a new pull request.


EDIT:

Pull request updated: https://bitbucket.org/cegui/cegui/pull-request/89/much-better-fix-for-issue-1036/diff

(Also, I've changed my VS tab-settings to stop my pull-request from being full of white space and tabs.)

User avatar
thomas
Quite a regular
Quite a regular
Posts: 64
Joined: Thu Aug 22, 2013 22:11

Re: Animation problem #2

Postby thomas » Thu Jul 17, 2014 14:27

Sounds like a sweet fix you got there, good job on solving it and improving your solution :pint:

Never thought about this animation stuff really, might have to give it a try. Thanks!

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Re: Animation problem #2

Postby Nickenstein79 » Wed Jul 23, 2014 06:53

I hate bumping threads, but it's been almost a week since I replied to Martin's comments on my pull request - https://bitbucket.org/cegui/cegui/pull-request/89/much-better-fix-for-issue-1036/diff

If you aren't seeing that update, I will reiterate it here:

Should I instead revert the pull-request to the default branch instead of the stable v0-8 branch?
Your reason for rejection was that people could have data-files that rely on the current (broken/unfinished) RelativeMultiply-Interpolation template that can only handle singular float interpolants.

I keenly await your feedback on this before I do anything else.

But the main point here is that the existing version of interpolateRelativeMultiply has been hacked/fudged to cast everything to floats, simply because the interpolator template was incompatible with the Widget-Object types in use.
That incompatibility between the widget-objects and the interpolator-template is what I have fixed, in order to make the interpolator template compatible with ALL CEGUI-types.

For example the current Vector3 class in CEGUI doesn't actually have a Vector3*Vector3 operator overload. This is one of the things that I rectified in order to make ALL widgets compatible with the interpolateRelativeMultiply template.
(Similar TYPE*TYPE operator overloads missing from the current CEGUI codebase is the actual root-cause for this type-vs-template clash with the interpolator templates. This is why I added them in my pull-request, as they allow all CEGUI-widget-classes to be fully compatible with all interpolation templates. The 'meat' of my pull request is these additions.)


As a side-note: Since adding this fix locally I have been using RelativeMultiply-Interpolation extensively for window-scale/position/rotation anims and relative-colour-blend anims. It looks ACE!
I'll be making a video of it soon. ;)

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Animation problem #2

Postby Kulik » Wed Jul 23, 2014 08:20

Hi,

I don't have much time during work days but I hope to have a look at this during this weekend. Before we merge this I want to have unit tests in place to ensure we don't break any documented behavior. Sorry for the delays, sometimes the best and most complex pull requests take a much longer time than simple ones.

User avatar
Nickenstein79
Quite a regular
Quite a regular
Posts: 93
Joined: Thu May 09, 2013 06:19

Re: Animation problem #2

Postby Nickenstein79 » Wed Jul 23, 2014 21:52

No worries, fella. :)

I just wasn't sure if people were actually getting notifications when I added comments on the pull.

User avatar
Ident
CEGUI Team
Posts: 1998
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: Animation problem #2

Postby Ident » Tue Jul 29, 2014 19:30

Martin has since replied to your PR, 2 days ago, in case you didn't get a notification for it.
CrazyEddie: "I don't like GUIs"


Return to “Help”

Who is online

Users browsing this forum: No registered users and 17 guests