Many Pink Textures

[LoopZoop]

Yes, but from what I have heard the linux Nvidia drivers may be a little... wonky. Are you on a Linux machine? IIRC Mac and of course Windows should be using the proprietary drivers.

Nope, I'm on Windows 10, and no problem, I appreciate the interest and your help.

[Frik]

Afaik, nVidia drivers support texture compression directly, without the need for additional drivers..

Yes, but from what I have heard the linux Nvidia drivers may be a little... wonky.

Linux provides open source Noveau drivers for nVidia but they wouldn't contain patented code. I don't use those, anyway. I prefer the proprietary nVidia Linux drivers, which work very well.

You mentioned that you see pink textures if they are missing. I've had this issue, as well, recently with a sword mod where the textures/meshes needed to be in specific folders. You can check your openmw.log file to see if this might be your problem.

Are the files in the proper folder location, is the folder location typed out properly in the openmw.cfg

Yes. That was what I was suggesting. The folder structure for the sword mod I was referring to had to be just like this, or you'd get the pink texture.

data
|
| icons
|------ w
| -------- f_W_katana_goldbrand.tga
|
| meshes
|------ w
| --------- f_W_art_katana_goldbrand.nif
|
| textures
| --------- f_W_goldbrand00.bmp
| --------- f_W_goldbrand01.bmp
| --------- f_W_goldbrand02.bmp
| --------- f_W_goldbrand03.bmp
| --------- f_W_goldbrand04.bmp

[silentthief]

I was referring to had to be just like this, or you'd get the pink texture.

data
|
| icons
|------ w
| -------- f_W_katana_goldbrand.tga
|
| meshes
|------ w
| --------- f_W_art_katana_goldbrand.nif
|
| textures
| --------- f_W_goldbrand00.bmp
| --------- f_W_goldbrand01.bmp
| --------- f_W_goldbrand02.bmp
| --------- f_W_goldbrand03.bmp
| --------- f_W_goldbrand04.bmp

I don't know where, but I remember reading about Nif creation that there were ways to "bake" the texture into the NIF/ -- and if I remember correctly this would then set up an absolute path to the texture in the NIF file. I don't know if you know anything about editing NIFs in NIFskope -- but this may be needed to remove these paths to the texture.

This is kind of guessing at this point, though.

ST the guesser

PS -- does this happen in vanilla MW ??

[AnyOldName3]

In trying to see why something to do with shadows wasn't working, I decided to try it on my laptop. That machine has a GTX 850M, runs Windows, and has the latest nVidia drivers. When I start OpenMW on it, though (be it an official 0.42 build or one of my own) every DDS texture shows up pink, and the console is spammed with errors like Error loading textures\tx_stars_nebula3.dds: no S3TC texture compression support installed. Other games I've tried that use S3TC texture compression work fine.

I ran a tool that gets the reported GL extensions, and it said that my integrated graphics supports GL_EXT_texture_compression_s3tc, but the dedicated chip supports GL_EXT_texture_compression_s3tc and also GL_S3_s3tc, and we only seem to check for the latter (imagemanager.cpp, line 70). My current guess is that it's running on the integrated GPU and we're not checking both versions of the extension (even though I think both provide the necessary functionality).

I just tried adding a check for the other version, and it didn't fix the issue, but it's possible that I did that incorrectly.

Thoughts?

[scrawl]

I ran a tool that gets the reported GL extensions, and it said that my integrated graphics supports GL_EXT_texture_compression_s3tc, but the dedicated chip supports GL_EXT_texture_compression_s3tc and also GL_S3_s3tc, and we only seem to check for the latter (imagemanager.cpp, line 70). My current guess is that it's running on the integrated GPU and we're not checking both versions of the extension (even though I think both provide the necessary functionality).

Hm, but we already check both. exts->isTextureCompressionS3TCSupported resolves to GL_EXT_texture_compression_s3tc , and GL_S3_s3tc is checked one line below. The checks may be confusing: because of the negation ext1 || ext2 becomes !ext1 && !ext2

If you're able to rebuild OSG, you can use this to run without using S3TC.

[AnyOldName3]

I've still never got an OpenMW executable to build using anything other than Ace's prebuilt OSG libraries, so that's not an option.

I did confirm that it works when I run it on the dedicated chip manually, but that's not something I can do when debugging in Visual Studio.