Recommended Posts

Actually the issue is... i want to update/refresh the openGL screen without make it active. I mean to say....i don't want to click on the screen for the animation. The animation or refreshing of GLwindow should b automatically performed.

I made menu for changing some parameters and whenever i change any parameter, the screen/GLwindow doesn't update or refresh. When i click on the GLwindows with mouse then the window refreshes. I made slider a for changing parameter and i want to see the changing/updating of the 3D model as the slider move.

i tried to put glutPostRedisplay(); everywhere and check but it doesn't work for me...

what i need to do ? guide me...

Thanks.

0

Share this post

Link to post

Share on other sites

glutPostRedisplay only redisplays the current window. So either make the window active (see glutSetWindow), redisplay, and reset the current window to whatever was active before that. Or, if you have it, post it directly to the correct window with glutPostWindowRedisplay.

Similar Content

Hi everyone,
I would need some assistance from anyone who has a similar experience
or a nice idea!
I have created a skybox (as cube) and now I need to add a floor/ground.
The skybox is created from cubemap and initially it was infinite.
Now it is finite with a specific size. The floor is a quad in the middle
of the skybox, like a horizon.
I have two problems:
When moving the skybox upwards or downwards, I need to
sample from points even above the horizon while sampling
from the botton at the same time.
I am trying to create a seamless blending of the texture
at the points of the horizon, when the quad is connected
to the skybox. However, I get skew effects.
Does anybody has done sth similar?
Is there any good practice?
Thanks everyone!

Hi everyone,
I would need some assistance from anyone who has a similar experience
or a nice idea!
I have created a skybox (as cube) and now I need to add a floor/ground.
The skybox is created from cubemap and initially it was infinite.
Now it is finite with a specific size. The floor is a quad in the middle
of the skybox, like a horizon.
I have two problems:
When moving the skybox upwards or downwards, I need to
sample from points even above the horizon while sampling
from the botton at the same time.
I am trying to create a seamless blending of the texture
at the points of the horizon, when the quad is connected
to the skybox. However, I get skew effects.
Does anybody has done sth similar?
Is there any good practice?
Thanks everyone!

I'm trying to implement PBR into my simple OpenGL renderer and trying to use multiple lighting passes, I'm using one pass per light for rendering as follow:
1- First pass = depth
2- Second pass = ambient
3- [3 .. n] for all the lights in the scene.
I'm using the blending function glBlendFunc(GL_ONE, GL_ONE) for passes [3..n], and i'm doing a Gamma Correction at the end of each fragment shader.
But i still have a problem with the output image it just looks noisy specially when i'm using texture maps.
Is there anything wrong with those steps or is there any improvement to this process?

Hello Everyone!
I'm learning openGL, and currently i'm making a simple 2D game engine to test what I've learn so far. In order to not say to much, i made a video in which i'm showing you the behavior of the rendering.
Video:

What i was expecting to happen, was the player moving around. When i render only the player, he moves as i would expect. When i add a second Sprite object, instead of the Player, this new sprite object is moving and finally if i add a third Sprite object the third one is moving. And the weird think is that i'm transforming the Vertices of the Player so why the transformation is being applied somewhere else?

Hello fellow programmers,
For a couple of days now i've decided to build my own planet renderer just to see how floating point precision issues
can be tackled. As you probably imagine, i've quickly faced FPP issues when trying to render absurdly large planets.

I have used the classical quadtree LOD approach;
I've generated my grids with 33 vertices, (x: -1 to 1, y: -1 to 1, z = 0).
Each grid is managed by a TerrainNode class that, depending on the side it represents (top, bottom, left right, front, back),
creates a special rotation-translation matrix that moves and rotates the grid away from the origin so that when i finally
normalize all the vertices on my vertex shader i can get a perfect sphere.
T = glm::translate(glm::dmat4(1.0), glm::dvec3(0.0, 0.0, 1.0));
R = glm::rotate(glm::dmat4(1.0), glm::radians(180.0), glm::dvec3(1.0, 0.0, 0.0));
sides[0] = new TerrainNode(1.0, radius, T * R, glm::dvec2(0.0, 0.0), new TerrainTile(1.0, SIDE_FRONT));
T = glm::translate(glm::dmat4(1.0), glm::dvec3(0.0, 0.0, -1.0));
R = glm::rotate(glm::dmat4(1.0), glm::radians(0.0), glm::dvec3(1.0, 0.0, 0.0));
sides[1] = new TerrainNode(1.0, radius, R * T, glm::dvec2(0.0, 0.0), new TerrainTile(1.0, SIDE_BACK));
// So on and so forth for the rest of the sides
As you can see, for the front side grid, i rotate it 180 degrees to make it face the camera and push it towards the eye;
the back side is handled almost the same way only that i don't need to rotate it but simply push it away from the eye.
The same technique is applied for the rest of the faces (obviously, with the proper rotations / translations).
The matrix that result from the multiplication of R and T (in that particular order) is send to my vertex shader as `r_Grid'.
// spherify
vec3 V = normalize((r_Grid * vec4(r_Vertex, 1.0)).xyz);
gl_Position = r_ModelViewProjection * vec4(V, 1.0);
The `r_ModelViewProjection' matrix is generated on the CPU in this manner.
// No the most efficient way, but it works.
glm::dmat4 Camera::getMatrix() {
// Create the view matrix
// Roll, Yaw and Pitch are all quaternions.
glm::dmat4 View = glm::toMat4(Roll) * glm::toMat4(Pitch) * glm::toMat4(Yaw);
// The model matrix is generated by translating in the oposite direction of the camera.
glm::dmat4 Model = glm::translate(glm::dmat4(1.0), -Position);
// Projection = glm::perspective(fovY, aspect, zNear, zFar);
// zNear = 0.1, zFar = 1.0995116e12
return Projection * View * Model;
}
I managed to get rid of z-fighting by using a technique called Logarithmic Depth Buffer described in this article; it works amazingly well, no z-fighting at all, at least not visible.
Each frame i'm rendering each node by sending the generated matrices this way.
// set the r_ModelViewProjection uniform
// Sneak in the mRadiusMatrix which is a matrix that contains the radius of my planet.
Shader::setUniform(0, Camera::getInstance()->getMatrix() * mRadiusMatrix);
// set the r_Grid matrix uniform i created earlier.
Shader::setUniform(1, r_Grid);
grid->render();
My planet's radius is around 6400000.0 units, absurdly large, but that's what i really want to achieve;
Everything works well, the node's split and merge as you'd expect, however whenever i get close to the surface
of the planet the rounding errors start to kick in giving me that lovely stairs effect.
I've read that if i could render each grid relative to the camera i could get better precision on the surface, effectively
getting rid of those rounding errors.

My question is how can i achieve this relative to camera rendering in my scenario here?
I know that i have to do most of the work on the CPU with double, and that's exactly what i'm doing.
I only use double on the CPU side where i also do most of the matrix multiplications.
As you can see from my vertex shader i only do the usual r_ModelViewProjection * (some vertex coords).