# Tag Info

14

Sorry folks for posting such a trivial issue! The issue is solved. I was using the wrong function. Here goes the correct one: glm::vec2 testVec(6,-4); float len = glm::length(testVec); The member function of the same name returns the number of components instead (i.e. vec2::length will always yield 2, vec3::length will always yield 3, etc.).

8

Rendering to different viewports (parts) of the same screen can be done as follows: For example splitting screen into four parts and rendering the same scene four times to each corner with different uniforms and different viewports: bindFramebuffer(); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); scene->setConstPerFrameUniforms(); //left bottom ...

7

If you are writing your own Vertex/Fragment Shader there is another additional possibility to do this. It is much more complicated but might be useful for you and/or others. Additionally it speeds up the whole drawing process since it uses only one call to a draw command. The maximum number of Viewports is defined by GL_MAX_VIEWPORTS and is usually 16. ...

5

This is a copy of @narthex's answer, except with only the viewports since that is all you need. I'm not sure why the frame buffer / blend stuff is included in his answer. //left bottom glViewport(0, 0, WindowWidth*0.5, WindowHeight*0.5); scene->draw(); //right bottom glViewport(WindowWidth*0.5, 0, WindowWidth*0.5, WindowHeight*0.5); scene->draw(); /...

4

Two symptoms There appear to be two problems with the image. The background is showing through along the line between adjacent triangles. The colour displayed is not always from the closest intersection. Note that the background colour is white, rather than black, due to the line: PutPixelSDL(screen, x, y, vec3(1, 1, 1)); Why this ...

4

It seems to me, to be that your different positions and normals are not in the same space. Having them in the same space is important because else it might think the normal is pointing left while it should point to the right. If you don't know what I mean with space in this context it's basically a coordinate system. Think about a grid, grid A. On grid A ...

3

I wasn't placing the lightposition into view space before passing it in. vec4 LightPosition_view=view*LightPosition; //put lp into view space with the rest When it comes to these things, you have to think in terms of spaces, and I was multiplying the view matrix and the model matrix, into view space, but not the lightposition itself. I hope that helps ...

1

I don't understand why, if I make the first argument to glm::lookAt be glm::vec3(0.0f, 0.0f, 2.0f), I see nothing. It's because of the up vector. If you think about the look-at operation, you specify where the camera is and what point it's looking towards. These two things alone leave one degree of freedom: the rotation around that axis. Which way is up on ...

1

You can calculate the world position of the pixel on near plane quite easily by first defining Normalized Device Coordinates (NDC) for the point and then transforming the NDC back to the world space. You can calculate NDC for your point as follows: $$v=[2*(x+0.5)/width-1, 1-2*(y+0.5)/height, 0, 1]$$ I'm using 0 here for the z-component assuming near-plane in ...

Only top voted, non community-wiki answers of a minimum length are eligible