I am using JOGL with OpenGL. I'm drawing everything through display lists. I'm trying to figure out how to specify materials.
I've been looking at this documentation. The following looks pretty straightforward:
glPushMatrix();
glTranslatef (-1.25, 3.0, 0.0);
glMaterialfv(GL_FRONT, GL_AMBIENT, no_mat);
glMaterialfv(GL_FRONT, GL_DIFFUSE, mat_diffuse);
glMaterialfv(GL_FRONT, GL_SPECULAR, mat_specular);
glMaterialfv(GL_FRONT, GL_SHININESS, low_shininess);
glMaterialfv(GL_FRONT, GL_EMISSION, no_mat);
auxSolidSphere();
glPopMatrix();
How can I do this with display lists? Without them, my app is way too slow.
Put the glMaterial calls into your display list.
int displayList = glGenLists(1);
glNewList(displayList, GL_COMPILE);
FloatBuffer ambient = BufferUtils.createFloatBuffer(4);
ambient.put(1.0f); // red
ambient.put(0.0f); // green
ambient.put(0.5f); // blue
ambient.put(1.0f); // alpha
ambient.flip(); // now OpenGL can read the buffer
glMaterial(GL_FRONT, GL_AMBIENT, ambient);
// put other material properties here
// put glVertex/glColor calls here
glEndList();
First, you should realize that, depending on your hardware, there's no guarantee that using a display list will make even a slight difference in speed. The currently-favored solution would be to use a vertex buffer object instead.
As far as doing it with a display list goes, it's pretty straightforward. You basically just do your drawing to the display list, then when you want to display something you tell it to play the display list with glCallList. There are some operations you can't put into a display list, but at least if memory serves (though it may not -- I haven't used lists in a while now) you can put glMaterialfv into a display list just fine.
Related
I have two simple questions:
First question:
Given is an object in OpenGL in an android application.
I want to apply phyics on the object like Gravtiy.
For this I've implemented a Public PositionVector {x,y,z,1.0f};
In the Object Object. So for example: Sphere.PositionVector = {0f,0f,0f,1f}
for the center of screen.
When I do the movement now, I have a modelMatrix and to update the Position should I multiply the modelMatrix with the PositionVector? But then I will still get 0,0,0,1.
mulitplyMV(tempVector,0,modelMatrix,0,PositionVector,0);
Where is the mistake? Or: What is the usual way to do this?
My goal is to have always the current positionvector of the Sphere.
Second question:
Does the shader have to do anything with the physics? Or may I calculate the gravtiy and the resulting vectors in the javaCode and apply then a translateMatrix to the modelMatrix?
Greetings,
Phil
So the first thing that really jumped out at me, was the question about movement. Normally if the movement was only for a visual effect, multiplying your position with a model matrix would be fine, but obviously you'll be wanting to handle collisions and that sort of thing as well.
What I normally do, is I keep track of each objects position, and update that value whenever it moves. When I draw my object, I first do a pass to leave out all objects that aren't in view and then only draw what my camera is seeing. So in this case, you'll only be drawing what is actually visible on the phone's screen at the moment.
So if you have a view matrix for your camera, to keep it simple for now you can leave out view culling, but you'll multiply your objects current position with the model matrix(in this case it is just an identity so it doesn't have any impact), and additionally with the view matrix and projection matrix. So its something like vec3 viewSpacePosition = projectionMatrix * viewMatrix * modelMatrix * position; (assuming I'm remembering that one correctly.)
Your physics calculations can be done either in your shaders or in your java code, though I recommend doing it on the java side while still getting the hang of things. OpenCL and transform feedback buffers can be quite tricky when you're still learning how some of the stuff works.
For the physics portion of your code, I would highly recommend taking a look an Glen Fiedler's series on game physics, you can find it here.
If you have any more questions, or if there is something you're still uncertain of let me know. :) Good luck!
I have got a single object.
A heightmap.
(Ignore the flag and the water - We have imaginations, right? ;) )
However, the issue is that I display this as a single display list. Therefore, I cannot "check the distance" of the map from the player, nor make the map less detailed, because I am only able to treat the map as a single object.
I have tried using shaders, however these are too late in the pipeline to be able to affect performance (If I use a shader to cut out EVERYTHING in the entire game, the game still lags as if it has everything else).
So, how can I add a Continuous Level Of Detail to the terrain, before it is too late, without splitting it into a ton of different objects (And even that wouldn't work well)?
You can split your map up into squares that you can display independently and only create those mesh objects when the player comes close enough to potentially render, and only render when inside the sight of the player.
besides that you can use a tesselation shader to create the continuous level of detail. it involves drawing flat quads and using the control shader to say how many vertices must be drawn and the evaluation shader to displace them upwards based on the height map (that you pass in as a texture).
or to be radical you can create a flat mesh that is fine grained in the center and decreases in detail further out, then using the vertex shader you can displace the vertices with the height map, the center remains under the camera but you use the position of the camera to offset the sampled coordinates of the height map (and texture map)
(Sorry in advance, I'm not at my computer so I can't provide code)
I have a voxel based game, and I wanted to add in transparent textures, namely glass. I realized that transparent textures would throw things off (looking through other blocks), so I used my shaders to remove any alpha components lower than the alpha value of the glass texture. Currently, the glass has an alpha of 0.26 (coordinates range from 0 - 1), and it works fine. But, if I want to add some transparency to the glass instead of removing all transparency, I run into my old issue where you can see through the blocks behind the glass.
I read in a few places that I would need to sort my geometry from front to back. Does this still pertain to my situation even after using shaders? I use display lists, for each chunk in my world, should I keep two lists, one for opaque blocks and one for transparent? So when I render, I would do one pass and render the opaque lists, and then do another render pass, and render the chunks inversely and render the transparent list?
Or is there a better way to do this?
looking through blocks behind transparent geometry means you still have depth checking enabled meaning the blocks behind the glass didn't get rendered.
I read in a few places that I would need to sort my geometry from
front to back. Does this still pertain to my situation even after
using shaders?
yes you still need to sort, geometry shaders don't solve that issue
however you only need to sort the transparent geometry when you render them after the opaque geometry (after turning on alpha blending)
I am having some performance problems with OpenGL. I essentially want to create a grid of squares. I first tried to implement it where each square I would translate to where I want a square, then multiply the model and view matrix, pass it into the shader program and draw the square. I would do this for each square. After creating about 50 squares the frame rate would start to drop to less than what I desire.
I then tried a VBO method where I basically would generate a vertex buffer each time the squares change location. Frame rate increased dramatically with this approach, but I have too much latency when something changes because it has to regenerate all the vertex locations.
What I think I need is a matrix stack... I used opengl 1.1 before and would use push/pop. I don't really understand the concepts of what that was doing though and how to reproduce it. Does anyone know where a good example of a matrix stack is that I can use as an example? Or possibly just a good explanation for one?
You can check this tutorial, is basically doing the same you want to achieve, but with cubes instead of squares. It uses a VBO as well:
http://www.learnopengles.com/android-lesson-seven-an-introduction-to-vertex-buffer-objects-vbos/
About the matrices, in OpenGL ES 2.0 you don't have any matrix related functions anymore, but you can use the glmath library, which does the same (and much more):
http://glm.g-truc.net/
It's a header library, so you just need to copy it somewhere and include it where you need it.
I'm not sure if I completely understand your objective, but I guess you could copy the data of one square in the grapic card (using a VBO) and then repeatedly update the model matrix for every square.
The concept of a matrix stack makes sense if your squares have some kind of hierarchy between them (for instance, if one of them moves, the one to its left has to move accordingly).
You can imagine it as a skeleton made out of squares. If the shoulder moves, all the pieces in the arm will move as well (hands, fingers, and so on).
You can emulate that by using a matrix stack. You can create some kind of tree with all your squares, so that every square has a list of "descendants", which will apply the same transformation as the parent. then you can render recursively all the squares like that:
Apply transform to the root square(s)
Push the transform in a queue
Call the same render function for every child
Every child reads the matrix on the top of the queue, multiplies
it by its own transformation, push the new matrix on the queue and
calls the children
After that every child pops out the matrix they pushed before
Using the glmath is quite easy, you just need to create a queue (std:vector in this case) of matrices:
std::vector<glm::mat4> matrixStack;
And then for every child:
glm::mat4 modelMatrix = matrixStack.back();
glm::mat4 nodeTransform = /*apply your transform here*/
glm::mat4 new = modelMatrix * nodeTransform;
matrixStack.push_back(new);
/*Pass in the new matrix to the shader and call to glDrawArrays or whatever to render your square*/
for (every child) {
render();
}
matrixStack.pop_back();
For the drawing part, I guess you could bind the vertex array with the square vertices, and then update the model matrix in the shader for every child, before calling glDrawArrays.
I'm currently developing a game for android.
I have added buttons to allow the user to navigate the camera in the x-axis and zooming in and out.
To do this I'm using the following matrix code:
// c is the canvas..
Matrix m = c.getMatrix();
// Make sure that the ground is always at the bottom of the screen
m.setScale(zoom,zoom,0.0f,height);
m.preTranslate(camera_x, 0); // Change offset in x-direction
c.setMatrix(m);
This works on the emulator but gives me some weird results on my real device.
Can anyone tell me what's wrong with it? I find working with matrixes to be tricky, especially since there are many options available for the Matrix object (pre,post and set).
Thanks
The matrix you get from canvas.getMatrix() in a View's onDraw method already has some manipulations in it (to scale the view to your display size and translate the View's coordinates to the ViewRoot Surface coordinates.
By using matric.setScale(), rather than pre or postScale, you reset the matrix to the identity transform and then apply the scaling. This causes the initial transformation set up for onDraw to be lost. The matrix.preTranslate() is fine.
Alternatively, you could keep the setScale and use canvas.concat(m) to apply your matrix to the existing matrix.
(I can't keep the operation of pre and post applying transformations straight either.)