VBO - Strange black quad appears sometimes

[TheBoneJarmer]

A few FBO examples work, but most examples exit on startup with this error:

java.lang.NullPointerException: in is null
	at java.util.zip.ZipInputStream.<init>(ZipInputStream.java:101)
	at java.util.zip.ZipInputStream.<init>(ZipInputStream.java:80)
	at org.lwjgl.demo.opengl.util.WavefrontMeshLoader.readSingleFileZip(WavefrontMeshLoader.java:89)
	at org.lwjgl.demo.opengl.util.WavefrontMeshLoader.loadMesh(WavefrontMeshLoader.java:103)
	at org.lwjgl.demo.opengl.fbo.DepthEdgeShaderDemo20.createCube(DepthEdgeShaderDemo20.java:227)
	at org.lwjgl.demo.opengl.fbo.DepthEdgeShaderDemo20.init(DepthEdgeShaderDemo20.java:165)
	at org.lwjgl.demo.opengl.fbo.DepthEdgeShaderDemo20.run(DepthEdgeShaderDemo20.java:397)
	at org.lwjgl.demo.opengl.fbo.DepthEdgeShaderDemo20.main(DepthEdgeShaderDemo20.java:416)

But different than that, I tried some random examples from different demos and they seem to work just fine.

[Cornix]

It might be that there is some error somewhere else in your code. Something you just overlooked. But if both computers show different behavior then it becomes likely that it is indeed some problem with the driver. It might be that you are doing something illegal (by opengl rules) but your driver does not produce an error and instead shows garbage data. This happened to me once. I was passing invalid arguments to an OpenGL function and weird things started to happen. There was no error and nothing, the driver just went with the garbage data.

[Kai]

A few FBO examples work, but most examples exit on startup with this error:

You need to have the /res folder in the source/classpath.

[TheBoneJarmer]

A few FBO examples work, but most examples exit on startup with this error:

You need to have the /res folder in the source/classpath.

Thanks, that fixed it!

It might be that there is some error somewhere else in your code. Something you just overlooked. But if both computers show different behavior then it becomes likely that it is indeed some problem with the driver.

I do not know if I mentioned it earlier, but both graphic cards from the laptop I'm using right now and my previous one are from Intel. Different ones though but the same manufacturer. My current one shows less garbage data compared to my previous one. But they do show garbage data nonetheless.

It might be that you are doing something illegal (by opengl rules) but your driver does not produce an error and instead shows garbage data. This happened to me once. I was passing invalid arguments to an OpenGL function and weird things started to happen. There was no error and nothing, the driver just went with the garbage data.

I just ran my game with a different computer which has a NVIDEA graphics card. The garbage data didn't occur there. Everything was working just the way it should. My mom has a laptop with a ATI Radeon graphics card which I, unfortunately, was unable to use but when I can I'll try my game there as well. But for now I got a result I can do something with. Good to know it was running fine at someone else's computer, a shame to realize it has to do with Intel (once again).

But I repeat myself: This cannot possibly be the "source" of your problem.
It simply CANNOT be. A wrong normal matrix cannot possibly result in some fragments being shown where there was no rasterized geometry. It CANNOT!
A wrong normal matrix can however result in wrong lighting calculations where some fragments (that are being produced by visible geometry) are being lit incorrectly.

But the "source" of your problem this is surely not. You just tend to always find "manifestations" of the problem when changing something in your shader. But I still suspect a driver bug.

I'm sorry but I think you misunderstood my intentions with changing the shader code. I saw a difference when I did that, so I thought that data could have been a result of a possible driver bug. But to find the bug, I have to know what part of it is going wrong. Still, I was almost certain that change would make a difference! My apologies for the inconvenience though.

[Kai]

If it's really a driver bug, which I am now also not quite certain, it would be nearly impossible to find it. After all, what do you want to find? It could be that you end up saying: Well, if I set the third-column-first-row matrix element of my MVP matrix to 0.0 instead of 1.0, everything works.
Or if you set the red component of your light color to 0.6 instead of 0.7 everything works.
The bug can manifest itself very wildly.
But those are all likely just manifestations of some other bug in your code due to you issuing wrong OpenGL commands/arguments like what Cornix said.
You just gonna have to plow through your own code once again and really make sure that you call each GL method with the correct (and by your driver supported!) arguments. Also, you should enable OpenGL debugging with a debug callback.
If that is unsupported by your card/driver you should insert GL11.glGetError() after each and every GL call.

[TheBoneJarmer]

I have been through my entire code with the glGetError() method, everything is working like a charm. But I've done more. I have made and downloaded different models. Ranging from a pack of cubes, spheres and other geometry to a dinosaur, sunglasses, fruitbasket and a porche. With those models, everything works like a charm. It only happened so far with a cylinder. And I am really starting to wonder why. Why is it that every other model I use works fine but that damned cylinder turns into crap. haha

[TheBoneJarmer]

It is has been 7 years since I used LWJGL and just learned I still have an account here. How times flies. Reading back my comments feels embarrassing. God I was a naive young idiot. Now I am just a naive idiot. lol In the meantime I have learned much, much more about OpenGL so I ought it was nice to share an update on the matter for those who like me back in the day experiences this issue. Kinda feels weird solving an issue for my past self but here goes! It was not the shader nor the driver and none of all the wild goose chasing ideas I threw up.

A couple of years ago I experienced the same issue with c++ and I learned it was actually my buffer data. My example worked with triangles and I was likely screwing up my buffers by not passing the right amount of vertices, texcoords and normals. Or with the wrong parameters for that matter. With what I know now, Kay was absolute correct to state it could not be the shaders. I know its a bit late but sorry for confusion the whack out of you! What I experienced back then was a case of what they call undefined behavior in c++. Same happens when you try to fetch an element from a const float* array that goes out of bounds. You won't get an error, just memory corruption. Which is why I saw those fragments. It was really that simple.