How to animate Position in SpriteBuilder's timeline? - spritebuilder

The only property I can seem to animate in SpriteBuilder 1.0.4 is Rotation. Is there a way to animation the other properties on the Timeline, such as Position?
Edit
Okay, I'm an idiot. I did a tutorial where it said press "R" to add a keyframe. This only adds a rotation keyframe. Option clicking on the Position timeline adds a keyframe to the position timeline.

You can either Option + click on the timeline you want to add keyframes or you can use the built in keyboard shortcuts:
Visibility - V
Position - P
Scale - S
Rotation - R
Skew - K
Sprite Frame - F
Opacity - O
Color - C
Double clicking on the actual keyframe will bring up the attributes it controls, their current values, and allow you to edit them.

Related

Different animation times for transform parameters

I'm writing a "3D navigation" where moving the mouse cursor subtlely rotates the contents of the screen. When something is clicked I want it to zoom (scale).
The rotation is achieved with transform property, and evoked when the cursor moves. This part works fine!
Now I want the scale to be animated at 500ms. But if I set this transition speed, it wrecks the nice smoothness of the cursor move property.
I tried solving with JavaScirpt, but the problem is that if I start working the "scale" segment alone, it overwrites the rotation property. CSS doesn't remember that I've set the rotation at some point, if I set transform again, during animation, with only the scale.
I have a work-around, but I don't think it's very nice and I suspect it will difficult to understand and refactor it in the future.
So like I can separate the timing for "background" and "color", is there a way to "go deeper", and also separate for the different transform properties?
Thanks in advance!

How to find out the image points of transit image in javafx

We are developing a small game of dropping images. We need to find the image X and Y points without an Event like mouseClick() event etc.
Please Help me to find out Points of Moving Image. i.e Points of Transit Image.
We have applied pathtransition on image.
Read the docs.
"This Transition creates a path animation that spans its duration. The
translation along the path is done by updating the translateX and
translateY variables of the node"
Just register a listener with the translateX and translateY properties of the Node you are animating. You can use the boundsInParent property to find its coordinates, including translations, relative to the parent.

Trying to zoom image based on mouse origin, yet my math is slightly off

