openmw.org

Dear developers,

I am using OpenMW for quite some time now, on Linux 64-bit boxes, and it used to work great. Recently, I upgraded my distribution from Salix 14.1 to 14.2 (Salix is 100% compatible with Slackware), and I suddenly have issues when water shaders are on:
(1) Water surface looks flat (no waves at all).
(2) There is a gap right between the shore and the water.
(3) When underwater, I see reflections of the sea bed on the water surface above my character.
(see pictures below).

It just looks ugly. I tried to change several settings without any luck. The only way to get rid of the problem is to actually turn off water shaders - which I don't want to do.
The problem is present on both a desktop machine with NVDIA Quadro 2000 GPU (latest Nvidia drivers installed), and a laptop with an Intel HD graphics card. Note that both machines used to run OpenMW without any similar issues
in the past.

Any suggestions?

EDIT: Marked as "Solved". Thank you for your help!

Scrawl was planning to fix this. I think he said post-1.0 though... hopefully soon.

Please post your openmw.log. Are you running a "generic" Linux build? I experience the same issue with generic release builds because they require a very old version of libpng that is no longer available in my repository.

I'm not familiar with Salix/Slackware. If there is no openmw package available for your system, I'm afraid you will have to compile it yourself: https://wiki.openmw.org/index.php?title ... ment_Setup

Pap wrote:(3) When underwater, I see reflections of the sea bed on the water surface above my character.
(see pictures below).

This is normal. If you look up, there should be a "hole" that you can see above water through. It's a real characteristic of water, called Snell's window.

Looks like libpng-legacy 1.2 is available in Slackware 14.2

https://slackbuilds.org/repository/14.2 ... -legacy12/

MiroslavR wrote:Please post your openmw.log. Are you running a "generic" Linux build? I experience the same issue with generic release builds because they require a very old version of libpng that is no longer available in my repository.

I'm not familiar with Salix/Slackware. If there is no openmw package available for your system, I'm afraid you will have to compile it yourself: https://wiki.openmw.org/index.php?title ... ment_Setup

I am using the "generic" guild - which used to work perfectly. It turns out that the problem is indeed the libpng library, and it is not the first time it causes problems to me. Recent Linux distributions (including Slackware 14.2 and its derivatives) replaced libpng 1.2 with libpng 1.6. This caused my own libraries (which used libpng to load png images in an OpenGL context) to segfault. Trying to figure out what the hell is going on didn't help much, and given the fact libpng is too "low level" anyway, I just got rid of it and replaced it with SOIL, a much smaller and easier-to-use library which just gets the job done perfectly. After that, my own libraries worked as expected and I just forgot about libpng.

To be honest, when I saw that OpenMW shaders were bugged, I thought of libpng as a possible reason. However, my own libraries are actually written in Fortran 2008 (with bindings to C libs like OpenGL) and I had segfaults with libpng 1.6 although I don't actually use shaders in my own libraries (GLSL is not bindable because it's not C), I concluded it is unlikely I am experiencing issues in OpenMW because of libpng 1.6. It turns out I was wrong.

Anyway, installing libpng-legacy12, as Frik pointed out, fixed the problem and OpenMW looks pretty once again. I am guessing future versions of OpenMW will use libpng 1.6. I don't know if you do "heavy" use of libpng in OpenMW, but if you just want to load and render png images, SOIL looks like an easier and better tool to me.

Please file a bug for this, we need to verify that we are handling PNGs correctly in code. This shouldn't have to be yet another worry for package maintainers considering that older versions of libpng will fall away.

psi29a wrote:Please file a bug for this, we need to verify that we are handling PNGs correctly in code. This shouldn't have to be yet another worry for package maintainers considering that older versions of libpng will fall away.

Done. Thank you for suggesting a bug report.