I want to have a 3d dice that can be dropped onto a surface and land face down. I also want to give the cube a random rotation velocity so the cube rotates in mid air before landing so I get a random result.
I've looked around but I cant find anything on the subject.
I know how to render and spawn the dice as well as have it affected by gravity and how to give it a random rotation velocity as well as how to stop it once it hits a surface but how can I make sure it lands face down and then how can I tell which face is facing upward so I can get the value that the dice landed on?
What you want is rigid body physics simulation. I would recommend using a physics simulation library, such as bullet.
Physics libraries usually provide functions to know if an object is "sleeping" (not moving). This can be used to trigger the dice value readout.
To know which face is facing upward, you can get the transformation matrix M of your cube, apply it to a unit vector and look where this result vector is pointing to.
If you prefer implementing the physics by yourself, those papers are really good to know the basics of rigid body simulation :
https://www.cs.cmu.edu/~baraff/sigcourse/notesd1.pdf
https://www.cs.cmu.edu/~baraff/sigcourse/notesd2.pdf
Related
I'm trying to make the basic robot arm which can hit the ping pong ball using OpenCv and C++.
I managed to detect the ball and move the robot arm according to XY coordinates using inverse kinematics, but now I need to hit the ball, and that's a hard thing.
I thought that if I'll predict the trajectory of the ball, the things would be easier, but unfortunately, this part doesn't seems easy to me either.
I thought that trajectory equations would be a good way to start, so I measured the distance of the ball between 2 frames, also I found the time between those, the angle between table and ball when the ball hits the table, but I don't know how to predict the future trajectory (or how to implement in C++) and I need some help with this.
Also, if you know any way to hit the ball in 2D it would help me a lot.
Thanks!
I am building an IOS game in Cocos2d - Chipmunk - Spritebuilder. I need to make a characters orbit around around a point, and I was having quite some difficulty in implementing orbits with real physics.
So far, I have tried two methods, one is creating a distance joint from the player to the planet, and then applying a 90 degree force on the player where an angle is created between the end of the distance joint and an imaginary line drawn at a 90 angle to it. He moves around crazily and this method is not working for me.
I then tried calculating 180 points on the circumference at a radius from the planet (which is the bounds of detecting and implementing its effects on the player) - and then in a scheduled update method [character.physicsbody applyForce:nextCircumferencePoint]; This does not work, as he does not follow the path exactly and is quite far from it. I am thinking that I need to also apply a gravitational force towards the planet which would cause him to circle it. Though I don't know how to calculate that force, apply it, or if it would even help.
A third method which would never work, but was used for testing was to set his position to the next circumference point. He does orbit, but any collision won't work (such as if a piece of space junk goes in his way.) He will simply be positioned right over any other object. This world great if you don't need collisions, are writing your own physics engine. This is not a polished way of doing things, so will avoid it.
Please correct anything I have already done and tell me how it would work, or shed light on other options and how to implement them.
Check out my answer here. It's for box2d, but you can do it with Chipmunk. If bodyA position will change, orbit will be same. You just need to change speed of body movement for your needs, just increase smoothness and slow down your update method.
I am making a simple 3D OpenGL game. At the moment I have four bounding walls, a random distribution of internal walls and a simple quad cube for my player.
I want to set up collision detection between the player and all of the walls. This is easy with the bounding walls as i can just check if the x or z coordinate is less than or greater than a value. The problem is with the interior walls. I have a glGenList which holds small rectangular wall segments, at the initial setup i randomly generate an array of x,z co ordinates and translate these wall segments to this position in the draw scene. I have also added a degree of rotation, either 45 or 90 which complicates the collision detection.
Could anyone assist me with how I might go about detecting collisions here. I have the co ordinates for each wall section, the size of each wall section and also the co ordinates of the player.
Would i be looking at a bounded box around the player and walls or is there a better alternative?
I think your question is largely about detecting collision with a wall at an angle, which is essentially the same as "detecting if a point matches a line", which there is an answer for how you do here:
How can I tell if a point belongs to a certain line?
(The code may be C#, but the math behind it applies in any language). You just have to replace the Y in those formulas for Z, since Y appears to not be a factor in your current design.
There has been MANY articles and even books written on how to do "good" collision detection. Part of this, of course, comes down to a "do you want very accurate or very fast code" - for "perfect" simulations, you may sacrifice speed for accuarcy. In most games, of the players body "dents" the wall just a little bit because the player has gone past the wall intersection, that's perhaps acceptable.
It is also useful to "partition the space". The common way for this is "Binary space partitioning", which is nicely described and illustrated here:
http://en.wikipedia.org/wiki/Binary_space_partition
Books on game programming should cover basic principles of collision detection. There is also PLENTY of articles on the web about it, including an entry in wikipedia: http://en.wikipedia.org/wiki/Collision_detection
Short of making a rigid body physics engine, one could use point to plane distance to see if any of the cubes corner points are less than 0.0f away from the plane (I would use FLT_MIN so the points have a little radius to them). You will need to store a normalized 3d vector (vector of length 1.0f) to represent the normal of the plane. If the dot product between the vector from the center of the plane to the point and the plain normal is less than the radius you have a collision. After that, you can take the velocity (the length of the vector) of the cube, multiply it by 0.7f for some energy absorption and store this as the cubes new velocity. Then reflect the normalized velocity vector of the cube over the normal of the plane, then multiply that by the previously calculated new velocity of the cube.
If you really want to get into game physics, grab a pull from this guys github. I've used his book for a Physics for games class. There are some mistakes in the book so be sure to get all code samples from github. He goes through making a mass aggregate physics engine and a rigid body one. I would also brush up on matrices and tensors.
I d like to make my Camera shake in opengl
my old algorithm is:
setCamPosXYZ(x+randx,y+randy,z+randz);
but it is not the best. What is a better solution, a real world camera shake?
I have found a sin function with a high frequency and a gradually decreasing amplitude looks very convincing. If you want it to appear more random you can have different frequencies for each direction and it will bounce around more randomly. A sin function is also makes sense physically because if you think of the camera being mounted on a very stiff spring with some damping, then it's going to oscillate like a damped sin curve.
Generate x+randx,y+randy,z+randz
and then animate smoothly (liner interpolation) between existing camera pos
and x+randx,y+randy,z+randz
for a smooth shake.
To animate smoothly set your new
x at each time step to xinitial + k(randx)
Once you reach the random shake point generate a new random point and again animate
using linear interpolation
A real world camera shake is a reaction to some force, like a bumb or a shockwave, so it's a movement in one direct, then a countermovement in the other direction, moving back and forth until it stabilises.
So start with a sinus wave that dissipates, and then you might add some random to this to make it a bit more jerky.
Also, you should add a slight rotation of the camera along with the movement.
I'm developing a game that basically has its entire terrain made out of AABB boxes. I know the verticies, minimum, and maximum of each box. I also set up my camera like this:
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glRotatef(Camera.rotx,1,0,0);
glRotatef(Camera.roty,0,1,0);
glRotatef(Camera.rotz,0,0,1);
glTranslatef(-Camera.x,-Camera.y,-Camera.z);
What I'm trying to do is basically find the cube the mouse is on. I thought about giving the mouse position a forward directional vector and simply iterating through until the 'mouse bullet' hits something. However this envolves interating through all objects several times. Is there a way I could do it by only iterating through all the objects once?
Thanks
This is usually referred to as 'picking' This here looks like a good gl based link
If that is tldr, then a basic algorithm you could use
sort objects by z (or keep them sorted by z, or depth buffer tricks etc)
iterate and do a bounds test, stopping when you hit the first one.
This is called Ray Tracing (oops, my mistake, it's actually Ray Casting). Every Physics engine has this functionality. You can look at one of the simplest - ODE, or it's derivative - Bullet. They are open-source so you can take out what you don't need. They both have a handy math library that handles all oftenly needed matrix and vertex operations.
They all have demos on how to do exactly this task.
I suggest you consider looking at this issue from a bigger perspective.
The boxes are just points at a lower resolution. The trick is to reduce the resolution of the mouse to figure out which box it is on.
You may have to perform a 2d to 3d conversion (or vice versa). In most games, the mouse lives in a 2d coordinate world. The stuff "under" the mouse is a 2d projection of a 3d universe.
You want to use a 3D picking algorithm. The idea is that you draw a ray from the user's position in the virtual world in the direction of the click. This blog post explains very clearly how to implement such an algorithm. Essentially your screen coordinates need to be transformed from the screen space to the virtual world space. There's a website that has a very good description about the various transformations involved and I can't post the link due to my rank. Search for book of hook's mouse picking algorithm [I do not own the site and I haven't authored the document].
Once you get a ray in the desired direction, you need to perform tests for intersection with the geometries in the real world. Since you have AABB boxes entirely, you can use simple vector equations to check which geometry intersects the ray. I would say that approximating your boxes as a sphere would make life very easy since there is a very simple sphere-ray intersection test. So, your ray would be described by what you obtain from the first step (the ray drawn in the first step) and then you would need to use an intersection test. If you're ok with using spheres, the center of the sphere would be the point you draw your box and the diameter would be the width of your box.
Good Luck!