Tag Info

New answers tagged

0

For first picture: We are creating projection matrix. For example, the parameters used are: Left1, Right1, Bottom1, Top1, Near1, Far1. Here, Aspect_Ratio_1A = (Right1 - Left1) / (Top1 - Bottom1); Then we are doing a view port transformation. For example, the parameters used are: Width1, Height1. (I am not mentioning shift parameters for simplicity). Here, ...


6

How are you passing your normals to the vertex shader? It looks like those are the normals for each of the six faces of a cube, but the vertex shader operates on vertices, not faces. Unless you're doing something unusual, you need to specify a normal for each vertex. In addition, if you want a cube to look right, you will need 24 vertices rather than 8, so ...


2

You can explicitly get those numbers from id = glGetAttribLocation(program, name); after linking; the name is the string that appears in the vertex shader for the attribute. For example if you passed "vertexPosition" for name then you would get 0. If the layout information is not in the shader then openGL will create a default layout (usually in order as ...


4

Absolutely, But not as simple as taking a return value of a normal function. First I assume your question isn't about sharing variables between two shader stages (vertex, fragment..etc) but actually between two shader (programs). Shaders are part of the rendering pipeline, every input/output should pass through the rendering pipeline and its memory is ...


3

You don't need to call glVertexAttribPointer for the indexes; the indexes are found from the bound GL_ELEMENT_ARRAY_BUFFER during the drawElements call (which is saved in the VAO state IIRC). However indexes start from 0 so the contents of your index buffer are flawed they should be: {0,1,2,2,3,0}


1

The positions and color (and all other vertex attributes) all use the same index buffer, there is no way to change that. So if you have an index X then that vertex will have the position at index X and the color at index X. The size parameter indicates how many values to take (1 to 4). Sometimes positions are stored in the homogenic format (essentially add ...


2

What you essentially want is the depth in camera coordinates, but relative to model, not camera. the easiest way to achieve that is to calculate the position of the origin of a model coordinate system in camera coordinates. ... vec4 cs_position = glModelViewMatrix * gl_Vertex; vec4 origin_position = glModelViewMatrix * vec4(0,0,0,1); distToOrigin = ...


1

calculate a bounding volume of the object (sphere, convex hull, box - depends on your speed/accuracy needs), this needs to be done only once - at initalization while rendering, for each object: transform camera (origin, direction) to object space project bounding volume on camera direction axis and subtract camera origin projection to retrieve min/max ...


0

I managed to find out what my problem was. The "smooth" keyword. Vertex shader: ... in float in_fl; flat out int FL; void main(void) { FL = int(in_fl); ... Fragment shader: ... flat in int FL; ... So now I have a red, a blue and a green square, as I wanted. Anyway thanks for any help.


2

To succinctly answer the "why" question, it's because a 4x4 matrix can describe rotation, translation, and scaling operations all at once. Being able to describe any of these in a consistent manner simplifies a lot of things. Different kinds of transformations can be more simply represented with a different mathematical operations. As you note, ...


0

You can't just generate the points in a grid and hope OpenGL figures our what you want. When you use glDrawArrays you need to pass the whole triangles (or whatever primitive you're drawing) to it. So either change your loop to: for( int y=0;y<height-1;y++ ) { for( int x=0;x<width-1;x++ ) { vertices.push_back( glm::vec3( y,heightMap[x][y],x ...


1

Yes, this is a fine approach - it will be orders of magnitude faster than creating a primitive per data point. Assuming single-channel data, you should use whatever DXGI_FORMAT (or equivalent in OGL) maps to your source data, and convert in the pixel shader. There are native types for 8, 16, and 32-bit integers, as well as 32-bit floats. You should also ...


1

I agree with what v.oddou said. An extra point, changing the number of inputs of the shader can be thought of as changing an interface of a function, they are not strictly the same but the concept applies. So expect by default a recompile for your shaders to add more input streams, you also need to modify your code to pass those streams. You can use #define ...


2

In DirectX this is called the input signature. In older version of DX (DX9) you could skip to plug a stream-source, and then all unplugged things in the shader would default to zero value. (zero value filled from void by the pipeline). I would suppose OpenGL also does this kind of things. Note the newer versions of the graphics libraries (DX10+) do not ...


0

I'm not quite sure whether I understand you correctly, but you can assign different buffer objects to different attributes. The buffer object currently bound while calling glVertexAttribPointer will be used as the data source: If a non-zero named buffer object is bound to the GL_ARRAY_BUFFER target (see glBindBuffer) while a generic vertex attribute ...


0

The specification for GL_ARB_vertex_array_object is clear on this: ...client memory cannot be accessed through a non-zero vertex array object... However, there is a workaround for you here. You can use use VAOs for everything else, but just bind VAO 0 and then issue the full set of glVertexAttribPointer calls (i.e referencing both buffer objects and ...


0

It would appear that mixing VAOs with glVertexAttribArray() calls where the latter does not use a VBO does not work and emits no OpenGL errors. This means that if you decide to use VAOs then all glVertexAttrbArray() calls must be made to a corresponding VBO.


3

glClearColor expects color values to be in 0 .. 1 range, everything outside of this range gets clamped to it. In your case numbers are getting clamped to (1, 1, 0, 0) which is indeed yellow. Try setting glClearColor(60/255.0, 181/255.0, 0.0, 0.0); instead.


3

The following code should work: var points = new float[] { 0.0f, 0.5f, 0.0f, 0.5f, -0.5f, 0.0f, -0.5f, -0.5f, 0.0f }; int vbo = GL.GenBuffer(); GL.BindBuffer(BufferTarget.ArrayBuffer, vbo); GL.BufferData(BufferTarget.ArrayBuffer, points.Length * sizeof(float), points, BufferUsageHint.StaticDraw); ...


0

The gl*Pointer calls will store the currently bound buffer object and use it as the data source no matter what buffer object is bound during glDrawArrays and other draw calls. So as long as you unbind the buffer object before you call glVertexAttribPointer it will interpret its source argument as an absolute address instead of an offset into a buffer ...


2

I'm not sure if I should just delete the question since I solved it on my own or if I should leave it up for others to see in case they have the same problem. For now I am going to add my edit to this as an answer but if I should just delete the entire question let me know! I'm relatively new to Stack Exchange and am not really sure. The problem with the ...


3

The only apparent error in your code is that you seem to specifying 4 mip-levels, from level 0 to level 3, however, you set GL_TEXTURE_MAX_LEVEL to 4. The max level is the zero-based index of the last mip-level, so in this case, it should be 3: glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 3);


3

I did finally figure out a solution - actually a few different solutions. I did not figure out the actual cause of the artifact from a graphics programming perspective - but I did find some solutions. As I previously stated in my question, it appeared that the artifact was only occurring on the pre-computed shadow volumes of the worldspawn static geometry ...


2

It could very well be a floating pointer precision error, since Doom used floats for the rendering (mainly an OpenGL limitation). However, fiddling around tr_stencilshadow.cpp, I've noticed this comment which might be related to the issue (inside PointsOrdered() function): // vectors that wind up getting an equal hash value will // potentially cause a ...


0

I had to call glUseProgram(program) before glUniformMatrix4fv() or any other uniform call.


1

if a normal was previously assigned to the same vertex, average it with the newly calculated value Let's say you have normals n1, n2 and n3 that you want to add to a vertex. The vertex's normal shall be N; Your method: apply n1: N = n1; apply n2: N = ( N + n2 ) / 2. So, N = ( n1 + n2 ) / 2. It's still fine until now. apply n3: N = ( N + n3 ) / 2. Let's ...


6

No. If you request a buffer store (via glBufferData) larger than the implementation can satisfy, you'll get a GL_OUT_OF_MEMORY error. Buffers may be temporarily (or permanently) backed by CPU memory depending on their state, but a overly-large buffer store will never overflow out of GPU memory into CPU memory. To handle the large volume of data you're ...


1

Your shader, vertex structure, and glVertexAttribPointer calls do not agree. This tends to cause unusual behavior because you're mapping unexpected values to the GPU pipeline. Your vertex structure says you have a 3-vector for position, a 2-vector for for texture coordinates, and a 3-vector for the normal (a total of eight floats per vertex). Your ...


0

I like simple. If GLEW loaded correctly, this extension will be valid function pointer. Otherwise it will be null. if(wglCreateContextAttribsARB) wglCreateContextAttribsARB(hDC, hRC, &attribs)


0

I found the solution, I had to change this line: glm::mat4 MVP = Model * ViewProj; To this line glm::mat4 MVP = ViewProj * Model; I made some research and it seems that in DirectX its the other way around.


0

The problem is your World matrix multiplication order. What you do is W = T * R * S; where W is the world transform, T is translation, R is rotation, and S is scaling. You should instead use: W = S * R * T. THis is because matrix multiplication is not commutative. Hope that helps.


3

glRotatef(GLfloat angle, Glfloat x, GLfloat y, GLfloat z); The Above function is what you need for your purpose. It " multiplies the current matrix by a rotation matrix", as the OpenGL documentation says. Here's how you use it- angle is the angle you want to rotate. (Duh.) The next three parameters define the axis around which you would like to rotate. You ...


1

As I understand from your question is that you to rotate the actual textures and not the polygon vertices. This can be done by modifying the Texture Matrix not the ModelView Matrix.(you're using fixed pipeline). In order to modify the texture matrix that actually transforms the UVs you need to enable it first. glMatrixMode(GL_TEXTURE); glLoadIdentity(); ...



Top 50 recent answers are included