I am looking to create a similar tunnel effect in COCOS2D (iOS). Could anyone suggest any pointers?
ref Video 1
ref Video 2
Till now I have tried with several ring shape sprites with decreasing scale and positioned center to a same point and keeping Z decreasing as well for each smaller sprite.
With that, animating it with CCScaleTo and changing the size to 2.0 with animation duration but it does not come anyway near to the tunnel effect shown in the reference.
Thanks,
sam
I found the implementation description from the author of this effect:
"It surely was a lot of work to create the depth illusion in a 2D plane.
The principle is very easy though: circles start in the middle of the screen with scale 0. Then the first circle of the tunnel starts scaling proportionally to the time elapsed (linear scaling doesn't work) and after some time the second circle starts scaling, then the 3rd, and 4th and so on.
You then lower proportionally the alpha value for the circles (the ones in the far back have alpha value lower than the ones in front to give the illusion of blur), you define a path that every circle has to follow, moving the X and Y coordinates of it, then you put a spaceship in the middle of the screen. Tilting the device makes the tunnel to shift left and right, up and down (but that gives the impression that the spaceship is moving instead!).
Once the circles go out of the screen, they are quickly faded and put back into initial position (to save memory so I don't need to create new circles but I reuse the same ones).
Sorry about my english, but I hope that explained the general idea :)"
Related
How do you simulate sliding, image a circle on screen and its sliding across the screen background. Or a puck sliding in an air hockey game.
This app shows exactly what I want if you care to see an example in action!
https://itunes.apple.com/gb/app/puck-puck/id463455207?mt=8
The app is free and put it there in case someone wanted to download it to exactly see what I was talking about. My current method is using physics.start() and setLinearVelocity(200, -300), then when the object is returning "falling" down screen i physics.pause() this gives appearance of fast - gradual stop. Wondering if another way so I could use friction to change things up.
Sliding friction is a force with a constant magnitude and a direction opposite to the direction of motion.
The magnitude is a free variable you can adjust to get the motion you like. In real life it's proportional to the normal force (the force perpendicular to the surface, related to the weight) and a coefficient of kinetic friction (which is a measure of how "frictiony" the interface is -- ice or sandpaper).
Kinetic friction stops when the motion stops. Then static friction takes over, which is similir to kinetic but a little stronger, and applies as long as the object stands still. A common mistake is to botch this transition, so that the object winds up oscillating at low speed.
I am using Chipmunk Space Manager.
I have my space setup with one ball and a bunch of segments (512 in my case) joined together to make a circle.
My aim is to force the ball to move in that circle as user moves the device.
The faster user moves the device, faster the ball will move in circle. The ball has to follow all physical laws as well.
I am getting gravity and userAcceleration components from CMMotionManager but unable to make some sense out of it.
I tried applying force manually and that works realistically, but I am unable to move the ball in the circle depending on how much user moved the device.
Like if I put a small ball in a glass and shake the glass, the ball will move in the circular bottom of the glass and comes to rest in the direction of tilt of glass when there is no more external force moving/tilting the glass
I think the easiest way to do it would just be to change the gravity of the space to match the accelerometer. To get smooth circular motion it would probably be best to use a cpSlideJoint with a min dist of 0 and a max dist of the radius of the circle you want to spin it in. It's not possible to make a smooth hollow shape otherwise. You'd have to build it out of many line segments and that might not work very well.
I'm trying to render 6 spot lights to create a point light for a shadow mapping algorithm.
I'm not sure if I'm doing this right, I've more or less followed the instructions here when setting up my view and projection matrices but the end result looks like this:
White areas are parts which are covered by one of the 6 shadow maps, the darker areas are ones which aren't covered by the shadowmaps. Obviously I don't have a problem with the teapots and boxes having their shadows projected onto the scene, however as you can see the 6 shadow maps have blindspots. Is this how a cubed shadow map is supposed to look? It doesn't look like a shadowmap of a point light source...
Actually you can adjust your six spots to have cones that perfectly fill each face of your cubemap. You can achieve this by setting each cone's aperture to create a circumscribed circle around each cubemap face. In this case you don't have to worry about overlapping, since the would be overlapping parts are out of the faces' area.
In other terms: adjust the lights' projection matrix' FOV, so it won't the view frustum that includes the light cone, but the cone will include the view frustum.
The a whole implementation see this paper.
What you're seeing here are a circle and two hyperbolas -- conic sections -- exactly the result you might expect if you took a double ended cone and intersected it with a plane.
This math may seem removed from the situation but it explains your problem. A spotlight creates a cone of light, and you can't entirely fill a solid space with a bunch of cones coming from the same point. (I'd suggest rolling up a bunch of pieces of paper and taping them together at the points to try it out.)
However, as you get far from the origin of your simulated-point-source, the cones converge to their assymptotes, and there is an infinitesimally-narrow gap in the light.
One option to solve this is to change the focus of the cones so that they overlap slightly -- this will create areas that are overexposed, but the overexposure will only become obvious as you get farther away. So long as all of your objects are near the point light source, this might not be much of an issue.
Another option is to move the focus of all of the lights much closer to their sources. This way, they'd converge to their assymptotes more quickly.
I'm implementing a small game and am having trouble getting the physics working properly.
In this game, there is one ball (a circle which moves from frame to frame, and may change radius) and several walls (line segments which also change and move from frame to frame). I can detect collisions properly, and making the ball bounce off in the correct direction is no problem.
Difficulties arise in situations where the ball intersects a line in one frame, then intersects it again in the subsequent frame, causing a double bounce. I could move the ball back along the normal of the line until it is in a valid position, but this causes really weird behaviour when the line in question is being hit along its axis (imagine a ping pong ball falling down on an upright toothpick and suddenly shifting aside so that it is on one side of the toothpick...). There are also a few issues when the ball intersects more than one line in a given frame (imagine four lines together making a rectangle and the ball intersecting the corner of said rectangle) -- which direction should it bounce off? In which direction should it shift?
I don't really have a specific question, but am looking for tips or some useful tutorials. All the 2D ones I've managed to find so far only cover rectangle intersections.
I'm using XNA if it makes any difference.
Thanks,
Cameron
This is an universal problem with most physics libraries. If you google for "penetration depth" (together with "physics", I suggest, or you might find something entirely different :D) you will find that even these libraries use tricks like yours.
There are two solutions to this:
The cheap one is to increase your update frequency. Move objects in 10 smaller steps instead of a single big one and you will have less penetration, so fixing it by offsetting the ball away from the wall will be less visible.
The expensive one is continuous collision detection. There are algorithms that can tell you, given a moving and a stationary object, the exact point in time both will will intersect. Google "swept sphere rectangle intersection" to find some of these.
You can then update like this: ball needs to move by 1.0 units. Check for collision. Collision occurs after 0.25 units, so move ball by 0.25 units, calculate reflection vector (so the ball bounces off the wall), repeat collision check with remaining 0.75 units (until you know the final position of the ball). This avoids penetrations entirely and even if your ball is moving so fast that it would normally skip over the wall in a single update, the collision will be detected.
It's generally accepted that, because of the timestep your collisions will intersect past an acceptable point in between updates.
Basically, you have to interpolate back to the point in between the last and current frame where the collision truly happened, move the object back to that point, and then calculate the forces, etc.
I have an issue similar to http://farseerphysics.codeplex.com/Thread/View.aspx?ThreadId=72364
I have a rectangle player geom, and many rectangle tile geoms lined up next to each other.
Occasionally when the player geom is crossing between them he seems to clip onto the corners of the tile geom and as a result rotate over.
Even when switching the moment of inertia to infinity which prevents rotation, the player geom "hops" when it clips the edge.
Here is a screenshot of the geoms tripping image http://notspike.com/PrototypeG/trip.png
Is there any fix for this? I've tried the Farseer forums but it seems pretty inactive
Here is a link to a video using a circle geom for the player
http://www.notspike.com/PrototypeG/trip.avi
I would suggest that you avoid the use of small tiles placed next to each other for the level's collision geometry. For example, although visually it's clear that you're using tiles, the "floor" from the video would best be described as a long contiguous rectangle. That way, you don't have this problem at all ... floating point math is already imprecise enough and tiling collision geometry is just asking for that to go wrong :-)
I've had this happen before when my shapes are small enough or the movements are fast enough for the interval between physics calculation "ticks" to be enough to allow the objects to overlap before the collision detection kicks in.