Hi,
I am missing some… understanding about animations:I am trying to animate playing cards.
When my card game starts, the player gets 9 cards, and I would like to animate them nicely, as his “hand” would open in front of him, so the cards should be animated around a path defined by a portion of circle, first one nearly moving, second one a bit further, middle one (5th) vertical, last having the longest animation.
Animations are both transitions, that I managed to figure out looking at some example, each keyframes being calculated by trigonometry and a rotation, at least around z axis first, to have the card nicely oriented and this is where I am struggling… here is for an idea of the look and feel www.hubris.ch/chibre2020/anim5.html
What I am not understanding: I am building the path of the translation based on a fixed number of keyframes, specifying a value for each keyframe, because this cannot be interpolated, but regarding the rotation, why can’t I just specify starting angle for frame 0 and final angle for frame “number of keyframe” ? Shouldn’t it sync with the translation ? Instead of doing the 90 degreees I wanted it does a crazy load of full turn…
Is animating mesh.rotation.z impacting the actual roation.z propriety of the mesh or it is about increasing it continuously ? not sure that makes sense, but … yup I am confused-> help !
tl;dr Try replacing lines 79 and 83 with the following code; is that the behavior you’re intending?
value: 2*aMaxR / numberOfKeyframes
I think your issue might be coming from the rotation keyframes wanting a value delta, not a value target. So, when you tell it your first keyframe has value a and your last keyframe has value b, it seems to be auto-generating intermediate keyframes with values interpolating from a to b. However, because each keyframe has a delta, not a target, it’s actually evaluating that as, “Perform this entire rotation by the time you get to your next keyframe.” Giving it a constant amount of rotation to do per frame causes it to essentially interpolate its rotation across the entire space. Does that work?
(Disclaimer: I haven’t chased this down in the source, I’m just evaluating what it seems to be doing from what I could find fiddling with your Playground, so please take what I’m saying with a healthy sprinkling of salt. Especially if it doesn’t work. )
To do this, though, I needed to treat the keyframes as targets, not deltas, as I had previously thought. I haven’t fully parsed through your Playground to understand why that is, but the targets theory matches more closely with what I would expect from reading Animations - Babylon.js Documentation.
Calling in @PatrickRyan for backup, to help make sure I’m not giving you misinformation.
Thanks! This is exactly what I am trying to achieve, and behaving how I originally thought it would… I am even thinking I gave a try to that solution, wrongly lol, so, I’ll continue from your playground, yeepee!!
I’ll post soon what I managed to do with your help, but just for the anecdote, the line that was producing the crazy result was line 176 : “card.rotationQuaternion = xQuaternion;”, replacing it by card.rotation.x = … correct it
so, here is where I am now, trying to find the best tricks to have a nice and logical display where cards are not cutting each others http://www.hubris.ch/chibre2020/anim21.html
if you are changing Z-direction in your animation, then you perhaps want to have different “tracks” with the z-offset of the final spot. That is one way to prevent the cards to pass through each other.
Yes, I have to experiment, but I know already that a combination of the current parameters won’t be enough… a good shape would look like something like that Title
But in reality the top card should stay on top during the opening / animation, and yes cardboard should not be penetrated but bend instead hehe
I tried to play with some increment on the Z axis, but this is no more mathematics… more black magic
I isolated the code in this playground https://www.babylonjs-playground.com/#AC01D8#1 and I am open to any suggestion
The way cards are on top of each other kind of work, but the deck is no more balanced
Btw @brianzinn reading your answer for the 4th time I think I understand just now that you weren’t suggesting to “play” with a Z-Axis increment but actually to create different anims / tracks for each card, right ?
If you are just fanning the cards open, you can get away with just a z-offset. You are dealing with z-fighting. When you are moving the cards and change z-direction of movement then they would pass through each other and the simplest way (probably not best) is to adjust the “tracks” by maximum z-difference. Cool playground you made - here is with small z-offset: https://www.babylonjs-playground.com/#AC01D8#2