Jump to content

  • Log In with Google      Sign In   
  • Create Account


Strange lighting issues; difference between SFML and GLFW


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 moldyviolinist   Members   -  Reputation: 181

Like
0Likes
Like

Posted 21 March 2013 - 02:47 PM

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: glfw.png ,

SFML: 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?

Attached Files

  • Attached File  glfw.zip   730.54KB   34 downloads
  • Attached File  sfml.zip   5.08MB   40 downloads

Edited by moldyviolinist, 21 March 2013 - 03:27 PM.


Sponsor:

#2 swiftcoder   Senior Moderators   -  Reputation: 9499

Like
0Likes
Like

Posted 21 March 2013 - 04:38 PM

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 - Software Engineer @Amazon - [swiftcoding]


#3 moldyviolinist   Members   -  Reputation: 181

Like
0Likes
Like

Posted 21 March 2013 - 06:11 PM

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.



#4 swiftcoder   Senior Moderators   -  Reputation: 9499

Like
0Likes
Like

Posted 22 March 2013 - 07:10 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.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#5 mhagain   Crossbones+   -  Reputation: 7328

Like
1Likes
Like

Posted 22 March 2013 - 09:11 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.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS