I made a ragdoll similar to the one in this demo. This rag doll will be used for a turn based rpg game where the physics will be used for animations such as character taking damage, dying, falling down, etc.
What I am pondering at the moment is as how should go about this, should I stick the rag doll by the head to the background (leaving the body dangling) and basically throw around its body parts around as to simulate punching etc (as shown in Fig 1), or stiffen the joints and statically rotate and move the body parts for the actions taken(as shown in Fig 2), and when it comes to the character dying(or a similar action) just loosen the joints and let the rag doll fall down. Or is there a better way to go about doing this?
I am new to farseer physics and don't even know if what I mentioned is even possible or overwhelmingly hard to do.
Illustration http://img3.imageshack.us/img3/8681/charactermovementrg5.jpg
Please note that the red line in the figures represents the character's arm
Not sure that ragdolls are the way to go here, if you want animations. But if you do want to use them, I'd lock the feet to the floor and have some rotation springs in the joints so that when no forces are applied, the body stands upright. Then if it gets a hit, it'll kind of bend over, but should rebound to it's stand-up state afterwards (you may have to help it along the way back, e.g. apply some forces/torques until it's back where you want it).
For animations, such as the character punching, you could perhaps apply a spring joint (I think that's the name). Connect it to the fist and the destination, and the arm should automatically move there. You could do the same with a kick, just release the lock on that foot. However, I think it might be hard to get it to look right. On the other hand, it would look unique to other games, even though it might look kinda funny.
If you're skilled, you might wanna create an animation editor and save an animation as a sequence of forces and torques that need to be applied to limbs in order to get them to where and when they should be.
I think a better approach is to have an animated sprite played, rather than going through joint manipulation .
Maybe you can use some RotateTransform implementations to articulate arms and legs.
For sure animated sprites are the best, and painless, way of doing this.
Related
Is there a way to change the clutter perspective for a given container or widget?
The clutter perspective controls how all the clutter actors on the screen are displayed when rotated, translated, scaled, etc.
What I would really like to do is to change the perspective's origin from the center of the screen to another coordinate.
I have messed with a few of the stage methods. However, I haven't had much luck understanding some of the results, and often I hit some stability issues.
I know there are transformation matrices that do all the logic under the hood, and there are documented ways to change the transform matrices. Honestly, I haven't researched much further and just though I would ask for guidance before spending a lot of time on it.
Which leads me to another question regarding the matrices and transformations. Can one of these matrices be used to skew an actor? Or deform it into a trapezoid, etc? And any idea how to get started on that, ie. what a skew matrix would look like?
Finally, does anyone know why the clip path was deprecated? It seems that would have worked for what I ultimately want to do: draw irregular shaped 2d objects on the screen If I can implement an answer to question 2, then I guess a clip box with a transformation can be used here.
1, I do not know if (or how) one might change the Clutter stage's focal point.
2 A skew or shear transformation matrix is easy enough to construct, and can be implemented in the GJS Clutter functions Clutter.Actor.set_transform(T) and Clutter.Actor.set_child_transform(T) where T is a Clutter.Matrix .
This does present another problem, however, for the current codebase; and this leads to another question. (I guess I should post it somewhere else). But, when a transform is set on a clutter actor (or its children), the rest of the actor's properties are ignored. This has the added effect that the Tweener library cannot be used for animation of these properties.
3 Finally, one can use Cairo to draw irregular shaped objects and paths on a Clutter actor, however, the reactive area for the actor (ie. mouse-enter and -leave events) will still be for the entire actor, not defined by the Cairo path.
I am working on a simple soccer simulation, I am using potential fields for collision avoidance more specifically following technique,
http://www.ibm.com/developerworks/java/library/j-antigrav/
only obstacles on the field are other players and they are constantly moving. Problem is it works if I assign really big push force to the characters since characters move at speed it takes some time to change direction but this has few drawbacks with such a high gravity I can never position an npc to grab the ball cause there is always some force pushing me around.
I though I could solve this by assigning pulling force to the ball but that actually made it worse. nps would go to the ball, ball starts pulling which makes npc push the ball it goes into a loop until npc crashes to a wall.
How I've implemented this is, I have a vector that would steer me towards my target then I add to that all gravitational forces acting on the npc and steer towards that direction.
Basically I am wondering what kind of improvements I can make? my current problem is not hitting other players precisely getting behind a ball without getting affected by other players.
I'm not sure that employing potential fields is the way to go here. If all players are directly between you and the ball, how do you get to it?
I'd be tempted to plot a straight line, then iteratively adjust the route for the position of other players, adjusting for their trajectories and — if you're really clever — anticipating changes in the same.
You could put some kind of limit as to the area of effect that another player's gravity well will have. Limit it to a small radius around that player so that when you're clear of other players, there are no forces acting on your character. You could also diminish the collision avoidance force when you're near the ball, reasoning that players care less about not hitting each other when it's time to kick the ball.
I have a sequence of images taken from a camera. The images consists of hand and surroundings. I need to remove everything except the hand.
I am new to Image processing. Would anyone help me in regard with the above Question. I am comfortable using C and Matlab.
A really simple approach if you have a stationary background and a moving hand (and quite a few images!) is simply to take the average of the set of images away from each image. If nothing else, it's a gentle introduction to Matlab.
The name of the problem you are trying to solve is "Image Segmentation". The Wikipedia page here: wiki is a good start.
If lighting consistency isn't a problem for you, I'd suggest starting with simple RGB thresholding and see how far that gets you before trying anything more complicated.
Have a look at OpenCV, a FOSS library for computer vision applications. Specifically, see the Video Surveillance module. For a walk through of background subtraction in MATLAB, see this EETimes article.
Can you specify what kind of images you have. Is the background moving or static? For a static background it is a bit straightforward. You simply need to subtract the incoming image from the background image. You can use some morphological operations to make it look better. They all depend on the quality of images that you have. If you have moving background I would suggest you go for color based segmentation. Convert the image to YCbCr then threshold appropriately. I know there are some papers available on it(However I dont have time to locate them). I suggest reading them first. Here is one link which might help you. Read the skin segmentation part.
http://www.stanford.edu/class/ee368/Project_03/Project/reports/ee368group08.pdf
background subtraction is simple to implement (estimate background as average of all frames, then subtract each frame from background and threshold resulting absolute difference) but unfortunately only works well if 1. camera has manual gain and exposure 2. lighting conditions do not change 3.background is stationary. 4. the background is visible for much longer than the foreground.
given your description i assume these are not the case - so what you can use - as already pointed out - is colour as a means of segmenting foreground from background. as it's a hand you are trying to isolate best bet is to learn the hand colour. opencv provides some means of doing this. if you want to do this yourself you just get the colour of some of the hand pixels (you would need to specify this manually for at least one frame) and convert them to HUE (which encapsulates the colour in a brightness independen way. skin colour has a very constant hue) and then make a HUE histogram. compare this to the rest of the pixels and then decided if the hue is simmilar enough.
I have a WPF application with many tabs..
in one tab.. i make a verycomplex vector drawing consisting of thousands of drawing visuals.. (this represents a machine and all elements need to be interactable..)
It takes 3/4 seconds for drawing this for the first time..After the first draw it should be done..
The problem is if i switch to another tab and comeback, it takes atlease 2,3 seconds to show the tabpage with drawing again.. Since there is no redraw, why should it take so much time..?
If the component is not going to change, you could call Freeze() on it to mark it as done. Without trying it out I don't know if that would help, but you could give it a shot.
Not all objects are Freezable. Check out the MSDN documentation for more info:
http://msdn.microsoft.com/en-us/library/ms750509.aspx
Another thing you could try would be rendering the vector art to a bitmap, and displaying that. Maybe it makes you feel icky to lose the vector precision, but if you know it's not going to change and it will look the same, what's the harm? (If you support printing or something that will require a hi-res version, you could always switch back for that operation.) For info on how to convert a UIElement to a bitmap, check out:
http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.rendertargetbitmap.aspx
Another possible solution: You don't really explain what kind of interaction you are doing with the elements, but if all you want to do is zoom and pan, a RenderTransform may be good enough (which is more efficient than a LayoutTransform and/or moving all the elements individually). I haven't played around with combining Freeze() and a RenderTransform, but you may be able to get the desired zooming while reducing the amount of layout WPF has to do.
I am new to Silverlight and want to animate a ball that is shot out of a cannon then moves through the air under the laws of physics (so roughly, on an elliptical path).
My inclination is to use a callback timer and move the little ball every 50ms by changing its Canvas.LeftProperty and Canvas.TopProperty values. Is this the right approach or should I be using a DoubleAnimation? My resistance to using animations here is that I would have to create many different animation in succession.
Which path would a Silverlight guru take?
Have a look at a question I asked some time ago here the accepted answer gives a comparison of five different ways to do animation for games in silverlight linking to this blog. The article concludes that the method you choose will depend on a number of factors.
To answer you question I personally would use the dispatcher timer which is fired each time the screen re-draws and set the properties then to move the X and Y.
I also found Game Physics 101 a really good resource.
Might be a little overkill bit are you aware of the physics helper libraray
I don't think you would have to create several animations in succession. The ball only changes direction once.
The Y value goes down (making the ball look like it's going up) and then goes up (making the ball look like it's going down). The deceleration as it's going down should be constant (something representing 9.8 m/s/s) and the acceleration as the Y value goes up (cannonball goes down) is constant, until it hits the point representing the ground.
The X value should be constant, or else decelerate slightly should air resistance be taken into account.
Therefore, you would work out the following:
Where does it start (the cannon,
obviously)
Where does the ball hit it's vertical peak
Where does the ball hit the ground
So now you can animate the Y value as a start value, and end value and one waypoint.
And you can animate the X value with just a start and an end.
Of course, it's going to involve non-trivial mathematics to determine the exact numbers to enter into the AccelerationRatio, DecelerationRatio, SpeedRatio, Duration, From and To parameters. But you would have to work that out no matter what method you're using.