If you’re getting different results for VS debug and release builds, it’s almost certainly a bug in the code which you’re “getting away with” in the debug build due to the lack of optimisation.
So set the warning level to the maximum then start investigating the warnings.
OK will try that but the behavior is the same for debug and release build of g++. Could it be in one of the libraries, like assimp, anttweakbar, magick++ used by the app, not sure whether they are built debug or release mode?
Looking closely at all the warnings:
1- Unused parameters in the callbacks functions of mouse,…
2- Format parameters of printf not matching for example %d for long variable
3- Sign-compare comparing int and DWord(unsigned long)
and that is it for compiling using g++ -Wall -Wextra
So, nothing serious that can cause this behavior, this leads to suspecting any of the libraries mentioned in my previous post, right?!
Well I seem to have located the problem, it is in the fragment shader which has version 450 core , by changing the last line into:
instead of
I got the 2 monkey heads on the red background in 3d and in white
as shown in image 9.
However I got the following warning as shown in image 10.
eventhough gColorMap is well defined in the shader and in the code through glGetUniformLocation…Now Can anyone explain what is a possible cause and how to get things to work right without this bizarre hack…
I forgot to mention that this hack was motivated by my early experiments mentioned in earlier posts when setting FragColor = texture(…) I get balck objects and when I changed that into FragColor = (1.0-tempColor.r, 1.0-temColor.g, 1.0-tempColor.b, 1.0) I still get black objects, so in the first case I get a zero case and in the second case when performing arithmetic with the returned value of texture(…) I get a vertor of 1’s. So I thought of this hack of adding zero’s to the components of vec4 returned by texture(…) to get 1’s.
I know it is bizarre but it is happening, and there must be a logical explanation…
Well the hack is not perfect it seems to always return 1’s instead of all zero’s in the original fragment shader. When I tried the box object with white texture I get image 11.
Well it seems that the hack causes the uniform sampler2D to be unknown (unable to locate) since it is not used in the o/p statement and hence it always returns a vector of 1’s. However when it is located and used in the output it returns random values, white texture is turned into black for the monkey and a white box becomes colorful, what causes such behavior for the sampler2D?
Well the mystery is solved, I contacted the author of the tutorials Etay Meiri and he responded as follows:
It appears to be a possible bug in Assimp. The material file is loaded in index 1 while the material index in the mesh is 2. I pushed a workaround that decrements the material index of the mesh. It’s quite a hack but I don’t see a good solution right now. I’ll file a bug report to Assimp.
So Assimp Importer is to blame, so for anyone intending to use assimp beware…
Well hardwiring numMateriials to 2 and materialIndex to 1 as printed by VS debug build which works fine fixed my problem for monkey.obj and got similar result in mingw64 to the one in VS. However the box.obj still get printed colorful for white.png and distorted texturing for bricks.jpg. Even VS prints 2 and 1 for both monkey and box. This may be not the right forum but there might be some assimp guru on this forum who can point a possible cause which seems to be an incompatibility between release and debug versions of the library.
I am suspecting the weird behavior for box.obj is due to one my GPU drivers since the VS debug which works fine accepted the shaders with version 410. While mingw64 complained and the CS shader wont compile because of the following declaration:
out patch OutputPatch oPatch;
giving the message: Error compiling ‘lighting_8.cs’: ‘0:30(8): error: storage qualifiers must come after precise, invariant, interpolation, layout and auxiliary storage qualifiers’
and I had to change the version of the shaders to 420 for them to compile.
I guess VS and mingw64 are using different GPU drivers and I have no control over this, it is handled automatically by windows.
Is that a plausible explanation?
Well, final mystery resolved. I have been including 32-bit header files instead of the 64-bit version of header files for assimp, also I included ImageMagick-6 heade files instead of 7 that I am linking to, when I included the right files, everything in the release version works fine…
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.
