Unable to reference stb_image when compiling.
Angular-Angel opened this issue · 16 comments
I get this a bunch when trying to compile the project. I'm not sure what the issue is - ogldev_texture seems to reference stb_image just fine to me.
/usr/bin/ld: /tmp/cc8CWbfJ.o: in function `Texture::Load()': /home/angle/Documents/Programming/C++/ogldev-master/tutorial36/../Common/ogldev_texture.cpp:45: undefined reference to `stbi_set_flip_vertically_on_load' /usr/bin/ld: /home/angle/Documents/Programming/C++/ogldev-master/tutorial36/../Common/ogldev_texture.cpp:47: undefined reference to `stbi_load' /usr/bin/ld: /home/angle/Documents/Programming/C++/ogldev-master/tutorial36/../Common/ogldev_texture.cpp:50: undefined reference to `stbi_failure_reason' /usr/bin/ld: /home/angle/Documents/Programming/C++/ogldev-master/tutorial36/../Common/ogldev_texture.cpp:73: undefined reference to `stbi_image_free' collect2: error: ld returned 1 exit status
Oh, for the build environment, I'm using the latest gcc on the latest Xubuntu, I believe.
Well, I was able to solve that problem by adding '../Common/3rdparty/stb_image.cpp' to the list of files to compile. But of course, now it gives me a seg fault when I try and run it. :/
Got this output:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x0000555555568f8c in BasicMesh::InitSingleMesh (this=0x555555b401e0,
paiMesh=0x555555b5d040) at ../Common/ogldev_basic_mesh.cpp:157
157 assert(Face.mNumIndices == 3);
I've just noticed that you are talking about tutorial 36 and not one of the new ones from youtube...
I pushed a fix to the build issue and I'm now taking a look at the crash. I was was able to run the tutorial without crashing but the textures came out wrong so I added aiProcess_FlipUVs to OGLDEV_LOAD_FLAGS in Include/ogldev_util.h. Now it is crashing in ogldev_basic_mesh.cpp:150. Looks like something is wrong with the normals. Did you change the model file?
Nope, I didn;t change anything, except the listed addition to build file. Lemme pull the latest version, and see how that works.
Try to rename ogldev/Include/assimp to ogldev/Include/assimp.bak. I recently found out that there is some conflict between the assimp headers that I provide and the ones that are installed by the Ubuntu deb package. We need these headers for Windows so I still need to resolve this. I was not able to force the build on Linux to use the ones on /usr/include so I may end up renaming the directory to assimp5 or something and make the VS project point to it.
Also, that same build issue applies to several of the other tutorials as well.
Also, that same build issue applies to several of the other tutorials as well.
Yes, I need to add stb_image.cpp to all the build files but I'm lazy...
Yeah that seems to fix it (using the latest version and Renaming the assimp folder, that is), but I get the same weird textures you were talking about:
I also get some terminal output:
Loaded ambient color [0.000000 0.000000 0.000000]
Loaded ambient color [0.000000 0.000000 0.000000]
Width 580, height 387, bpp 3
Loaded texture '../Content/bricks.jpg'
Loaded ambient color [0.000000 0.000000 0.000000]
Loaded ambient color [0.000000 0.000000 0.000000]
Loaded ambient color [0.000000 0.000000 0.000000]
32
../Common/glut_backend.cpp:129 - Unimplemented GLUT key27
../Common/glut_backend.cpp:129 - Unimplemented GLUT key27
../Common/glut_backend.cpp:129 - Unimplemented GLUT key27
../Common/glut_backend.cpp:129 - Unimplemented GLUT key```
The message at line 129 is just a warning about some key not being handled in the case statement. The problem is with the texture.
I think I fixed all the build errors related to the missing stb_image.cpp. There are a few more errors I need to check but they are of a different nature.
Huh. For those wierd textures, I wonder if they got rotated by like 45 degrees, or something? That might explain the wierd streaking on the corner, if it's just smearing the edge of the texture to cover that space...
The problem is the addition of GL_CLAMP_TO_EDGE on the two wrapping modes in ogldev/Common/ogldev_texture.cpp. If you remove them it fixes the visual problem. But there may still be some problem with the asserts when loading the mesh that I need to sort out. Right now it works if I just disable the assert on num vertices. Assimp should have triangulated the quads.
Yeah commenting out the 'GL_CLAMP_TO_EDGE' fixes things for me too, thank you! XD
Hmm. Latest version works, except it still need the 'GL_CLAMP_TO_EDGE' bit commented out. That should probably be a separate issue though, so I'm going to close this one.