I'm using Chipmunk cocos2d for what will ultimately be a sound-generation game where colliding particles make noise. But right now, I'm running into a problem: my particles keep falling through the floor!
In the example "bouncing ball" templates, the multiplier on the incoming accelerometer stream is fairly low (around 100.0f) but to get things to really react quickly I am cranking it up:
- (void)accelerometer:(UIAccelerometer *)accelerometer didAccelerate:(UIAcceleration *)accel
{ space->gravity = cpvmult(cpv(accel.x, accel.y), 10000.0f); // originally 100.0f
}
I have found that this can be ameliorated by making dt really small, polling the accelerometer around 1/240 of a second.
Is this the best way? Is there another way to say to Chipmunk "look out, these things move fast"?
In general many physics engines have difficulty with collisions between quickly moving objects that are small relative to their velocities. I do not know the specifics of Chipmunk, but your issue implies that at certain time intervals a check is performed for intersecting objects. If the objects move quickly and are small, it is possible for the time interval where a collision is happening to be skipped.
The two easiest solutions are to use a smaller time interval, or somehow make one of the two objects larger. How are you representing the floor? If you can represent it as a thick rectangle, that should also reduce the problem.
The harder solution is to use a more complicated intersection algorithim, such as using bounding capsules to represent the area of space traversed by a sphere between two samples. If the API does not already support this, it is a pretty hefty amount of math and modification.
Related
I have this simple domino scene where you can click a domino and apply a force to knock it.
At first I had this dominoes in a scale of (x=0.1), (y=0.6), (z=0.3) 1 is supposed to be 1 meter, they fell without a problem but too slow. According to unity documentation on Rigidbody this made total sense.
Use the right size.
The size of the your GameObject’s mesh is much more important than the mass of the Rigidbody. If you find that your Rigidbody is not behaving exactly how you expect - it moves slowly, floats, or doesn’t collide correctly - consider adjusting the scale of your mesh asset. Unity’s default unit scale is 1 unit = 1 meter, so the scale of your imported mesh is maintained, and applied to physics calculations. For example, a crumbling skyscraper is going to fall apart very differently than a tower made of toy blocks, so objects of different sizes should be modeled to accurate scale.
So I just re sized the dominoes to (x=0.01), (y=0.06), (z=0.03), this time they fell to the desired speed but for some reason they stop falling and don't knock the next domino.
example GIF
I don't know why this is happening but i can guess that this is because at the time of calculating physics the engine doesn't waste so much resources in calculating small objects that are probably not even going to be seen by the user.
Modifying mass doesn't seem to do anything, also draw and angular draw are both 0 and already tried every collision detection mode.
Is there any solution or workaround for this?
In my experience, Unity physics doesn't like too small objects since it introduces rounding errors. A game simulation usually does not need the same accuracy as when you try to land on Mars. Therefore, I usually avoid scales less than 0.1f.
In your case, I would keep the scales at 1.0f and instead experiment with either increasing the world gravitation, changing it from the default -9.81f to -98.1f (Edit - Project Settings - Physics). Or changing the default Time Scale from 1f to 5f (Edit - Project Settings - Time).
Try not to make too big changes in the beginning since it might introduce strange effects on other parts of the gameplay.
I have a sphere with bounciness set to 1
The ball has no drag and uses gravity
It hits a platform, which has bounciness set to 1 and no friction
Yet, the ball bounces higher on every bounce, going to infinity. How is such a thing possible, when I have not given it any extra momentum?
The issue comes from the fact that physics in games happens in discrete frames, and that a moving object will be "inside" another at the frame where there is a collision. The physics engine then has to separate the objects before the next frame, and figure out how much energy to "bounce" with.
One of the steps to do this involves figuring out how much the objects overlap, and that's where this phantom extra energy is comin from. Less error in the overlap equals less error in the energy.
Don't fiddle with the bounciness; those are naive solutions, not to mention they sidestep the issue rather than solving it.
What you should do is to fix what's wrong with your collisions. That can be done a number of ways, the most appropriate/performant of which depends on each specific game:
Increase your physics frame rate (decrease fixed delta time). This reduces overlaps and makes physics frames "smoother". It doesn't really solve phantom energy though; only makes it's causes and effects smaller (maybe so small they become unnoticeable, which is all you need).
Set your sphere's collision detection method to Continuous Dynamic,
and set your ground to static. If you need the sphere to collide with
other stuff, those other stuff present similar issues, and those need
to be non-static, set their rigidbodies' collision detection method
to Continuous. (This is the method I most often find to be the best, but I've had projects where others were better for various reasons)
Increase your Default Solver Velocity Iterations
Change your solver type to Temporal Gauss Seidel
I have had a similar issue with javascript/html/css canvas animations. I have no explanation for this. Use a number like 0.99999 or 0.969399 and that should do the trick. I do get what you mean though it's weird. Just get close to 1. That's all I can say. I hope this helps anyway.
I am working on an AI mode for a SpriteKit game I am making in Xcode. I have dynamic physics bodies which can be launched towards the AI. I want to make it so that when one of these bodies is within a certain radius of the AI, the AI tries to dodge it. I have started working through different routes and got decent results.
1st method (pseudocode): Check AI.position.x and AI.position.y and compare to incomingSprite.position.x and incomingSprite.position.y. Break this comparison into quadrants if both x and y are within radius. (i.e. incomingSprite is bottom left relative to AI, bottom right, etc). Based on this info move the AI's position to move away from it.
cons:
-lots of code and calculations in update function to account for multiple incoming sprites
-depending on dx and dy of incoming sprite, the AI often make illogical decision
2nd method (pseudocode): Calculate distance from AI to incomingSprite. Then check dx and dy of incomingSprite and set dx and dy to go in reverse direction of incomingSprite. This seems logical. I am a little rusty on reversing vectors to do this. I feel like this might be possibly a good idea though.
Is there a better method to accomplish this? Perhaps a force field on the magnet I could use to repel the AI at a certain strength so that if the incomingSprite is fast enough it will override and still collide anyway? Im concerned about memory as most of the AI logic is in the update function, which can cause big problems if I'm not careful.
Edit: I decided to use the electric field and gave the incoming sprites a positive charge so that they are repelled by the AI. This makes things accurate/lightweight and more interesting. If the incoming sprites are fast enough, they will break through the electric field and still collide with AI. This also gives room as an additional difficulty parameter in my game (the stronger the field, the harder it is to get the incoming sprites to collide with the AI).
I'm trying to create a chain in unity3d. A player should be capable of grabing one side of it and pull it to different location. So i created some grids and connect them together. It all works fine, the problem is only when user pulls a bit faster, then I got some spaces bettwen seperate grids. Is there anyway to set max distance on that?
Btw. I'm doing these in 2d so i have 2d Rigidbody and 2d Hinge joint.
Thanks!
The solverIterationCount of rigidbodies affects the smoothness of physics when they are moving fast. You should try increasing it or dynamically adjusting it according to the speed of the rigidbodies to increase stabilty
http://docs.unity3d.com/Documentation/ScriptReference/Physics-solverIterationCount.html
There a number of ways to tackle this issue, all with the up sides and down sides:
increasing accuracy:: this is usually the first place new game designers go, and crank up accuracy to the max. But then end up playing the price later when performance plummets. So be gentle, try to find a good balance, and if it does not cut it make up the rest with other tricks.
The main ways to increase accuracy are, increasing fixed times interval, and increasing ridged body Iteration count
.
Increasing restrictions::This often requires the most time, but cutting corners allows for smoother more predictable physics and can increase performance
small example:: the top link of the chain only needs to simulate rotation on the ridged body
.
Cheating:: find any way to make things easier, fake it
for example:: does the image really need to match the physics? Why not make sure the sprites stick together, but alow the physics to have small gaps
playing with the same concept more or less this week, experimented some with 2D Unity joints, I think the issue you are having is identical to one I had yesterday, the force you are applying 'breaks' joints for some frames, hence that almost 'spring' joint effect, make sure the mass and/or force applied are not too heavy, also maybe increase the chain parts mass, makes the joints more solid too.
In Editor, Hinge Joint -> Use Spring = true; Spring/Damper/Target Position = 0.
I'm trying to create a new kind of rotary control with a look and feel of a real massive wheel supported on a pin, able to rotate around it's center point with a certain degree of damping, which will eventually bring the wheel to a halt. Think "wheel of fortune".
Rotary control sample project
When working with native UITableView and/or UIScrollView, they can be "flicked" in one direction and continue scrolling in that direction for a while. I know similar effect may be achieved with the animation curve.
What I'm interested in is how to calculate how far the interface element should scroll/rotate based on the distance/speed that the finger travelled. Different types of "flicks" would produce different behavior by transferring "momentum" to the wheel. Can anyone suggest examples of such calculations?
I'm particularly interested in applying the same concept of inertia to a custom rotary control as described here: Rotary control on stack overflow . The current examples, and even the convertbot app mentioned in the examples do not use inertia. The wheel simply follows the finger and snaps to pre-defined positions. I want to make a similar wheel feel like it has real mass to it, so it can be flicked and will spin in a predictable manner until coming to a smooth halt. (Think "wheel of fortune" type shows).
How can I achieve this kind of "wheel of fortune" inertia-based behavior for a rotary control that would make the control feel like it has real mass to it?
Thank you!
Implementing a fully realistic mass effect is not that trivial, and maybe requires too much work (especially for such a simple task), thus I'd ignore physic's laws (except those strictly needed) and make everything simpler.
A momentum is r x F where r is the radius and F is the force applied. Since it depends on the radius, the more you get far from the center of your wheel the greater will be the momentum. Let's ignore it and suppose that the force is tangent and is applied always at r=wheelWidth/2.
Besides, instead of computing force you may simply make it depends on the speed of the gesture (easier than computing force, since it requires mass and acceleration). Thus we can image that a faster touch will correspond to a greater momentum.
Of course, the gesture will never be perfectly horizontal or vertical, thus you can assume that every time there are two torques applied: the first corresponding to the vertical movement and the second to the horizontal.
You can get the gesture speed you may simply compute initial and final position of the touch, and divide their difference by the time elapsed.
To get the effect of slowing down you must assume that, when the wheel is moving, there is always an opposite torque. You can define it at compile time or make it dependent from the width of your wheel (such that larger wheels will slow down faster).
Now you have pretty much all that you need...good luck :)
I found that using iCarousel, it is possible to create a wheel like control with inertia/momentum!