I'm in the process of learning sprite kit and decided a catapult style game would be a good project to start with.
I am launching a projectile by using physicsBody?.applyImpulse(CGVector(dx: strength * dx, dy: strength * dy)) and this all works fine.
I'm currently trying to predict the trajectory of the projectile. I am doing this by applying the same impulse to a hidden SKNode and plotting the path it takes.
The problem is that the user has to wait until the impulse/physics has finished until they can see the full path. (see image below)
Path Image
(from the image above) I want the green path to either appear instantly or appear a lot faster.
I've tried to adjust the speed of the SKNode but it doesn't seem to have any effect on the simulation (it always runs at the same speed). I've also tried using SKAction.applyImpulse with the speed property being adjusted but it didn't have any effect either.
The only thing that has worked is setting physicsWorld.speed but I don't want to change the speed of the whole physics world, only the hidden trajectory node.
I was wondering if there was a way to run the physics simulation on a specific node instantly, or at least speed it up so it runs quicker?
Thanks in advance.
You can massively increase the gravity, and then factor this increase into the increase in the force used to project your object. This will result in the same arc of flight, but rising and falling much faster.
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 have a game similar to Sand balls and I was wondering how can I speed up the game a bit without touching the timescale? A nice and somehow correct approach would be to scale down all my objects so gravity can also "affect" the drop movement. I already tested that and works as expected, except I have to apply that for 100+ levels... and would break some prefabs (a mass level editor to scale by bounding box would work but that's another story)
On the other hand, I have timescale but feels like it's the incorrect approach since it also affects animations and leads to unwanted behaviors.
So... do you know any other ways to speed up the game?
If objects is falling down, you can increase gravity. Or without touching timescale, you can just create a public speed multiplier variable and set it to 1 at start.
If you only move balls (Assumed from give sand balls reference), just multiply speed variable of ball with public speed multiplier variable. When you want to change the speed, just change the variable. As an example:
var ballSpeed = baseBallSpeed * speedMultiplier;
I have a rope with pin joints between chain rings. It had worked perfectly.
I now want to simulate real chain, so I added limits for pin joints as such:
pinJoint.upperAngleLimit = CGFloat(M_PI / 6)
pinJoint.lowerAngleLimit = CGFloat(-M_PI / 6)
pinJoint.shouldEnableLimits = true
However, when I use a ball-like start of the chain, I get pictures 3-4 (shown below)
I tried to use constraints, but they weren't really helpful
Have you tried to use Matti's rope module? This worked pretty well for me. The simulation became very unstable based on the mass of the ball. Try reducing the mass of the rope links and the ball. Also, if the rope spins too fast the physics will also become unstable.
I think next time I will try using Verlet integration like this example. This also has the advantage of being able to attach on both ends.
Usually in 2D physics engines like JBox2D, if the user wanted to make a simulation run in "slow motion", you would just decrease the value by which the simulated world iterates by, for example normal movement at 60fps, the step would be 1/60 if the physics world is stepped forward every frame.
But for the SKPhysics class in the sprite kit in xcode 6 using swift, I only see the property called ".speed" which when I decreased, only led to a jittery mess, that updated the physics bodies once every 10 frames.
Is there a specific property, or trick maybe to get the SKPhysics world to iterate forward in time by smaller increments without gross glitchy movements?
The only way to slow down the simulation in sprite kit is to use the physicsWorld.speed element.
But if you are trying to change only one or two sprite speeds, try the velocity element of the sprite:
node.physicsBody.velocity = x
you can directly change the velocity(speed) of your node or sprite through its physicsBody.
Hope it helps :)