I have this camera that is set up with vecmath.lookatMatrix(eye, center, up).
The movement works fine, forwards, backwards, right, left, these work fine.
What does not seem to work fine is the rotation.
I am not really good at math, so I assume I may be missing some logic here, but I thought the rotation would work like this:
On rotation around the Y-axis I add/sub a value to the X value of the center vector.
On rotation around the X-axis I add/sub a value to the Y value of the center vector.
For example here is rotation to the right: center = center.add(vecmath.vector(turnSpeed, 0, 0))
This actually works, but with some strange behaviour. It looks like the higher the x/y of the center vector value gets, the slower the rotation. I guess it's because through the addition/substraction to the center vector it moves too far away or something similar, I would really like to know what is actually happening.
Actually while writing this, I just realized this can't work like this, because once I have moved around and rotated a bit, and for example I'm in "mid air", the rotation would be wrong....
I really hope someone can help me here.
Rotating a vector for OpenGL should be done using matrices. Linear movement can be executed by simply adding vectors together, but for rotation it is not enough just to change one of the coordinates... if that was the case, how'd you get from (X,0,0) direction to (0,X,0)?
Here is another tutorial, which is C++, but there are Java samples too.
There is a bit of math behind all this - you seem to be familiar with vectors, and probably have a 'feel' of them, which helps.
EDIT - if you are to use matrices in OpenGL properly, you'll need to familiarize yourself with the MVP concepts. You have something to display (the model) which is placed somewhere in your world (view) at which you are looking through a camera (projection).
A working solution to working with a free-flight camera with eye, center, up vectors was posted here:
Free Flight Camera - strange rotation around X-axis
Here is my problem,
I have 2 rectangles.
I want to detect collision between these 2 rectangles.
However one rectangle should be able to rotate around a given position(player midpoint,not constant).
My Problem is, that i don't know how to rotate this one Rectangle.
I would be grateful for any help.
Here is a sketch of my problem:
for a simple collision detection I had always rectangles:
playerrect = new Rectangle(playerposition.x,playerposition.y,playersizeX,playersizeY);
enemyrect = new Rectangle(enemyposition.x,enemyposition.y,enemysizeX,enemysizeY);
and this;
if(playerrect.overlaps(enemyrect)){.....}
and this was enough for me.
This time this noob needs the playerrect at various angles, like 5°,10°,15°.....
So I need something like
playerrect.setRotation
which is not available :).
Libgdx Rectangle can't do that unfortunately. If you want that kind of collision detection, the easier way would be using Box2d.
I've been wanting to write it for some time now... as a project for the university, I've written (with a friend) a game that needed good explosions & particles effects. we've encountered some problems, which we solved quite elegantly (I think), and I'd like to share the knowledge.
OK then, so we found this tutorial: Make a Particle Explosion Effect which seemed easy enough to implement using Java with JOGL. before I'll answer as to how exactly we implemented this tutorial, I'll explain how rendering is done:
Camera: is just an orthonormal basis which basically means it contains 3 normalized orthogonal vectors, and a 4th vector representing the camera position. rendering is done using gluLookAt:
glu.gluLookAt(cam.getPosition().getX(), cam.getPosition().getY(), cam.getPosition().getZ(),
cam.getZ_Vector().getX(), cam.getZ_Vector().getY(), cam.getZ_Vector().getZ(),
cam.getY_Vector().getX(), cam.getY_Vector().getY(), cam.getY_Vector().getZ());
such that the camera's z vector is actually the target, the y vector is the "up" vector, and position is, well... the position.
so (if to put it in a question style), how to implement a good particles effect?
P.S: all the code samples and in-game screenshots (both in answer & question) are taken from the game, which is hosted here: Astroid Shooter
OK then, lets look at how we first approach the implementation of the particles: we had an abstract class Sprite which represented a single particle:
protected void draw(GLAutoDrawable gLDrawable) {
// each sprite has a different blending function.
changeBlendingFunc(gLDrawable);
// getting the quad as an array of length 4, containing vectors
Vector[] bb = getQuadBillboard();
GL gl = gLDrawable.getGL();
// getting the texture
getTexture().bind();
// getting the colors
float[] rgba = getRGBA();
gl.glColor4f(rgba[0],rgba[1],rgba[2],rgba[3]);
//draw the sprite on the computed quad
gl.glBegin(GL.GL_QUADS);
gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3d(bb[0].x, bb[0].y, bb[0].z);
gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex3d(bb[1].x, bb[1].y, bb[1].z);
gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex3d(bb[2].x, bb[2].y, bb[2].z);
gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3d(bb[3].x, bb[3].y, bb[3].z);
gl.glEnd();
}
we've most of the method calls are pretty much understandable here, no surprises. the rendering is quite simple. on the display method, we first draw all the opaque objects, then, we take all the Sprites and, sort them (square distance from camera), then draw the particles, such that further away from the camera is drawn first. but the real thing we have to look deeper into here is the method getQuadBillboard. we can understand that each particle has to "sit" on a plane that is perpendicular to the camera position, like here:
the way to compute a perpendicular plane like that is not hard:
substruct particle position from camera position to get a vector that is perpendicular to the plane, and normalize it, so it can be used as a normal for the plane. now a plane is defined tightly by a normal and position, which we now have (particle position is a point that the plane goes through)
compute the "height" of the quad, by normalizing the projection of the camera's Y vector on the plane. you can get the projected vector by computing: H = cam.Y - normal * (cam.Y dot normal)
create the "width" of the quad, by computing W = H cross normal
return the 4 points / vectors: {position+H+W,position+H-W,position-H-W,position-H+W}
but not all sprites acts like that, some are not perpendicular. for instance, the shockwave ring sprite, or the flying sparks/smoke trails:
so each sprite had to give it's own unique "billboard".BTW, the computation of the smoke trails & flying sprites sparks was a bit of a challenge as well. we've created another abstract class, we called it: LineSprite. i'll skip the explanations here, you can see the code in here: LineSprite.
well, this first try was nice, but there was an unexpected problem. here's a screenshot that illustrates the problem:
as you can see, the sprites intersects with each other, so if we look at 2 sprites that intersects, part of the 1st sprite is behind the 2nd sprite, and another part of it, is infront the 2nd sprite, which resulted in some weird rendering, where the lines of the intersection are visible. note, that even if we disabled glDepthMask, when rendering the particles, the result would still have the lines of intersection visible, because of the different blending that takes place in each sprite. so we had to somehow make the sprites to not intersect. the idea we had was really cool.
you know all these really cool 3D street art?
here's an image that emphasizes the idea:
we thought the idea could be implemented in our game, so the sprites won't intersect each other. here's an image to illustrate the idea:
basically, we made all the sprites to be on parallel planes, so no intersection could take place. and it did not effected the visible data, since it stayed the same. from every other angle, it would look streched, but from the camera point of view, it still looked great. so for the implementation:
when getting 4 vectors representing a quad billboard, and the position of the particle, we need to output a new set of 4 vectors that represents the original quad billboard. the idea of how to do this, is explained great in here: Intersection of a plane and a line. we have the "line" which is defined by the camera position, and each of the 4 vectors. we have the plane, since we could use our camera Z vector as the normal, and the position of the particle. also, a small change would be in the comparison function for sorting the sprites. it should now use the homogeneous matrix, which is defined by our camera orthonormal basis, and actually, the computation is as easy as computing: cam.getZ_Vector().getX()*pos.getX() + cam.getZ_Vector().getY()*pos.getY() + cam.getZ_Vector().getZ()*pos.getZ();. one more thing we should notice, is that if a particle is out of the viewing angle of the camera, i.e. behind the camera, we don't want to see it, and especially, we don't want to compute it's projection (could result in some very weird and psychedelic effects...).
and all is left is to show the final Sprite class
the result is quite nice:
hope it helps, would love to get your comments on this "article" (or on the game :}, which you can explore, fork, and use however you want...)
I am trying to code a cessna flying around the world using the accelerometer with the min3D framework for android but the rotation is a bit weird.
I'm using this to apply the accelerometer rotation to the object:
cessna.rotation().x = rotX;
cessna.rotation().z = rotZ;
This works fine. I haven't figured out yet how to move in the direction of rotation (I think I have to use trigonometry).
I rotated the object with
cessna.rotation().y++;
just to test what will happen. At 180° the rotation around the x axis is mirrored. So the nose of the plane turns down instead of up.
I think I rotate the Objects around the world axis and not around the local axis from the object. How can I do this? I didn't find any documentation about the min3D framework in the internet :/ .
Thank you if you can help me.
(sorry for the bad English)
If you want to rotate around object local axis. Do this
(in pseudo code - you'll need to find similar functions in min3d)
Translate(object.pos.x,object.pos.y,object.pos.z);
object.rotation().x+=radians(45);// or whatever
if that doesn't work, try wrapping the above two lines in
pushMatrix()
...
popMatrix()
Or similar functions in min 3d to save and then restore the current camera rotation translation matrix.
Have you considered, Processing, which also comes with an Android 'output'?
So I have a 2d game which normally just has gravity and "flat" levels however I have added in "planets" which have their own gravity.
I have a function called addForce(float xForce, float yForce) that I use to move my character. So say if I called player.addForce(1, -1); the player would move up and to the right(albeit slightly). This worked fine on the levels with regular downward gravity, however with planets it is not so.
There is another float called earthAngle which is:
atan2(player.getY()-earth.getY(), player.getX()-earth.getX());
What I did for the jumping code on the planets is:
player.addForce(cos(earthAngle)*1500, sin(earthAngle)*1500);
which works well. However I am stuck on how to make the character walk around the planet.
Currently for the movement code I have:
player.addForce(25*x_*cos(earthAngle), 25+x_*sin(earthAngle));
which only works on some parts and works in reverse on the bottom as well as being stronger/weaker on some parts, x_ can be either -1(left) or 1(right). I'm guessing their is a really elegant solution I am just overlooking. Thanks.
Since you already have the vector from the center of the planet to the player eg (x,y), you can use a vector perpendicular to that (-y,x) as the direction for the walking force.