I'm trying to make a basic first person shooter game with Bullet and OpenGL. I'm having the issue of my rigid bodies not colliding at high speed.
My bullets will go straight through any other rigid bodies that I have, such as walls. Reducing velocity to less than 10 does result in collisions, but this is too low for a moving bullet. The bullet also moves insanely fast (I know it's a fast moving bullet, but sometimes I can't even see it, not sure if that's expected).
I'm thinking that it's to do with how I'm stepping the simulation? Reading up on it has left me confused. How can I make it so that my objects will always collide (at least, when going reasonably fast), and if possible, is there a way to slow the simulation down whilst maintaining the correct bullet velocity etc. so that I can actually see the bullet moving and colliding?
Here are some approaches to solve:-
It is copied from How can I avoid missing collisions for fast moving objects? - an official FAQ
smaller timesteps
extruding the object along the motion
ray cast to the new position
swept collision test (convex cast, linear cast)
continuous collision detection, including rotational motion
Please read the link for more detail. It is not a trivial issue.
One important thing to ask before try anything: do you really need high speed object?
It is not free (cost more CPU).
Here is another useful link (less useful though) : https://gamedev.stackexchange.com/questions/11961/how-can-i-enable-ccd-in-bullet-physics
Related
Okay, I have read some articles about basic platformer creation, people say it's the hardest part - to make correct collisions at high speeds. Indeed, even if I have 60 fps, an object moving at like 50-100 pixels per tick is hard to trace. The problem is, if it hits a wall, it passes through it, detects going too far and returns the object to a defined point next to a wall with speed 0 (or ricochets). But if I have a 5 pixel wall in a middle of a stage, even at low speeds collision may just be missed. Yeah, you'd say "make 2 areas, check if object in one, another will be a whole hitTest zone to return from it" but what if I need a maze of randomly drawn walls? What is a good way to make thin walls an object wouldn't pass?
Thinking of platformer, I recall Castlevania and Metroid, it wasn't AS3, but still, maybe you know how they did it so smooth? Good fps? Predicting collisions? Or does nobody make crazy speeds like a ricocheting bullet?
I could really use some ideas before I dive into coding. I wish to at least know I'm moving the right way, even if it's hard. To not end up with 1000 lines, not remembering where is what and CPU load # 95% for 1 single object XD My guess for now is make 4 invisible blocks right, left, up and down of the object and count each side collisions separately. But it may get ugly on the corners. 8 blocks maybe?
At the moment, you're checking if the object is intersecting with a wall at the exact moment the frame happens, but really you want to know if the object ever intersected with the wall between the last frame and now. You can imagine a line between where the object was before and where it is now, so essentially you need to check if that line intersects with the line of the wall.
It's quite old, but tonypa has a nice tutorial here which goes over all of the basics.
Can anyone explain why (indeed, if) it's best to abstract the major parts of a canvas game to different layers when using something like Kinetic?
It of course feels like you should, and so far I have been: one layer for the background, one for the player's character, and others.
Then I ran into a situation where I needed a shape of one layer to sit behind a shape on another layer - but moving the entire layer behind the other layer was not an option, so I reluctantly re-coded so the entire game sits on one layer.
To my surprise, though, I can still do everything I need. I can still animate or handle events on individual shapes or groups.
So in short: what advantage does explicit layering bring? What pitfalls might I face with the one-layer approach?
Actually, layers usually give a huge advantage. However, sometimes they are not necessary. Just to give an idea - compare PhotoShop (layers) and MS Paint (no layers). If this gives you the idea then that's it!
If not: layers is an organizational concept. It lets you to deal with data in pieces. They allow:
Apply certain transformations to a whole layer.
Automatically categorize your objects on a per-layer basis, so that you can get
all objects of a layer and work with them pretty easily.
Isolate anything that happens in a layer from happening in other layers.
Disable/enable whole layers.
Much-much more!
As you see, layers, generally, allow such abstractions as encapsulation and, to some extent, polymorphism to be enforced on content organization level. Pitfall that one-layer approach brings is just that - too tight coupling - a beast from the world of permanent chaos that encapsulation and polymorphism fight for the eternity. Nuff said!
If your game contains a lot of different stuff, it might take time to draw everything. Too much in the same layer reduces performance. Although too many layers does so aswell.
Check out: http://www.html5canvastutorials.com/labs/html5-canvas-kineticjs-drag-and-drop-stress-test-with-1000-shapes/
In organizational terms, noncom's answer was spot on. However, as he has noted his answer is more in regards to canvas animations in general, and you are quite correct in pointing out that KineticJS provides it's own tools to offer those same organizational benefits.
So, with organisation irrelevant, all we have is performance. With that said, the main difference is that each 'layer' corresponds to a distinct canvas tag.
The simple answer then, is that having multiple layers allows you to selectively redraw only one canvas tag at a time. Think about it, if you have objects moving on top of a background, do you want to be clearing and redrawing the background every time those objects move?
If you're not using layers, that's what is happening. What you want is a background that only ever gets drawn again when the background changes, that means a layer for the background.
Whether this is actually worthwhile depends highly upon your application, but that's the idea. The point of layers (outside of organisation) is to isolate the required drawing processes to things that actually need to be drawn. With complex animations this can be incredibly important to maintaining decent performance.
Here's a jsperf for reference: http://jsperf.com/layered-canvases/3
At the moment I am working on a prototype racing game, with an aim to get as close to 3D graphics, without having to use Flash Player 11 and/or DirectX. For this, I opted to use RotationX, RotationY and RotationZ to give me the desired effects. In order to make buildings become 3D, I created four instances of the same object and rotate/index them appropriately.
This works great, until there comes a point where there are a lot of these rotation objects on stage - Then the issues start with performance. Namely, there is none.
An example is here:
http://www.hosted101.net/car/Racing3D.html
If you follow the track around you will see that performance becomes progressively worse the more that is on stage.
Stages that I have taken to try and rectify this include:
1) Disabling Z sorting - This gave no increase in performance (to my surprise)
2) Disabling object RotationZ to follow the camera - Again, no increase in performance
3) Swapping Vector graphics for Bitmap graphics - Sadly again, no increase in performance
What exactly is causing these dramatic performance hits?
Is it just that having this many objects with 3D rotation on the stage?
To answer my own question here, in case somebody ever gets into a similar pickle:
The problem was directed related to the FPS of the game. Having it set to (originally) 120 wasn't possible for lower-end machines to match, as such different results were being seen. When dropped to 60, it was still too high and as such when multiple rotated objects were onstage the FPS dropped too low, giving the choppy effect.
Having set the FPS maximum to 24 and doubled the maximum speed/turn, the game is now working as it should.
Moral: Lower FPS is better, if you're aiming for lower-spec machines.
The link you posted ran for me at a constant 60 FPS.
Your performance bottleneck might be somewhere else if none of those changes helped, try to profile using something like TheMiner.
You can also try setting wmode to "direct" or "gpu" I noticed you are using "window".
Since you don't need any mouse events on any of these buildings and trees make sure you set mouseEnabled mouseChildren to false on all these sprites.
Those are the things that come to my mind hope that helps.
I have an array of points that I will use to generate a closed polygonal fence on the outside of a game stage (2D). I wish to have collision detection between this fence and a bouncing ball-like object on the inside.
Additionally, I would like to be able to arbitrarily add/remove/redraw the fence in realtime and have the collision detection still operate realistically.
I have considered drawing a Sprite/Shape from the points and doing a HitTest at each frame to check whether to bounce or not.
My question: is this the best/correct way to accomplish this goal? Consider something like JezzBall with diagonal lines of any angle a simulation of what I'm trying to do.
Check the corners of your bouncing ball with four hitTestPoints. If it succeeds, then do hitTestPoints from the fence with shapeflag set to true.
There may be better solutions as I do not know the performance impact of shapeflag, but combined with the corners optimization I think it will be good, but I'm also interested if there is a better way.
Math will be your friend here. Do a quick search for circle-line, or point-line collision (here's one: Circle line-segment collision detection algorithm?).
What you do is run through your array of points, creating lines. So line 1 will be points[0] and points[1], and line 2 will be points[1] and points[2]. After that you check each line against your ball (if you want proper collision that will work no matter the frame rate, then you create a ball line, which is the line that the ball has travelled along between the last frame and this one). Do your collision detection against the ball line and each line made from your points (there's tons of line-line collision detection algos on the web). What you'll get out of an algorithm like that is the time the collision takes place in the current time step, as well as the normal of the colliding line, which will give you the reflection angle.
If you don't know Vector math, then learn it, it'll make your life a ton easier. Again, there are tons of implementations of a Vector2 class on the net.
You can arbitrarily remove parts of the wall as needed by just ignoring those points in your check.
Another lazy solution would be to use a physics engine like Box2D http://box2dflash.sourceforge.net/ or Nape: http://code.google.com/p/nape/ - it might be overkill for what you want for your game, but hey, it's easy.
For bonus points, another technique which might be easier for you is the Separating Axis Theorem, which is used in the flash game N: http://www.metanetsoftware.com/technique.html
Does anyone have any good references for equations which can be implemented relatively easily for how to compute the transfer of angular momentum between two rigid bodies?
I've been searching for this sort of thing for a while, and I haven't found any particularly comprehensible explanations of the problem.
To be precise, the question comes about as this; two rigid bodies are moving on a frictionless (well, nearly) surface; think of it as air hockey. The two rigid bodies come into contact, and then move away. Now, without considering angular momentum, the equations are relatively simple; the problem becomes, what happens with the transfer of angular momentum between the bodies?
As an example, assume the two bodies have no angular momentum whatsoever; they're not rotating. When they interact at an oblique angle (vector of travel does not align with the line of their centers of mass), obviously a certain amount of their momentum gets transferred into angular momentum (i.e. they each get a certain amount of spin), but how much and what are the equations for such?
This can probably be solved by using a many-body rigid system to calculate, but I want to get a much more optimized calculation going, so I can calculate this stuff in real-time. Does anyone have any ideas on the equations, or pointers to open-source implementations of these calculations for inclusion in a project? To be precise, I need this to be a rather well-optimized calculation, because of the number of interactions that need to be simulated within a single "tick" of the simulation.
Edit: Okay, it looks like there's not a lot of precise information about this topic out there. And I find the "Physics for Programmers" type of books to be a bit too... dumbed down to really get; I don't want code implementation of an algorithm; I want to figure out (or at least have sketched out for me) the algorithm. Only in that way can I properly optimize it for my needs. Does anyone have any mathematic references on this sort of topic?
If you're interested in rotating non-spherical bodies then http://www.myphysicslab.com/collision.html shows how to do it. The asymmetry of the bodies means that the normal contact force during the collision can create a torque about their respective CGs, and thus cause the bodies to start spinning.
In the case of a billiard ball or air hockey puck, things are a bit more subtle. Since the body is spherical/circular, the normal force is always right through the CG, so there's no torque. However, the normal force is not the only force. There's also a friction force that is tangential to the contact normal which will create a torque about the CG. The magnitude of the friction force is proportional to the normal force and the coefficient of friction, and opposite the direction of relative motion. Its direction is opposing the relative motion of the objects at their contact point.
Well, my favorite physics book is Halliday and Resnick. I never ever feel like that book is dumbing down anything for me (the dumb is inside the skull, not on the page...).
If you set up a thought problem, you can start to get a feeling for how this would play out.
Imagine that your two rigid air hockey pucks are frictionless on the bottom but have a maximal coefficient of friction around the edges. Clearly, if the two pucks head towards each other with identical kinetic energy, they will collide perfectly elastically and head back in opposite directions.
However, if their centers are offset by 2*radius - epsilon, they'll just barely touch at one point on the perimeter. If they had an incredibly high coefficient of friction around the edge, you can imagine that all of their energy would be transferred into rotation. There would have to be a separation after the impact, of course, or they'd immediately stop their own rotations as they stuck together.
So, if you're just looking for something plausible and interesting looking (ala game physics), I'd say that you could normalize the coefficient of friction to account for the tiny contact area between the two bodies (pick something that looks interesting) and use the sin of the angle between the path of the bodies and the impact point. Straight on, you'd get a bounce, 45 degrees would give you bounce and spin, 90 degrees offset would give you maximal spin and least bounce.
Obviously, none of the above is an accurate simulation. It should be a simple enough framework to cause interesting behaviors to happen, though.
EDIT: Okay, I came up with another interesting example that is perhaps more telling.
Imagine a single disk (as above) moving towards a motionless, rigid, near one-dimensional pin tip that provides the previous high friction but low stickiness. If the disk passes at a distance that it just kisses the edge, you can imagine that a fraction of its linear energy will be converted to rotational energy.
However, one thing you know for certain is that there is a maximum rotational energy after this touch: the disk cannot end up spinning at such a speed that it's outer edge is moving at a speed higher than the original linear speed. So, if the disk was moving at one meter per second, it can't end up in a situation where its outer edge is moving at more than one meter per second.
So, now that we have a long essay, there are a few straightforward concepts that should aid intuition:
The sine of the angle of the impact will affect the resulting rotation.
The linear energy will determine the maximum possible rotational energy.
A single parameter can simulate the relevant coefficients of friction to the point of being interesting to look at in simulation.
You should have a look at Physics for Game Developers - it's hard to go wrong with an O'Reilly book.
Unless you have an excellent reason for reinventing the wheel,
I'd suggest taking a good look at the source code of some open source physics engines, like Open Dynamics Engine or Bullet. Efficient algorithms in this area are an artform, and the best implementations no doubt are found in the wild, in throroughly peer-reviewed projects like these.
Please have a look at this references!
If you want to go really into Mecanics, this is the way to go, and its the correct and mathematically proper way!
Glocker Ch., Set-Valued Force Laws: Dynamics of Non-Smooth Systems. Lecture Notes in Applied Mechanics 1, Springer Verlag, Berlin, Heidelberg 2001, 222 pages. PDF (Contents, 149 kB)
Pfeiffer F., Glocker Ch., Multibody Dynamics with Unilateral Contacts. JohnWiley & Sons, New York 1996, 317 pages. PDF (Contents, 398 kB)
Glocker Ch., Dynamik von Starrkörpersystemen mit Reibung und Stößen. VDI-Fortschrittberichte Mechanik/Bruchmechanik, Reihe 18, Nr. 182, VDI-Verlag, Düsseldorf, 1995, 220 pages. PDF (4094 kB)