Strange lighting issues; difference between SFML and GLFW

Started by
3 comments, last by 21st Century Moose 11 years ago

I recently got into OpenGL, trying to make a simple survival/exploration game just for fun. I'm using C++ with GLEW. I started off using SFML 2.0 for context creation, since it was pretty well documented and had the necessary features. However, I ran into some problems using SFML, and I switched to GLFW. At the same time I decided to organize my code and make it object oriented. I now have some issues getting some simple Phong lighting to work correctly. Using the exact same GLSL shader code, I receive completely different lighting results using SFML and GLFW. Since the project using GLFW has been reorganized, I thought I may have messed something up somewhere, but I just can't find anything. I've tried using a number of different lighting algorithms and variations.

Here are screenshots comparing the same scene.

GLFW: [attachment=14390:glfw.png],

SFML: [attachment=14391:sfml.png]

Apart from the GLFW scene being significantly darker, the light just doesn't spread as much. There's also a weird pure white spotlight directly underneath the light. Finally, the SFML scene has hard edges, which is actually what I want for this game. With non-smoothed normals, the edges should always appear, right?

I attached all the source files for the two projects, including the shaders used. I included the code blocks project files in case you'd like to test the lighting yourself. Really appreciate any help. Thanks

Edit 5:04: OK, well I had the idea to basically use color information to display the normal values. Needless to say for GLFW version, they are horribly wrong. It's clear that my program is passing the shader bad normal values. I'll need to look more closely at that aspect of my program.

Edit 5:23: The normal buffer was somehow not bound when I called glDrawArrays. The change that made the difference was calling glBindBuffers on the normal buffer just before glDrawArrays. Can someone clarify the order of operations on binding buffers? I've seen all sorts of different ways to do it in tutorials. I wasn't binding the buffers on the uv and vertex buffers every frame, but they were obviously being passed to the shaders fine. So why was the normal buffer NOT bound?

Advertisement

Can someone clarify the order of operations on binding buffers? I've seen all sorts of different ways to do it in tutorials. I wasn't binding the buffers on the uv and vertex buffers every frame, but they were obviously being passed to the shaders fine. So why was the normal buffer NOT bound?

The buffer needs to be bound at the time you call glNormalPointer(). After that you can bind whatever you like, and it won't affect the normals.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Do glVertexAttribPointer() and glBindBuffer() need to be called every frame then? Because I was binding it correctly once, but the normals only showed up once I called both of those every frame.

Do glVertexAttribPointer() and glBindBuffer() need to be called every frame then? Because I was binding it correctly once, but the normals only showed up once I called both of those every frame.

They will stick around till you change them. If you are only rendering a single model, you can set them once at the beginning of your program.

More realistically, you will be rendering multiple models, and you will need to call them once for each model, each frame.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Do glVertexAttribPointer() and glBindBuffer() need to be called every frame then? Because I was binding it correctly once, but the normals only showed up once I called both of those every frame.

They will stick around till you change them. If you are only rendering a single model, you can set them once at the beginning of your program.

More realistically, you will be rendering multiple models, and you will need to call them once for each model, each frame.

...or put them in a VAO.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

This topic is closed to new replies.

Advertisement