Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 14 Jan 2011
Offline Last Active Today, 09:26 AM

#5165270 VBO and glIsBuffer

Posted by Sponji on 07 July 2014 - 09:08 AM

Sounds like there's no opengl context active when you try to call those opengl functions?

#5165034 Transparency Issue

Posted by Sponji on 06 July 2014 - 06:54 AM

The problem is basically that the triangles are not still sorted. For example, if you want one object which has two transparent boxes in it, how do you know which box of those will be drawn first? It will look weird depending on the viewing direction.

#5165021 Transparency Issue

Posted by Sponji on 06 July 2014 - 05:52 AM

You probably have depth writing enabled (glDepthMask), so when you draw the transparent quad first, it will write the depth for those transparent pixels. And now when you try to draw the other object behind it, it will skip the drawing the pixels because of depth testing (something is in front of the pixel). Simplest way to solve this is to render opaque objects first, then transparent objects from back to front. It still won't work for all kinds of shapes though.


Try changing the order you render, first the textured box and then the transparent thing.

#5162835 My Kingdom for a Link to a Past Post

Posted by Sponji on 25 June 2014 - 02:07 PM

Maybe this one, http://www.gamedev.net/topic/630721-mind-if-we-discuss-vbo-streaming/

#5156333 glFrontFace GL_CW vs. GL_CCW question

Posted by Sponji on 27 May 2014 - 01:44 PM

Now, mystery to me that that my points specified in clockwise order, but I see my square as white.

CCW = counterclockwise


Try drawing the vertex positions on a paper, +x is to the right, +y is up, it's white when the order is counter clockwise.

#5152442 Calculating the Final Vertex Position with MVP Matrix and another Object'...

Posted by Sponji on 08 May 2014 - 08:20 PM

This is how I would do this stuff usually:
mat4 projection = camera->projection();
mat4 view = camera->view(); // should be same as inverse(camera->transform());
mat4 model = model->transform();

mat4 vp = projection * view;
mat4 mvp = vp * model;
mat4 mv = view * model;

mat3 normal_matrix = transpose(inverse(mat3(mv)));


For the child objects, you just multiply by the child's transform, so it goes like this:

mat4 mvp = vp * model0 * model1 * model2
mat4 mv = view * model0 * model1 * model2

#5134955 GLSL Lighting

Posted by Sponji on 27 February 2014 - 12:20 AM

glm::mat3* MV = new glm::mat3 (modelview[16]);
setUniform(m_shader, "normalMatrix", -glm::transpose(glm::inverse(*MV)));


Is there a reason you are using new there? You are also passing just one float to the mat3's constructor, and it's out of bounds.

I would suggest doing something like glm::transpose(glm::inverse(glm::mat3(modelview))). Also, I think you should normalize your normals after the loop where you calculate them.


You can use &matrix[0][0] or glm::value_ptr(matrix) to access a glm matrix, you don't have to use your own float arrays. But if you really want to, you can convert a float array to mat3 or mat4 with make_mat3 and make_mat4. Just include glm/gtc/type_ptr.hpp to get access to those functions.


Edit. I meant that modelview is glm::mat4. Also, maybe a better example code:

glm::mat4 modelview_matrix; 
glGetFloatv(GL_MODELVIEW_MATRIX, &modelview_matrix[0][0]);
glm::mat3 normal_matrix = glm::transpose(glm::inverse(glm::mat3(modelview_matrix)));
const float *pointer = glm::value_ptr(normal_matrix);

#5131681 Uptading parts of data in a VBO

Posted by Sponji on 16 February 2014 - 05:17 AM

Is there something wrong with creating separate buffers for positions and texture coordinates? This could help, https://www.opengl.org/wiki/Vertex_Specification_Best_Practices#Vertex.2C_normals.2C_texcoords


Maybe something like this:

// bind, update and set the pointer for positions
glBindBuffer(GL_ARRAY_BUFFER, position_buffer);

// bind, update and set the pointer for texture coordinates
glBindBuffer(GL_ARRAY_BUFFER, texcoord_buffer);

// bind index buffer
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, index_buffer);

// Draw

#5130596 first steps with enet

Posted by Sponji on 11 February 2014 - 01:28 PM

You don't have to flush all the time, enet_host_service will take care of all that sending and receiving. Just handle the network events with enet_host_service from your main loop.

#5130503 first steps with enet

Posted by Sponji on 11 February 2014 - 04:41 AM

enet_host_service handles flushing, but you can also call enet_host_flush to actually send your packets.

#5129898 C++ Win32 && OpenGL 3.3 Not Updating FrameBuffer and or Device Context?

Posted by Sponji on 08 February 2014 - 01:30 PM

Your triangle is also really small compared to your projection matrix.

#5128931 glm and perspective matrices

Posted by Sponji on 04 February 2014 - 11:51 PM

Normally, -Z means going towards the screen in OpenGL, so you probably want to change the vertices' z to -1. It's 1 now which means the triangle is behind you.


Edit. I think this helps a lot, http://www.songho.ca/opengl/gl_projectionmatrix.html

#5119781 Segfault with core profile context

Posted by Sponji on 29 December 2013 - 04:21 AM

For glGenVertexArrays, try setting glewExperimental = GL_TRUE before calling glewInit. And glGetString is not in the core profile, so you can't use it.


Edit. I read some stuff wrong.

#5116435 Snake 3D why does this work?

Posted by Sponji on 12 December 2013 - 01:19 AM

I would use real matrices instead of playing around with OpenGL's functions to modify the current matrix. It makes code much more cleaner and helps you later with newer OpenGL versions where you don't have those functions.


I would set the camera like this:

mat4 camera_transform = translate(snake.position) * rotate_x(angle) * translate(0, 0, distance);

Now the camera should be looking at the snake's position with the specified angle and distance.


Take the inverse of it to get the view matrix:

mat4 view_matrix = inverse(camera_transform);

And rendering could be done like this then:

// Load projection matrix

// Load view matrix

// Render an apple

Hope this helps.

#5116433 World Space Frustum Culling?

Posted by Sponji on 12 December 2013 - 01:05 AM

Inverse of the camera's world space transform is the view matrix. That inverse can be simplified by taking the transpose of the rotation part and negating the translation part.