following Situation: I have a box2d Body which I control via the accelerometer in a Zero gravity environment. I set linearVelocity proportional to 'roll' and 'pitch' via Impulses.
When the Body touches anything, it will cause damage.
Now the Problem: When the Body is colliding with static objects, and the direction of the movement is still pointing in that direction, the Body will still receive damage due to the Impulses (Body vibrating).
I tried to slow down the Body after collision, e.g. decreasing Maximum Impulse value over time(which works), but I'd rather don't want to slow it down.
Any suggestions how this could be achieved?
Thanks
You should set a proper values for Fixture - in this case you should set restitution to 0.
FixtureDef fd = new FixtureDef();
fd.restitution = 0;
The restitution is abount how "bouncy" is body. The situation you've described is probably caused by too high restitution (body touches static one, bounce but immediately fall down due to gravity then bounce then...)
You can read more at Box2D official reference
Related
When I make a lot of bodies (rectangles) stacked on each other they don't stand stable. Even if restitution is set to 0. They are bouncy and fall off each other. I tried setting the density to a very low value, but it didn't change.
Is there a possibility to fix that?
shape.setAsBox(0.1f, 0.1f, new Vector2(0, 0), 0);
bDef = new BodyDef();
bDef.type = BodyDef.BodyType.DynamicBody;
bDef.position.set(0, 0);
fDef.shape = shape;
fDef.density = 0.001f;
fDef.friction = 0.5f;
fDef.restitution = 0.0f;
for (int i = 1; i < 50; i++) {
bDef.position.set(0, i * 0.201f);
body1 = world.createBody(bDef);
fixture = body1.createFixture(fDef);
}
So long as this is the problem that I think it is, then yes, this is fixable. Albeit with additional work. But in the short term, no.
When I run the "Vertical Stack" test of the Testbed from Box2D 2.3.2, I see a bunch of boxes drop down on top of each other in a vertical stack. At first they stack, then they wobble, then they tip over. This is how Box2D is designed to work. I didn't like that behavior so I changed it.
I suspect that this is essentially the same problem as you are seeing. The "fix" I used to modify this and gain a stable stacking behavior, involves changing the internal Box2D library code.
Algorithmically speaking, I modified the way position resolution is done from resolving impulses being applied one collision manifold point at a time, to resolving impulses being applied in order of penetration depth or simultaneously when they're almost equal. Code wise, I essentially made this algorithmic change to Erin's b2ContactSolver::SolvePositionConstraints and b2ContactSolver::SolveTOIPositionConstraints methods (in Erin's b2ContactSolver.cpp).
Code for this altered algorithm is in the dev branch of my fork of Box2D (see the SolvePositionConstraint function in the ContactSolver.cpp file). Unfortunately, I don't have a diff that would just apply to those methods as my code changes extend beyond those. Additionally, the changes that I've made modify the Box2D library public interface so even if you can get it to build for your platform, you'll still need to adapt your code to the new interface I have.
I'm developing a cocos2d-x game (version 3.8). My game uses chipmunk physics and it has a static body that works like an interruptor. This interruptor is enabled when another body is over it. The interruptor is disabled when bodies separate each other.
I want to:
Moving body don't collision with interruptor. It has to cross interruptor with no bounce
I want to detect when moving body separates the interruptor
My first approach was implementing onContactBegin method. I return false when those two bodies get in touch. This way the body crosses the interruptor and does not bounce.
The problem is onContactSeparate method is not called, because contact did not happen.
If I return true in onContactBegin method, onContactSeparate is called and I can detect it. The problem is the body does not cross the interruptor, it bounces.
[EDIT] More info
This is the scenario where two sprites are separated. The ball can move and interruptor is a static body. Ball could be over the interruptor.
This is the scenario where two sprites are in contact and object1 (the ball) is over the interruptor. I want to detect where two sprites separate each other.
Any help would be appreciated!
It seems to me like you are using Box2D within cocos, so I'll answer with that as my base assumption.
This is what i would do.
My interrupter would be a b2Body* with no BodyDef dimensions defined or just a 0x0 dimension def.
I would set the user data for the bodyDef to a rectangle that describes my interruption area. This way you can always have your interruption area represented, but will not collide with anything.
(Optional) If you want the interruption area to move around based on the fake body you assigned to it, you can updated it just after the step function using something like below.
world->Step(delta, 10, 10);
for (auto physicsBody = _world->GetBodyList(); physicsBody; physicsBody = physicsBody->GetNext())
{
auto userData = static_cast<Node*>(physicsBody->GetUserData());
if(userData != NULL)
{
// Set interruptor area rectangle = physicsBody->GetPosition();
}
}
To let the rest of the system know when I have left the interrupter I would store a function pointer to the function I want to call when this happens, When a object enters the interruption area I would flag it saying "I'm in the area" after that, the first update step you get when it's not in the area anymore I would fire the callback and reset the flags I used to get to that point.
I hope this helps. You are not giving a lot of context for what you want to do, an image would be helpful. Especially when it comes to looking for help with code that has a visual representation as well.
[EDIT]
Based on the behaviour you want this is the way I did this. The first thing to know is that you don't need physics collisions for the behaviour you want. You can do this by using bounding box intersection tests and use flags and callbacks to figure out the rest.
I have an object that knows about both the ball and my interrupter nodes. In the update loop of this object I check if the two intersects. I set a flag indicating "I am in the interrupter", the next frame that I am not in the interrupter and my flag is still true I call the function that I assigned with my "leaving logic" in it, and set then flag back to false.
i expect this is quite an easy one.
I'm trying to simulate a falling Bean Bag that can be knocked into a net on one side of the screen.
I have:
a dynamic body and circle shape representing a hand or bat, which moves respective to the mouse.
falling dynamic body circle shapes representing the Bean Bags.
and simply, two small circle shapes representing the net's open top.
To move the hand/bat i update a linear velocity on each step, so that this force can be applied to the bean bag:
// move hand
deltaX = (handBody.GetPosition().x * scaleF) - mouseX;
deltaY = (handBody.GetPosition().y * scaleF) - mouseY;
var newVel:b2Vec2 = new b2Vec2(-deltaX, -deltaY);
handBody.SetLinearVelocity(newVel);
My problem is that I would like the Bean Bag to absorb some of the initial force of the knock. At the moment it's too easy for the falling bags to be flung off the screen with a quick swipe. Is there a simple way to use the friction, damping or other settings? I have tried but cannot seem to create the effect. Can anyone suggest how i can remove some of the collision force manually without effecting the updated position of the bat/hand?
tia,
Chris
Can't you just multiply the new velocity/bean bag velocity with say 0.8 or whatever and call this the dampening effect?
But the provided code seems weird, I can't see anything in it related to impact or hitting a bean bag. This just sets the vel of hand?
I need to do an endless horizontal scroll of elements within a parent MovieClip.
No matter what ever method I try, an element of 'drift' occurs and eventually the elements start to overlap.
I've tried using relative recursive tweening for each element according
but this method seems prone to quite a bit of error after repeated starts and stops.
//CODE START
function doScroll():void {
TweenLite.to(this, .25, {x:"20", ease:Linear.easeNone,onUpdate:checkPos,onComplete:doScroll});
}
//CODE END
I've reverted to doing absolute tweens to a predefined position using a contant speed. This seems to be more accurate but still some 'drift' occurs.
//CODE START
//_dest is predefined
var speed:Number = 500;
var dist:Number = this.x - _dest;
var distAbs:Number = dist < 0 ? -dist : dist;
//kludge to get constant velocity by recalculating time every frame
_time = distAbs / speed;
TweenLite.to(this, _time, {x:_dest, ease:Linear.easeNone,onComplete:reset});
//CODE END
Thought this should be very simple.
Can anyone point me to any possible tutorials or make any suggestions?
Any help appreciated.
Solution/Discussion at http://forums.greensock.com/viewtopic.php?f=1&t=6800
(warning: this is gonna require a rather lengthy explanation...)
It's a logic problem in your code. In your onUpdate, you were running conditional logic such that if the x position is beyond 980, it kills the tween and moves x back to -980 and starts things over. You're doing that for each individual item, each of which begins at a different position. That initial position affects when it crosses that threshold, thus when they reposition, the offsets are different.
For example, let's say item1 starts at an x position of 0 and item2 starts at 490 and both start moving at 400 pixels per second and your frame rate is 60, thus they'll move 6.66666 pixels per frame. Item1 will take 147 frames to hit 980. However, item2 will take 74 frames (actually 73.5, but there's no such thing as a half-frame) to cross the 980 threshold, but when it does so it will be at an x position of 983.333333. At that point it jumps back to -980 due to your conditional logic, but notice that it traveled an EXTRA 3.333333 pixels. You intended Item1 and item2 to travel at the exact same velocities and they do during the tween, but your onUpdate logic is misaligning them on the reposition such that in the end, some are traveling more than others which affects their overall velocity.
Another issue has to do with the fact that Flash rounds x/y coordinates of DisplayObjects to the nearest 0.05. So when you do your manual reposition (wrap), small rounding errors creep in. For example, let's say TweenLite sets the exact x value to 980.799. Flash will actually round that to 980.75. Then when you reposition it like this.x -= 980 and then tween it, the value would have just lost almost 0.05 pixels on that round. Do that many times and it can add up to a half-pixel or whole pixel (or more). All your items are crossing the threshold at slightly different spots, thus the rounding errors aren't the same, thus you start seeing slight variances in the spacing. Again, this is NOT an issue with the tweening engine. You'll see that the engine itself sets the values correctly, but Flash rounds them internally when applied to DisplayObjects.
A solution was posted at http://forums.greensock.com/viewtopic.php?f=1&t=6800 that includes an FLA and support files.
As others have suggested, I'd recommend having a single chunk of code that manages ALL the items that you're aligning/scrolling. It would lay things out from a single reference point so that everything lines up perfectly every time. You could tween a getter/setter that applies the logic. I use that technique all the time and it works great. You can see a smaller-scale example in the code I attached in the above URL (the scrollX getter/setter in ItemBase.as)
If you will be tweening all background elements at the same rate indefinitely on a single dimension - why not use a Timer and bypass tweening libraries entirely?
I have a velocity vector that is V(233, 188).
It makes an object moves toward the right-bottom side of the screen in 300 pixels per second when the origin is V(0, 0).
When the position of the object is, for instance, (592, 334), I set the velocity vector to V(294, 55) but the object does not start moving toward that direction... It keeps moving the same direction, but it seems that it makes a small curve of 10 degrees...
What I'm doing is:
objectLocation += velocity * elapsedTime;
What am I doing wrong?
The difference between (233,188) and (294,55) is not that much, in the grand scheme of things. To verify your code is working, try a vector such as (200,-200). That will cause it to actually bounce off the point in the y-direction.
If that code works, then it's just your values that aren't working.