Currently I'm using WebGL for a school project, and am stuck on trying to keep an object perpendicular to the camera while allowing rotation of the rest of the scene.
I currently have a cube and other object on the canvas, and they're being successfully rotated using a quaternion and converting that to a rotation matrix. I would now like to add a simple square within the scene, but have it consistently perpendicular to the camera.
In thinking about this, I've considered an approach using multiple vertex shader programs for the different objects in the scene: 1 for handling the positioning of all objects in the scene that can be rotated, and another vertex shader corresponding to the square that I don't want rotated.
Though, I really don't know if this approach will work as expected, as I am still a novice at WebGL.
Would there be a better approach to this? I greatly apologize if there's a lack of info given, and can give any more info if needed. I've searched quite a bit for something involving this, but have hit a dead end.
Thank you!
If you want a more step by step tutorial: http://www.opengl-tutorial.org/intermediate-tutorials/billboards-particles/billboards/.
Related
In OpenGL I created a simple cube that I rotate. I am rotating the cube, not the camera!
Then I added a light source. The light also rotates with the cube. How can I avoid this?
Can somebody tell me when to activate which matrix mode and when to push and pop the current matrix. I have tried many, many combinations and sequences, but the damn light always (!) follows the rotation.
I am not expecting a general answer that just says that has something to do with the matrix stack. A concrete short example of a rotating object with a non-rotating light would be great!
A probable reason why the light follows a rotating object is that there was defined no (suitable) normal vector for the object. Although the light and the movements of the objects are programmed correctly the wrong or no normal vectors can make the whole scene look like the light follows a rotating object.
Defining normal vectors for the objects, that determine how the light is reflected, can solve the problem.
I am trying to rotate over the 'x' axis and save the transformed matrix so that I can use it to rotate further later; or over another axis from the already rotated perspective.
//rotate
glRotatef(yROT,model[0],model[4],model[8]);//front over right axis
//save model
glGetFloatv(GL_MODELVIEW_MATRIX, model);
Unfortunately I noticed that openGL must buffer the transformations because the identity matrix is loaded to model. Is there a work-around?
Why, oh God, would you do this?
I have been toying around with attempting to understand quaternions, euler, or axis rotation. The concepts are not difficult but I have been having trouble with the math even after looking at examples *edit[and most of the open classes I have found either are not well documented for simpleton users or have restrictions on movement].
I decided to find a way to cheat.
edit*
By 'further later' I mean in the next loop of code. In other words, yRot is the number of degrees I want my view to rotate from the saved perspective.
My suggestion: Don't bother with glRotate at all, they were never very pleasant to work with in the first place and no serious program did use them ever.
If you want to use the fixed function pipeline (= no shaders), use glLoadMatrix to load whatever transformation you currently need. With shaders you have to do the conceptually same with glUniform anyway.
Use a existing matrix math library, like GLM, Eigen or linmath.h to construct the transformation matrices. The nice benefit is, that you can make copies of a matrix at any point, so instead of fiddling with glLoadIdentity, glPushMatrix and glPopMatrix you just make copies where you need them and work from them.
BTW: There is no such thing as "models" in OpenGL. That's not how OpenGL works. OpenGL draws points, lines or triangles, one at a time, where each such called primitive is transformed individually to a position on the (screen) framebuffer and turned into pixels. Once a primitive has been processed OpenGL already forgot about it.
Basically I'm writing a C++ program to draw objects in a world and I'm having some difficulty with lighting when I'm rotating/translating an object that consists of multiple objects (For example a tree object consists of a cylinder object for the trunk and pyramid objects for the leaves).
I have a working light source right now but I run into some issues when rotating a subcomponent of an object (like the pyramid object inside its parent, the tree).
All lighting/shading works when I apply a rotation to the tree object, but lighting gets wonky and random if I attempt to rotate the pyramid object inside the tree. I'm really hoping someone may have some tips or hints as to what I could be running into?
Edit: There are a lot of files with this project and it would be difficult to throw enough up here to give the entire picture. Essentially my steps are:
Set up a world with a functioning opengl light source.
Create a shape object which has a transformation matrix associated with it.
Using the shape and its matrix and calculate its normals to use for shading.
Now create a new shape object which consists of the other shape objects, and throw it in the world for the lighting to take effect.
Now the problem happens here. If I rotate the parent object, lighting is fine, but if I rotate the child object, lighting becomes random.
I found the problem in my code. I was updating the normals too frequently so opengl lighting had bad normals to work with.
Thanks for the help everyone!
I have an OpenGL scene in which the user can rotate the camera. I have some two dimensional shapes that I would like to always face the user. I do have the forward facing vector, and I do have the screen point at which the component should be drawn. I'm not sure the best way to approach this problem - should I be rotating the shape to the forward vector (which I'm not entirely sure how to do correctly)? Or is there another way I can just draw in two dimensions and ignore the rotation of the camera (maybe by using an orthographic projection)? Any sample code for helping with this would be appreciated.
PS - I'm doing this in Java, but the language is irrelevant here (it is just OpenGL specific).
I already answered it in Inverting rotation in 3D, to make an object always face the camera?
My first though is to use the "gluLookAt" matrix.
http://www.opengl.org/resources/faq/technical/viewing.htm
I would say, that you keep the position of the 2d objects, and then take the "eye" or camera position and set that as the target value for the 2d objects. It should keep them facing the camera.
I am currently working on designing my first FPS game using JOGL. (Java bindings for OpenGL).
So far I have been able to generate the 'world' (a series of cubes), and a player model. I have the collision detection between the player and the cubes working great.
Now I am trying to add in the guns. I have the gun models drawn correctly and loading onto player model. The first gun I'm trying to implement is a laser gun, which shoots and instantaneous line-of-sight laser at whatever you're aiming at. Before I work on implementing the enemy models, I would like to get the collision detection between the laser and the walls working.
My laser, currently, is drawn by a series of small cubes, one after the other. The first cube is drawn at the end of the players gun, then it draws continuously from there. The idea was to continue drawing the cubes of the laser until a collision was detected with something, namely the cubes in the world.
I know the locations of the cubes in the world. The problem is that I have to call glMatrixPush to draw my character model. The laser is then drawn within this modelview. Meaning that I have lost my old coordinate system - so I'm drawing the world in one system, then the lazer in another. Within this player matrix, I have go call glRotate and glTranslate several times, in order to sync everything up with the way the camera is rotating. The lazer is then built by translating along the z-axis of this new system.
My problem is that through all of these transformations, I no longer have any idea where my laser exists in the map coordinate system, primarily due to the rotations involving the camera.
Does anyone know of a method - or have any ideas, for how to solve this problem? I believe I need a way to convert the new coordinates of the laser into the old coordinates of the map, but I'm not sure how to go about undoing all of the transformations that have been done to it. There may also be some functionality provided by OpenGL to handle this sort of problem that I'm just unaware of.
You shouldn't be considering the laser as a spacial child of the character that fires it. Once its been fired, the laser is an entity of its own, so you should render as follows:
glPushMatrix(viewMatrix);
glPushMatrix(playerMatrix);
DrawPlayer();
glPopMatrix();
glPushMatrix(laserMatrix);
DrawLaser();
glPopMatrix();
glPopMatrix();
Also, be sure that you don't mix your rendering transformation logic with the game logic. You should always store the world-space position of your objects to be able to test for intersections regardless of your current OpenGL matrix stack.
Remember to be careful with spacial parent/child relationships. In practice, they aren't that frequent. For more information, google about the problems of scene graphs.
The point that was being made in the first answer is that you should never depend on the matrix to position the object in the first place. You should be keeping track of the position and rotation of the laser before you even think about drawing it. Then you use the translate and rotate commands to put it where you know it should be.
You're trying to do things backwards, and yes, that does mean you'll have to do the matrix math, and OpenGL doesn't keep track of that because the ModelView matrix is the ONLY thing that OpenGL does keep track of in regards to object positions. OpenGL has no concept of "world space" or "camera space". There is only the matrix that all input is multiplied by. It's elegantly simple... but in some cases I do prefer the way DirectX has a a separate view matrix and model matrix.
So, if you don't know where an object is located without matrix math, then I would consider that a fundamental design problem. If you don't need to know the object position, then matrix-transform to your hearts content, but if you do need it's position, start with the position.
(pretty much what the first answer says, just in a different way...)