I have a GSAP (Greensock) animation that is "seemless," meaning that when it is played on an infinite loop you can't tell which part is the beginning, and which is the end.
Let's say I have two labels, one near the start (about 10% of the way in) and another near the end (around 90% completed):
| start end |
|----|----|----|----|----|----|----|----|----|
If I create a tweenTo from 'start' to 'end', it'll go "the long ways", scrubbing the playhead forward from 10% over to 90%.
Tween from 'start' to 'end' would go
"long ways" from the left to the right
:==================================>
| start end |
|----|----|----|----|----|----|----|----|----|
So far so good, this makes sense to me.
But what if I don't want that to happen? Since my animation is seemless, technically the animation could start at 10% and go backwards until it reaches the beginning, then loops around to the end of the animation and continues in reverse until it reaches the 'end' label at 90%.
But what if I wanted to go "backwards" from
'start' and loop around to 'end'?
/====: <====/
| start end |
|----|----|----|----|----|----|----|----|----|
This would be the "short way" between those two labels.
My question is, how would I go about creating an effect like this?
That is, if I have two labels, is it possible to animate between them where my animation "wraps around" the timeline instead of staying contained within the timeline?
See the following codepen for an example of this - https://codepen.io/romellem/pen/yQOQar?editors=0010
Within that codepen, on the left is the issue I'm facing, and on the right is a faked" example that shows what I want the animation on the left to do when tweening "around" my two labels.
Related
I frequently get myself into trouble when I've put together a complex animation in Maya with lots of rigs and connections and animated attributes and then find that I need to insert 100 frames somewhere in my 5000 frame animation to make space for additional animation. In the past, I've struggled with selecting all objects and all of their keyframes to move them down the timeline as it seems that I always miss some attributes that don't get moved and then things get ugly and I waste a lot of time fixing things.
I feel like there must be a more elegant way to insert a certain number of frames into the timeline easily without worrying that some keyframes will be left behind. I've tried my luck with the dope sheet, but I don't really find it any easier to use than the graph editor.
"Elegant" in this case is in the eye of the beholder.
Effectively what you need to do is move all the keys after a given point by a given amount. The hard part is that moving the keys will change the meaning of the curves: the interpolation is going to change no matter what you do unless you've got locked tangents on both sides of the change.
if you just want to insert keys at a particular point in time, it'll look like this:
def move_keys_after(start, time_shift):
key_string = '%s:' % start
for curve in cmds.ls(type='animCurve'):
before = cmds.keyframe(curve, q=True)
cmds.keyframe(curve, r = True, tc = time_shift, t = (key_string,), iub=True)
after = cmds.keyframe(curve, q=True)
print curve, before, "->", after
move_keys_after( 10, 20)
That example moves all of the keys in the scene after time start by time_shift frames. If you want to limit this to an object you could get the anim curves from the object directly or use the animation flag of the keyframe command
I'm using the 3rd person blueprint template and I've added a custom sprint and custom crouch functionality to it.. when crouching I trigger the crouching animations according to the character speed and set the max walk speed to a low value, I can interrupt the crouch by sprinting and vice versa... I can stand up from the crouch by pressing the crouch key again or attempting to jump.
It all worked quite well, until I attempted to manipulate the capsule collider's half height according to the character's speed whenever crouch, jump, or sprint is pressed... I can see the collider working as expected, however when I try to crouch the character's feet sink into the ground and when I try to stand up again the character falls through the floor...
Any help would be greatly appreciated...
The problem is that just shrinking the half-height is probably not what you want when your character is crouching, because your collision capsule is shrinking from the top and the bottom.
So, the feet of your character start to sink into the ground and when you grow your capsule it will clip through your level and fall down due to gravity.
You have two possibilities to fix this:
Use two capsules on your character, one for crouching and one for standing and only activate the one you are using
Move the capsule down the same time you are shinking it.
The capsule needs to finish at the same point, so move it lower.
I am making a game and i have come across a hard part to implement into code. My game is a tile-bases platformer with lots of enemies chasing you. basically, in theory, I want my enemies to be able to, every frame/second/2 seconds, find the realistic, and shortest path to my player. I originally thought of A-star as a solution, but it leads the enemies to paths that defy gravity, which is not good. Also, multiple enemies will be using it every second to get the latest path, and then walk the first few tiles of it. So they will be discarding the rest of the path every second, and just following the first few tiles of it. I know this seems like a lot, to calculate a new path every second, all at the same time, if their is more than one enemy, but I don't know any other way to achieve what i want.
This is a picture of what I want:
Explanation: The green figure is the player, the red one is an enemy. the grey tiles are regular, open, nothing there tiles, the brown tiles being ones that you can stand on. And finally the highlighted yellow tiles represents the path that i want my enemy to be able to find, in order to realistically get to the player.
SO, the question is: What realistic path-finding algorithm can i use to acquire this? While keeping it fast?
EDIT*
I updated the picture to represent the most complicated map that their could be. this map represents what the player of my game actually sees, they just use WASD and can move around and they see themselves move through this 2d plat-former view. Their will be different types of enemies, all with different speeds and jump heights. but all will have enough jump height and speed to make the jumps in this map, and maneuver through it. The maps are generated by simply reading an XML file that has the level data in it. the data is then parsed and different types of tiles are placed in the tile holding sprite, acording to what the XML says. EX( XML node: (type="reg" graphic="grass2" x="5" y="7") and so the x and y are multiplied by the constant gridSize (like 30 or something) and they are placed down accordingly. The enemies get their frame-by-frame instruction from an AI class attached to them. This class is responsible for producing this path and return the first direction to the enemy, this should only happen every second or so, so that the enemies don't follow a old, wrong path. Please let me know if you understand my concept, and you have some thought/ideas or maybe even the answer that i'm looking for.
ALSO: the physics in this game is separate from the pathfinding, they work just fine, using a AABB vs AABB concept (the player and enemies also being AABBs).
The trick with using A* here is how you link tiles together to form available paths. Take for example the first gap the red player would need to cross. The 'link' to the next platform (aka brown tile to the left) is actually a jump action, not a move action. Additionally, it's up to you to determine how the nodes connect together; I'd add a heavy penalty when moving from a gray tile over a brown tile to a gray tile with nothing underneath just for starters (without discouraging jumps that open a shortcut).
There are two routes I see personally: running a quick prediction of how far the player can jump and where they'd jump and adjusting how the algorithm determines node adjacency or accept the path and determine when parts of the path "hang" in the air (no brown tile immediately below) and animate the enemy 'jumping' to the next part of the path. The trick is handling things when the enemy may pass through brown tiles in the even the path isn't a parabola.
I am not versed in either solution; just something I've thought about.
You need to give us the most complicated case of map, player and enemy behaviour (including jumping up and across speed) that you are going to either automatically create or manually create so we can give relevant advice. The given map is so simple, put the map in an 2-dimensional array and then the initial player location as an element of that map and then first test whether lower number column on the same row is occupied by brown if not put player there and repeat until false then same row higher column and so on to move enemy.
Update: from my reading of the stage generation- its sometime you create- not semi-random.
My suggestion is the enemy creates clones of itself with its same AI but invisible and each clone starts going in different direction jump up/left/right/jump diagonal right/left and every time it succeeds it creates a new clone- basically a genetic algorithm. From the map it seems an enemy never need to evaluate one path over another just one way fails to get closer to the player's initial position and other doesn't.
I've been trying D3 for a day or two now. So I'm a D3 newbie but have lots of C/C++, Java, PHP, Javascript, etc background.
I started from the tutorials page github.com/mbostock/d3/wiki/Tutorials, and went fairly meticulously through
- Introduction
- Three Little Circles
- Thinking with Joins
- How Selections Work
first trying examples verbatim, sometimes trying different changes to see if I understand the results.
I then jumped to A Bar Chart, Part 1, and Part 2.
I ended up with results pretty much exactly as expected by the end of Part 2. The tutorial only has code fragments and I don't see a spot in the tutorial where it says "here is the full finished result you should end up with", nonetheless I end up with this http://jsbin.com/oqetuw/2/edit and it looks to be working identically to the tutorial.
Note for those who haven't tried this tutorial, the key points I'm asking about are the redraw interval, 1500 ms, the transition duration, 1000 ms, and the transition ease function, which the tutorial doesn't use or specify, but I've googled to find that it defaults to cubic-in-out.
As my goal is for a continuous smooth scrolling across the screen, I changed the redraw interval to 1000, and the transition ease function to "linear", and the result is here http://jsbin.com/ijumuv/1/edit
And these are the only changes as shown here:
$ diff tut2.09.html tut2.10.html
33c33
< }, 1500);
---
> }, 1000);
78a79
> .ease("linear")
82a84
> .ease("linear")
86a89
> .ease("linear")
The strange behaviour, and thus the question is, why do occasionally the bars that reach the left edge seem to bounce back and accumulate from left to right, behind the main bars? (and also occasionally get cleared)
Undoing only the 1500 -> 1000 change, the problem seems never to happen (so it is scrolling every 1.5 s, with each scroll duration being 1 s). So it would seem maybe if D3 is busy still doing the transition, it fails to remove them? or some other explanation I can't figure yet.
Thanks in advance for any tips.
Yeah, there are issues with d3 transitions. When the interval and duration are both 1000, there is high chance for the redraw operations to occur before the prior transition() on that selection is finished. And that messes with the data binding, or something along those lines.
I modified your code such that it continuously checks whether the previous redraw transition has finished before calling the next one. This is by no means "good javascript", but it does illustrate the issue, and some way around it. To understand what I added, just look for all occurrences of __readyForNext in the code. It should make sense.
I'm doing some animation script in RPG Maker XP (made with ruby) that allow you to display moving images. My question here is not strictly about RPG Maker, but in general term. This is the code I found out so far and it works, but with problem :
class Poser
attr_accessor :images
def initialize
#images = Sprite.new
#images.bitmap = RPG::Cache.picture('Character.png') #display picture
#images.x = 540 #place it on the bottom right corner of the screen
#images.y = 180
end
def move(x,y)
#images.x += x
#images.y += y
end
def animate(x,y,step,delay) #Animate moving the picture up and down with delay
forward = true
2.times { #the first loop, do code 2 times of :
step.times {
wait(delay) #wait x frame
if forward
move(x/step,y/step) #move the picture down
else
move(-x/step,-y/step) #move the picture up
end
}
wait(delay*3)
forward = false
}
end
def wait(time)
while time > 0
time -= 1
Graphics.update
end
end
end
Then I create an instance of it and called the method :
$test = Poser.new
$test.animate(0,10,10,10)
What the above code do is to move the picture up and down (just like breathing animation, your head bob up and down)
As you can see, Im using loop functions to move the picture with delay. What I got is, I cannot do anything else until the animation finished. What I meant by "anything else" is such as walking around with my character, talk to NPC, I want to do those things while there is animation being played in the background. In the end, the game "paused" in the loop block.
Is there is another way to do animation without looping, or, anything that doesn't "pause" the screen until animation is finished ? Thanks in advance.
Usually, games use a system called a game loop. A game loop is a loop in the main function of the program that executes as fast as it can. Each time it executes, it executes two functions (or these can be the body of the loop, that's a design choice that you can make): draw and update (update, then draw).
update's job is to change the positions of characters, usually by a formula of position=(x+pixelsPerSecond*secondsSinceLastTick,y+pixelsPerSecond*secondsSinceLastTick) (in game terminology, a tick is an iteration of the game loop). The system of a game loop is optimized for games, because every tick you can execute one tiny piece of each animation, fast enough together that they give an illusion of concurrency (game loops run many times per second).
After update has changed the position of entire objects (eg. a fast NPC is now 5 pixels further to the left), draw is used to draw the scene. draw can do a couple of things. It can draw sprites at the locations indicated by update, and it can also maintain it's own animations (small things like the animation of legs walking -- update shouldn't set the position of the legs in the walking animation, just the new position of the character for this tick).
I'm not sure if I am exactly answering your question, as I know nothing about RPG Maker (so maybe you have to do something else completely), but because you said in general, this is what it is.