I made a skybox in opengl using five textures on five quads, the problem is that the lines(boarders) between the textures are visible:
How do you get of those lines?
GL11.glBegin(GL11.GL_QUADS);
GL11.glTexCoord2f(0.0f, 1.0f);
GL11.glVertex3f(-15.0f,-14.0f,-15.0f);
GL11.glTexCoord2f(1f, 1.0f);
GL11.glVertex3f(15.0f,-14.0f,-15.0f);
GL11.glTexCoord2f(1f, 0f);
GL11.glVertex3f(15.0f,16.0f,-15.0f);
GL11.glTexCoord2f(0.0f, 0f);
GL11.glVertex3f(-15.0f,16.0f,-15.0f);
GL11.glEnd();
This is one quad of the skybox, should it be done differently?
I had the same problem in OpenSceneGraph and adapted the OpenGL solution, which should be pretty straight forward. Basically just use glEnable(GL_TEXTURE_CUBE_MAP_SEAMLESS) when your program starts before you start your rendering loop and the lines should disappear.
There was some ambiguity in my research, and it is possible that the enum is actually GL_TEXTURE_CUBEMAP_SEAMLESS, but one or the other should work for you. It is a bit more complicated in OSG because you need to #define GL_TEXTURE_CUBE_MAP_SEAMLESS 0x884F then enable seamless cubemapping by using state->setMode(GL_TEXTURE_CUBE_MAP_SEAMLESS, osg::StateAttribute::ON), where state is a state set from the root of your scene graph.
I hope this helps, it worked for me.
Related
According to this wikibook it used to be possible to draw a simple rectangle as easily as this (after creating and initializing the window):
glColor3f(0.0f, 0.0f, 0.0f);
glRectf(-0.75f,0.75f, 0.75f, -0.75f);
This is has been removed however in OpenGL 3.2 and later versions.
Is there some other simple, quick and dirty, way in OpenGL 4 to draw a rectangle with a fixed color (without using shaders or anything fancy)?
Is there some ... way ... to draw a rectangle ... without using shaders ...?
Yes. In fact, AFAIK, it is supported on all OpenGL versions in existence: you can draw a solid rectangle by enabling scissor test and clearing the framebuffer:
glEnable(GL_SCISSOR_TEST);
glScissor(x, y, width, height);
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
This is different from glRect in multiple ways:
The coordinates are specified in pixels relative to the window origin.
The rectangle must be axis aligned and cannot be transformed in any way.
Most of the per-sample processing is skipped. This includes blending, depth and stencil testing.
However, I'd rather discourage you from doing this. You're likely to be better off by building a VAO with all the rectangles you want to draw on the screen, then draw them all with a very simple shader.
I want to draw a 4pointed star using GLUT and openGL in C++. Here is my code
glBegin(GL_TRIANGLE_FAN);
glVertex3f(0.0f,6.0f,0.0f);
glVertex3f(1.0f,4.0f,0.0f);
glVertex3f(3.0f,3.0f,0.0f);
glVertex3f(1.0f,2.0f,0.0f);
glVertex3f(0.0f,0.0f,0.0f);
glVertex3f(-1.0f,2.0f,0.0f);
glVertex3f(-3.0f,3.0f,0.0f);
glVertex3f(-1.0f,4.0f,0.0f);
glEnd();
The problem is the shape directly goes to 3,3 from 0,6
can anyone help me how to fix this,
screenshot
I want something like this
desired output
The 1st point of the the GL_TRIANGLE_FAN primitiv is always held fixed (See Triangle primitives). Just start the GL_TRIANGLE_FAN primitiv at one of the "inner" points:
glBegin(GL_TRIANGLE_FAN);
glVertex3f(1.0f,4.0f,0.0f);
glVertex3f(3.0f,3.0f,0.0f);
glVertex3f(1.0f,2.0f,0.0f);
glVertex3f(0.0f,0.0f,0.0f);
glVertex3f(-1.0f,2.0f,0.0f);
glVertex3f(-3.0f,3.0f,0.0f);
glVertex3f(-1.0f,4.0f,0.0f);
glVertex3f(0.0f,6.0f,0.0f);
glEnd();
You are creating a triangle fan but setting its central vertex (the initial one) at 0,6,0.
You probably want to change your geometry so that your central vertex is at the origin (for symmetry). It also works to move the first vertex down to the bottom as #Rabbid76 shows.
I just started loading some obj files and render it with opengl. When I render these meshes I get this result (see pictures).
I think its some kind of depth problem but i cant figure it out by myself.
Thats the parameters for rendering:
// Dark blue background
glClearColor(0.0f, 0.0f, 0.4f, 0.0f);
// Enable depth test
glEnable( GL_DEPTH_TEST );
// Cull triangles which normal is not towards the camera
glEnable(GL_CULL_FACE);
I used this Tutorial code as template. https://code.google.com/p/opengl-tutorial-org/source/browse/#hg%2Ftutorial08_basic_shading
The problem is simple, you are doing FRONT or BACK culling.
And the object file contains CCW(Counter-Clock-Wise) or CW (Clock-Wise) cordinates, so written from left to right or right to left.
Your openGL code is expecting it in the other way round, so it hides the surfaces which you are looking backward on.
To check this solves your problem, just take out the glEnable(GL_CULL_FACE);
As this exactly seems to be producing the problem.
Additionally you can use glCullFace(ENUM); where ENUM has to be GL_FRONT or GL_BACK.
If you don't in at least one of both cases can't see your mesh (means in both cases: GL_FRONT or GL_BACK your just seeing the partial mesh) , thats a problem with your code of interpreting the .obj. or the .obj uses not strict surface vectors. (A mix of CCW and CW)
I am actually unsure what you mean, however glEnable(GL_CULL_FACE); and then GL_CULL_FACE(GL_BACK); will cull out or remove the back face of the object. This greatly reduces the lag while rendering objects, and only makes a difference if you are inside or "behind" the object.
Also, have you tried glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); before your render code?
I try to use the following code to draw a square-shaped pixel with opengl
glPointSize(5.0f);
glBegin(GL_POINTS);
glVertex3f(1.0f, 1.0f, 1.0f);
glEnd();
However, the final result is a circle-shaped pixel.
Please take a look the reference http://risknfun.com/compform/w1.html
See the "Problem 4. A Grid". On the right side, the display image has square-shaped pixel.
It's partly up to the OpenGL implementation (i.e., it can vary with your graphics driver), but with a bit of luck, you can turn this on or off with glEnable(GL_POINT_SMOOTH); or glDisable(GL_POINT_SMOOTH); With point smoothing turned on, you'll normally get round points, but with it turned off you'll get square points.
You can also try to tell OpenGL not to spend time making GL_POINTS nice and round by calling:
glHint(GL_POINT_SMOOTH_HINT, GL_FASTEST);
But keep in mind that's just an hint. The OpenGL driver has ultimately the last word.
My cube isn't rendering as expected when I use GL_BLEND.
glEnable(GL_CULL_FACE);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE);
I'm also having a similar problem with drawing some semi-opaque vertices in front, which could well be related.
Related: Why do my semi-opaque vertices make background objects brighter in OpenGL?
Here's what it's supposed to look like:
Normal cube http://img408.imageshack.us/img408/2853/normalcube.png
And here's what it actually looks like:
Dark cube http://img7.imageshack.us/img7/7133/darkcube.png
Please see the code used to create the colored cube, and the code used to actually draw the cube.
The cube is being drawn like so:
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glPushMatrix();
glLoadIdentity();
// ... do some translation, rotation, etc ...
drawCube();
glPopMatrix();
// ... swap the buffers ...
You could try disabling all lighting before drawing the cube:
glDisable(GL_LIGHTING);
It looks like you have lighting enabled on the second one,
try with a glShadeModel( GL_FLAT ) before drawing,
This has me stomped. What it looks like is that some vertices have some alpha values that are non-opaque. However the code you posted has all 1. for alpha. So... in order to debug more, did you try to change your clear color to something non-black ? Say green ?
From the code, I doubt lighting is turned on, since no normals were specified.
Last comment, offtopic... You should really not use glBegin/glEnd (2 function calls per vertex + 2 per primitive is really not a good usage of the recent developments in OpenGL). Try glDrawElements with QUAD_LIST, or even better, TRIANGLE_LIST. You already have the data nicely laid out for that.