I'm working on a full screen image viewer, I'll temporarily open a dev URL here:
http://www.jungledragon.org/apps/jd3/image/704/great_grey_owl.html/zoom
This viewer is responsive and scales to your browser width/height. One of its key features is being able to zoom in and out of the image using your mouse wheel. Rather than a center-based zoom, the idea is to zoom based on origin, meaning the coordinates of your mouse, allowing you to zoom into specific areas of the image.
How to reproduce the issue
If you open the above URL and have a quick play with your mouse wheel, it may appear to be working correctly. However, the math I am using is slightly off. Here is how you can reproduce the issue:
Open the above URL
Hover your mouse over the left eye of the Owl
Zoom one step using your mouse wheel, it should zoom exactly into the eye
Position your mouse on the owl's beak
Zoom one more step using your mouse wheel
You should now notice that the second zoom step did not go into the Owl's beak exactly, it seems to be slightly off, both horizontally and vertically. I'm thinking this is a result of bad math.
How it works
Here is the javascript that handles it all:
http://www.jungledragon.org/apps/jd3/js/jd3-slideshow.js
I am capturing the mousewheel event. Based upon its direction, I am increasing or decreasing the zoom level. The actual zooming is nothing more than applying a CSS class that scales the image using a CSS3 transform:
&.grow1 { #include jd-scale(1); }
&.grow2 { #include jd-scale(1.5); }
&.grow3 { #include jd-scale(2.0); }
&.grow4 { #include jd-scale(2.5); }
&.grow5 { #include jd-scale(3.0); }
Note: the above is a call to a SASS mixin that translates into the right vendor prefixes for transform:scale.
The above accomplishes the basic zooming without issues. To make origin-based zooming possible, however, a few more steps are needed. Upon doing the actual zooming, I first set the origin of the zoom in javascript, using transform-origin. Here is my helper function for setting it:
function zoomOrigin(selector, originStr) {
selector.css({'-webkit-transform-origin': originStr});
selector.css({'-moz-transform-origin': originStr});
selector.css({'-ms-transform-origin': originStr});
selector.css({'-o-transform-origin': originStr});
selector.css({'transform-origin': originStr});
}
The heart of this question is about calculating the correct origin. There are two things worthy to mention in calculating this value:
The absolute coordinates (meaning the X and Y) are relative to the image, not relative to the page
The calculation of the origin should take into account that the image has grown/shrunk based on the current zoom state
The origin calculation happens in realtime, based on the mousemove event. Here is the method that does so, with irrelevant parts removed:
$("#image-container img").mousemove(function(e) {
// user has moved their mouse. in case of zooming or panning, this means that the
// origin (center point) of those interactions need to be recalculated
// calculate the mouse offset within the zoomable object (which is different than the page-level offset)
// this relies on the parent of the element having position:relative set
var parentOffset = $(this).offset();
zoomOriginX = e.pageX - parentOffset.left;
zoomOriginY = e.pageY - parentOffset.top;
// recalculate the width and height of the image given the current zoom level
width = $(this).outerWidth() + (1 + ((zoomLevelCurrent - 1)*0.5) * $(this).outerWidth());
height = $(this).outerHeight() + (1 + ((zoomLevelCurrent - 1)*0.5) * $(this).outerHeight());
// calculate origin percentages based on zoomed width and height
// the zoom methods rely on these variables to be set
zoomOriginPercX = (zoomOriginX / width * 100);
zoomOriginPercY = (zoomOriginY / height * 100);
});
The main purpose of this method is to correctly set the global variables zoomOriginPercX and zoomOriginPercY, which are used to set the origin (percentage) prior to zooming.
From a math perspective, my idea was to simply calculate the zoomed width of the image, and to use the offset X and Y to come to a reliable origin percentage. As the problem statement shows, I am quite close to a correct calculation, yet something is off.
Although the zooming currently works well, I want it to be perfect. It would make for quite a powerful image viewer that is really easy to implement, also for others.
Desired Effect
To start answering your question I think it's worth first clarifying the desired effect. Essentially you're looking for the same effect you'd get if you pinched to zoom on an iPhone - the 'origin' of the pinch stays exactly the same, and everything around it stretches. You can imagine pinning some stretchy fabric at the origin, and pulling the corners.
Problem
This is working fine for you if you don't move the mouse between zooms, but if you do, the origin appears to move. The cause of the problem is exactly that - you are changing the origin of the transform every time you move the mouse. Of course you do need to do this, but you are calculating the origin based on the original (100% zoomed) position of the image. The actual origin needs to be somewhere between the origin of the first zoom and the new mouse position.
In other words, CSS is just doing one transform. If you set the origin to x,y then zoom to zoom level 2, this will give the same result as if you set the origin to x2,y2, zoom to level 1, then move to x,y, and go to level 2.
Solutions
I presume you could solve the issue in several ways:
Calculate a scaling factor for the 'new' origin on each zoom
this is likely a function of zoom level, mouse position and previous origin
Calculate and apply a translation each time the origin is moved
again will depend on the current origin, zoom level and mouse position
Find another way to 'stack' transforms on top of one another.
One way to do this may be to dynamically generate a new containing div each time you and apply a scale transform to that similar to the accepted solution in this question.
Unfortunately I don't have the time to go further than this, but hopefully it points you in the right direction?

Prevent CSS3 Animation from restarting

A lot of people need to restart their CSS3 animations; Well I want the exact opposite:
If I start an animation by adding the proper css class, the animation starts; If I then sort my container using a series of parentNode.insertBefore calls (and reusing the very same node instances), the animations restart every time.
Is there anything I can do to prevent this behavior?
Here's a fiddle showing this behavior: http://jsfiddle.net/v66G5/17/
Click on Add all, let the animation plays for a few seconds then click shuffle: Any node that moved has its animation restarted.
container.insertBefore(node, childrenClone[Math.floor(Math.random() * childrenClone.length)]);
Why manipulate DOM elements, when you can shuffle their CSS positions instead?
http://jsfiddle.net/v66G5/19/
children.each(function() {
var $node = $(this),
$node2 = $(children[Math.floor(Math.random() * children.length)]),
tmp = $node.position().top;
$node.css("top", $node2.position().top + 'px');
$node2.css("top", tmp + 'px');
});
Taking from http://dev.w3.org/csswg/css3-animations/
An animation specified on an element by modifying the style after the document has loaded will start when the style is resolved. That may be immediately in the case of a pseudo style rule such as hover, or may be when the scripting engine returns control to the browser (in the case of style applied by script).
An animation applies to an element if the element has a value for ‘animation-name’ that references a valid keyframes rule. Once an animation has started it continues until it ends or the ‘animation-name’ is removed. The values used for the keyframes and animation properties are snapshotted at the time the animation starts. Changing them during the execution of the animation has no effect
Removing and inserting nodes causes the elements to recalculate the style, so I don't think what you want is possible by simple css.
A possible way to achieve it using jQuery, would be to take a snapshot of opacity and time left till the end of animation when removing the node, and setting it back after inserting it (ie. for 10s animation, after 5s if shuffle was clicked, start from 50% opacity, with the duration of the animation at 5s)

Webkit CSS Transitioning Rotation Not Spinning

I'm having difficulty rotating an item a full 360 degrees in webkit using CSS transitions.
I've created a JS Fiddle to show what I'm trying to do: http://jsfiddle.net/russelluresti/PnTk8/2/
The transition should happen in 2 steps. First, the item should just rotate along the Y axis for a 1/2 turn. Then, once that transition is complete, it should rotate the opposite direction a full turn and scale down to 1/2 the original size. The problem I'm having is that the second transition is only scaling and not rotating, even though rotate values of rotateY(-360deg) and rotateY(0deg) should cause a full rotation.
This is just a proof-of-concept, so I'm only targeting webkit at the moment. However, I'd like to stick with transitions, and not keyframe animations. Any ideas?
In my knowledge, rotate from rotateY(-180deg) to rotateY(-360deg) would be as the same state as rotateY(0). Let's put it this way: imagine you flip a piece of paper twice in the same direction, would be totally the same state as the very beginning. As a result, the browser take it for 'no changes at all', therefore no transition upon the rotation.
another example would make this even clearer:
given deg. set to your case, rotateY(-90deg) => rotateY(-300deg) => rotateY(60deg) would work just the same, the second transition won't start. Becuz relative to the original state: rotateY(0), rotateY(-300deg) is just at the same state as rotateY(60deg).

Resources