Is there an easy way to calculate the expected trajectory of the bullet in the Nape? I need to build something like this path reflected no more than one or two bodis. Like billiard games. My game do not have gravity.
Start with a stationary rectangle. I assume you can determine which edge the bullet will strike. If it strikes a horizontal edge (constant Y), then reverse the Y-component of the trajectory; If it strikes a vertical edge (constant X), then reverse the X-component of the velocity.
In the case of a circle, you must find the ray from the center of the circle to the point of impact, then reverse the component of the velocity parallel to that ray (do you know how to find the component of a vector parallel to a given vector?).
If the objects can move, and the speed of the bullet is much greater than the speed of the objects, then all you need is the instantaneous positions of the objects-- as far as the bullet is concerned, they are stationary.
If the objects are moving with speed comparable to the speed of the bullet, you must be able to do simple coordinate transformation, in order to shift in and out of the object's frame. For instance, if the object has velocity (2,3) and the bullet has velocity (-5, 9), then in the frame of the object the object is stationary and the bullet has velocity (-7, 6). Then you can calculate the collision in this frame (where the object is stationary), then transform back. For instance, if the object is a rectangle and the bullet hits its bottom edge, the bullet's velocity becomes (-7, -6), which we transform back into the world frame: (-5, -3).
Related
I am building a sandbox for playing around and testing ammo.js (a javascript port of the Bullet physic engine v2.82). So this question should apply to both Ammo and Bullet I guess.
I am starting my scene with a falling sphere and the world gravity is set to (0, -9.8, 0).
Before the sphere touch the ground, I am disabling the world's gravity:
physicsWorld.setGravity(new ammo.btVector3(0, 0, 0));
I am expecting the sphere to "freeze" it's movement, since no gravity should be applied anymore, but the sphere is still falling and hit the ground. I am wondering why.
It's due to inertia. The first Newton's law says that if the forces applied on an object is zero (the case of your sphere after your gravity change), the acceleration is zero. But it does not mean that the velocity is null. In your case, the velocity will stay constant.
Another way to convince you is with Newton's second law which is probably coded in ammo.js:
ma = F
a is the acceleration, m the mass, F the sum of external forces.
Let's say that a = (v_{t+1} - v_t) / dt. With F=0, you will get v_{t+1} = v_t, a constant velocity.
v is the velocity, dt the time step.
I have two layers. Each layer has a primitive drawing in it with OpenGL like this:
void Layer1::drawPolygon()
{
glLineWidth(1);
DrawPrimitives::setDrawColor4B(255,255,255,255);
DrawPrimitives::setPointSize(1);
// Anti-Aliased
glEnable(GL_LINE_SMOOTH);
// filled poly
glLineWidth(1);
Point filledVertices[] = { Point(10,120), Point(50,120), Point(50,170), Point(25,200), Point(10,170) };
DrawPrimitives::drawSolidPoly(filledVertices, 5, Color4F(0.5f, 0.5f, 1, 1 ) );
}
When I addChild these layers to a scene and set Z orders 1 and 2, I see that I can bring one primitive on top of another and vice versa - when I exchange the Z order values. The strange things start when I addChild a sprite into one of these layers. If I addChild a sprite, then sprite lays on top of the primitive of that layer, and not only that layer. Even if the layer has smaller Z index, anyway its sprite is on top of other layer's primitive, while its primitive is below the other primitive shape - as was expected. Is this OK? How I should understand this? What if I want to draw primitives on top of all sprites?
EDIT:
I could manipulate their order, but not drawing order, with the following:
CCDirector::getInstance()->setDepthTest(true);
myLayer->setVertexZ(-1);
But I don't understand why sprites in a layer with smaller Z order are being drawn later than the primitives of the layer with bigger Z order. In other words, seems that all the primitives from all the layers is being drawn according to their order, then the same is being done for the sprites.
Due to the new multithreader renderer on cocos2d-x 3.0, drawing with primitives requires a different approach. Take a look at my reply at this thread:
https://stackoverflow.com/a/22724319/1468700
I believe there is a bug in cocos2d-x V3 beta 2 that makes primitive drawing always appear below all layers.
It is fixed (I understand) in V3.0 RC
This is incorrect - there is no bug (I was mislead by other posts - my apologies).
See the post below for a link explaining what needs to happen to get primitives to draw in the 'right' z-order.
The summary is that all drawing operations are added to a queue in the game loop, then the queue processed - so you need to add your primitive drawing into the queue rather than drawing immediately.
Question: How do you drag an object in a 3d environment with libgdx?
I manage to pick the object by using a Ray projected from the screen point that I touch and checking if intersects the object's bounding box but I don't understand how to actually update its position. What I'm trying to achieve is a movement on the xz plane, so that when I drag my finger towards the upper ( or lower) end of the screen, the objects move in depth on the plane. Anybody can help?
I have a main object that moves around wherever the mouse is.
How would I make an animation that shoots out other objects from the main object toward receivers that don't move?
Is there an easier way than finding the angle between the main object and the receivers and then sending the animation out that way?
So the shooting animation should rotate depending on where the main object is so that the shooting animations will always reach the target.
You can use TweenLite and just specify the x, y location :
TweenLite.to(bullet, duration, {x:targetX, y:targetY});
You can download it here :
http://www.greensock.com/v12/
You'll probably want to calculate the duration of the tween based on the distance between the objects and how fast you'd like it to move in pixels per second. For example :
var duration:Number = distance / pixelsPerSecond;
That would give you the correct amount of time for the tween.
I have created a collision class to detect collisions using pixels. In my class I've also developed some functions for determining the collsion angle. Based on this I created some examples:
http://megaswf.com/serve/25437/
http://megaswf.com/serve/25436/
(Space to change gravity, right/left to give some speed to the ball.)
As you will probably notice, there are strange things that happen:
When the ball speed is very low
When the direction of the ball is
almost tangent to the obstacle.
collision http://img514.imageshack.us/img514/4059/colisao.png
The above image shows how I calculate the collision angle.
I call the red dots the keypoints. I search for a maximum number of keypoints (normally 4). If I find more then 2 keypoints, I choose the 2 farthest ones (as shown in one of the blue objects). Thats how I then find the normal angle to where in the surface the object collided. I don't know if this is an obsolete way of doing things.
based on that angle, I rotate the speed vector to do the bouncing.
The piece of code to do the maths is here:
static public function newSpeedVector(speedX: Number, speedY: Number, normalAngle: Number): Object{
var vector_angle: Number = Math.atan2(speedY, speedX) * (180/Math.PI);
var rotating_angle: Number = (2*(normalAngle - vector_angle) + 180) % 360;
var cos_ang: Number = Math.cos(rotating_angle/DEGREES_OF_1RAD);
var sin_ang: Number = Math.sin(rotating_angle/DEGREES_OF_1RAD);
var final_speedX: Number = speedX * cos_ang - speedY * sin_ang;
var final_speedY: Number = speedX * sin_ang + speedY * cos_ang;
return {x_speed: final_speedX, y_speed: final_speedY};
}
This is how the new speed vector is calculated...
My question is, has anyone faced this kind of problem or has some idea on how to avoid this from happening?
Without seeing your code, this is the best I can provide.
Collision physics should have some velocity threshold that is considered "stopped". That is, once the velocity gets small enough you should explicitly mark an object as stopped and exempt it from your collision code. This will help stabilize slow moving objects. Trial and error is required for a good threshold.
When a collision happens, it is important to at least attempt to correct any inter-penetration. This is most likely the reason why tangent collisions are behaving strangely. Attempt to move the colliding object away from what it hit in a reasonable manner.
Your method of determining the normal should work fine. Game physics is all about cheating (cheating in a way that still looks good). I take it rotation and friction isn't a part of what you're going for?
Try this. You have the contact normal. When you detect a collision, calculate the penetration depth and move your object along the normal so that is isn't penetrating anymore. You can use the two points you have already calculated to get one point of penetration, you'll need to calculate the other though. For circles it's easy (center point + radius in direction of normal). There are more complex ways of going about this but see if the simple method works well for you.
I have read and recommend this book: Game Physics Engine Development
I did something a little like that and got a similar problem.
What I did is that when the pixels from the bouncing object (a ball in your case) overlap with the pixels from the obstacle, you need to move the ball out of the obstacle so that they are not overlapping.
Say the ball is rolling on the obstacle, before your render the ball again you need to move it back by the amount of 'overlap'. If you know at what angle the ball hit the obstable just move it out along that angle.
You also need to add some damping otherwise the ball will never stop. Take a (very) small value, if the ball velocity is bellow that value, set the velocity to 0.
You can try one more thing, which I think is very effective.
You can make functions such as getNextX() and getNextY()(Which of course give their position coordinated after the next update) in your game objects and Check collision on objects based on their next position instead of their current position.
This way, the objects will never overlap, you'll know when they are about collide and apply your after collision physics gracefully!