The main player in my game is a biped linked together using b2Revolute joints. This works well for the most part, seeing as I can limit the rotation of each joint to make a somewhat realistic biped. But when a large amount of force is applied to the biped, its parts stretch appart and it looks ridiculous. Is there any way to limit the bounciness of a joint? Another problem is that each joint doesn't limit the rotation completely. This ends up in legs swinging almost 360 degrees. Is there any way to set how strict this joint is? I thought about using a b2DistanceJoint but that doesn't allow me to limit rotation.
In Box2D, impulses are calculated to move the two joined bodies so that the joint constraints are met (eg. for revolute joints the constraints are the anchor point and the angle limits). These impulses are shared between the two bodies so that the influence of their mass is taken into account.
Two bodies of equal mass will both move equally to correct the joint constraint. When the bodies have different masses, the lighter body tends to 'obey' the heavier body and move more to correct the constraint than the heavy body does, as if there was some kind of 'pecking order' among them. Problems arise when a lighter body is joined to two heavier bodies and gets 'pecked' both ways, which almost never results in the constraints of both joints being met simultaneously.
One way to avoid this is to make sure this pecking order only goes one way, eg. the torso of your biped is the heaviest body and all connected bodies get lighter as they get further from the torso. This works until he grabs something heavier than the body at the end of his arm, at which point the pecking order becomes conflicted.
My guess is that you are trying to make the biped grab something heavy and be pulled, yet not get pulled apart? You could do this by joining the heavy things together with a rope joint, which sets a maximum distance that two points can be apart. For example if he finds himself in some dire situation like hanging from the edge of a cliff with one hand, with his pet elephant hanging below him grabbed onto the other hand, you could join the cliff and the elephant together with a rope joint that is as long as the maximum distance between his hands. This would allow him to appear super strong (which he would have to be to even attempt doing this in the first place) because the pecking order goes directly from the cliff to the elephant and skips over him completely.
Related
I have a small application I have built where there are a few balls on a blank background. They all start flying through the air and use the physics I wrote to bounce accurately and have realistic collision responses. I am satisfied with how it looks except I have an issue where when my balls land directly on top of each other, the attach together and float directly up.
Here are the functions involved
https://gist.github.com/anonymous/899d6fb255a85d8f2102
Basically if the Collision function returns true, I use the ResolveCollision to change their velocities accordingly.
I believe the issue is from the slight re-positioning I do in ResolveCollision(). If they collide I bring them a frame or so backwards in location so that they are not intersecting still the next frame. However, when they are directly on top they bounce off eachother at such small bounces that eventually stepping back a frame isn't enough to unhook them.
I'm unsure if this is the problem and if it is, then what to do about it.
Any help would be awesome!
The trick is to ignore the collision if the circles are moving away from each other. This works so long as your timestep is small enough relative to their velocities (i.e. the circles can't pass through each other in a single frame).
When the circles first collide, you will adjust their velocity vectors so their relative velocity vector pushes them apart (because a collision will do that). After that, any further collisions are spurious because the circles will be moving apart, and will eventually separate completely. So, just ignore collisions between objects that are moving apart, and you should be fine.
(I've implemented such an algorithm in a 3D screensaver I wrote, but the algorithm is entirely dimension-agnostic and so would work fine for 2D circles).
I'm working on a Minecraft like game for educational purposes. The rendering is great so far even with 1024x1204 blocks but now that I started integrating the player collision I'm having problems.
I have a aabb for the player and aabb's for all the blocks around him. These are created dynamically and it works out pretty fast.
My problem goes as following:
I have speed vector and the current position. For each axis I calculate the potential position and make out an aabb. I check for collisions and it's free I move there otherwise I set the speed for that component to 0. I separate the axis since I want my player to slide in a direction of partially facing a wall.
The order for the axis is y,x,z. The collision response is great but I'm having some problems with the corners as it sometimes get's stuck in the world without being able to move. Not sure what the reason is for this.
I do not want to implement actual physics since those are more demanding and basically just too much for what I need.
Do you guys have any suggestions on how to implement this in a nice way? I did some searching but I didn't find anything useful for this particular situation.
This is a bit abstract in a sense that the cause of your problem can be related to many things. From the top of my head, maybe a bug in your collision detection code: somehow it allows the objects to cross boundaries by 1 (or more) unit. So when the next collision is computed 1 or more dimension is stuck (imagine having an arm already inside the wall when collision is detected. You can't get your arm out because it collide with the interior of the wall boundary)
I'm trying to develop a game where cars move along roads and stop according to the signal of the traffic lights. They've got different velocities. Sometimes cars need to decelerate in order to not hit the leading car. They need to stop at the red lights. They have to make turns and etc. This is all relatively easy when working with straight intersecting roads. But how can I move a car/cars along a curved path? So far it was easy because I was just using either x or y of a car's position. But this time it's not the case, both coordinates seem to be necessary for moving it ahead. With straight roads I can just give a car an arbitrary speed and it will move along x or y axis with that speed. But how can I determine the velocity, if both coordinates have to be taken into account? Acceleration and decelerations are also mistery to me in this case. Thanks ahead.
Although this is about moving a train over a freeform track, the same issues and principles apply to cars moving across freeform roads. Actually, cars may be easier because they don't need to stick to their track 100% accurately.
In short: it's not easy, but doable. How hard it is going to be depends on how realistic you want your cars to look and finding corners to cut.
In your case the cars should simply follow a path (series of points). Since CCActions are bad for frequent direction/velocity changes, you should use your own system of detecting path points and heading to the next. Movement along a bezier curve is not going to have your cards move at constant speed, that rules out the CCBezier* actions.
One of the powerups in my game is a vortex that attracts all coins. I know I have any cocos2d's moveto/bezierto methods available, but I don't know how to make them have tangential and radial speed.
The extra difficulty is that the vortex center can change in every step, so all movement has to be readjusted.
One way to achieve this without a physics engine is to use the rotation around point algorithm.
That covers the rotation around the vortex center. Once an object is rotation around the vortex, all you need to do is to reduce that object's distance from the center by a certain amount every frame. That way it will continue to move inwards.
The only tricky part then is to get the object from its initial position being "sucked into" the vortex. There's going to be a lot of tweaking needed. With a physics engine, that part would come natural from the physics itself and it would always look right.
This is not guaranteed for the manual solution and definitely not for actions, which aren't designed to track moving targets. For example, if you change a move action every frame by replacing the existing one with a new one, your object won't move at all. Every time you do that, there's a 1-frame delay before the new action does its work.
For Operating Systems class I'm going to write a scheduling simulator entitled "Jurrasic Park".
The ultimate goal is for me to have a series of cars following a set path and passengers waiting in line at a set location for those cars to return to so they can be picked up and be taken on the tour. This will be a simple 2d, top-down view of the track and the cars moving along it.
While I can code this easily without having to visually display anything I'm not quite sure what the best way would be to implement a car moving along a fixed track.
To start out, I'm going to simply use OpenGL to draw my cars as rectangles but I'm still a little confused about how to approach updating the car's position and ensuring it is moving along the set path for the simulated theme park.
Should I store vertices of the track in a list and have each call to update() move the cars a step closer to the next vertex?
If you want curved track, you can use splines, which are mathematically defined curves specified by two vector endpoints. You plop down the endpoints, and then solve for a nice curve between them. A search should reveal source code or math that you can derive into source code. The nice thing about this is that you can solve for the heading of your vehicle exactly, as well as get the next location on your path by doing a percentage calculation. The difficult thing is that you have to do a curve length calculation if you don't want the same number of steps between each set of endpoints.
An alternate approach is to use a hidden bitmap with the path drawn on it as a single pixel wide curve. You can find the next location in the path by matching the pixels surrounding your current location to a direction-of-travel vector, and then updating the vector with a delta function at each step. We used this approach for a path traveling prototype where a "vehicle" was being "driven" along various paths using a joystick, and it works okay until you have some intersections that confuse your vector calculations. But if it's a unidirectional closed loop, this would work just fine, and it's dead simple to implement. You can smooth out the heading angle of your vehicle by averaging the last few deltas. Also, each pixel becomes one "step", so your velocity control is easy.
In the former case, you can have specially tagged endpoints for start/stop locations or points of interest. In the latter, just use a different color pixel on the path for special nodes. In either case, what you display will probably not be the underlying path data, but some prettied up representation of your "park".
Just pick whatever is easiest, and write a tick() function that steps to the next path location and updates your vehicle heading whenever the car is in motion. If you're really clever, you can do some radius based collision handling so that cars will automatically stop when a car in front of them on the track has halted.
I would keep it simple:
Run a timer (every 100msec), and on each timer draw each ones of the cars in the new location. The location is read from a file, which contains the 2D coordinates of the car (each car?).
If you design the road to be very long (lets say, 30 seconds) writing 30*10 points would be... hard. So how about storing at the file the location at every full second? Then between those 2 intervals you will have 9 blind spots, just move the car in constant speed (x += dx/9, y+= dy/9).
I would like to hear a better approach :)
Well you could use some path as you describe, ether a fixed point path or spline. Then move as a fixed 'velocity' on this path. This may look stiff, if the car moves at the same spend on the straight as cornering.
So you could then have speeds for each path section, but you would need many speed set points, or blend the speeds, otherwise you'll get jerky speed changes.
Or you could go for full car simulation, and use an A* to build the optimal path. That's over kill but very cool.
If there is only going forward and backward, and you know that you want to go forward, you could just look at the cells around you, find the ones that are the color of the road and move so you stay in the center of the road.
If you assume that you won't have abrupt curves then you can assume that the road is directly in front of you and just scan to the left and right to see if the road curves a bit, to stay in the center, to cut down on processing.
There are other approaches that could work, but this one is simple, IMO, and allows you to have gentle curves in your road.
Another approach is just to have it be tile-based, so you just look at the tile before you, and have different tiles for changes in road direction an so you know how to turn the car to stay on the tile.
This wouldn't be as smooth but is also easy to do.