#36 view3dscene bump mapping very dark and too much?

[simon]

view3dscene: some models very dark until bump mapping turned off, obj and 3ds.

also texture movement, have to brighten to see this.

example model: http://www.mediafire.com/download/odjo99c4rsrki1b/Armored+Security+Vehicle.7z

see attached video.

[Michalis Kamburelis]

Incredibly sorry for such long delay... busy times (but it's good, since the last month was mostly busy around Castle Game Engine --- great stuff is coming:).

For me, the Armored Security Vehicle works fine. Tested on
1. Linux x86-64, with view3dscene 3.15.0 release, with good GPU from NVidia (GeForce GTS 450/PCIe/SSE2 , OpenGL version: 4.4.0 NVIDIA 340.76).
2. Like above but with latest view3dscene SVN.
3. Linux i386 with view3dscene SVN, with old GPU from Radeon and open-source drivers (Gallium 0.4 on ATI RV530, OpenGL version: 2.1 Mesa 10.6.3).

The lighting is sensible both with and without bump mapping. And the texture coordinates are not messed up like on your video. Attaching the screenshot.

So, it seems like a GPU problem on your system.

• Can you test does bump mapping stuff work at all on your GPU? Try http://castle-engine.sourceforge.net/demo_models.php , inside open bump_mapping/fountain_level/fountain_final.wrl . Playing with "lights editor" inside is fun:)

• What is your GPU? Can you try upgrading to the latest version? Can you try installing proprietary drivers (if you use open-source ones), or vice versa --- uninstalling the proprietary drivers (if you use them).

[simon]

same with demo models; Gallium 0.4 on AMD OLAND OpenGL 3.0 Mesa 10.1.3

but works with latest driver; Gallium 0.4 on AMD OLAND Opengl 3.0 Mesa 11.0.2

(also fine with old graphics card and newer driver; Gallium 0.4 on AMD RV610 opengl 3.0 Mesa 10.3.2)

could this have anything to do with "Buggy GLSL gl_FrontFacing"? which is true for the problem setup but not on for the latest?

[Michalis Kamburelis]

could this have anything to do with "Buggy GLSL gl_FrontFacing"? which is true for the problem setup but not on for the latest?

Hm, yes, there's a chance it could be related. Although testing on my system, "Armored Security Vehicle" renders fine even with BuggyGLSLFrontFacing forced to true. But let's check on your system!

For test, I forced now BuggyGLSLFrontFacing to false in the latest view3dscene build. Can you try does view3dscene from today, http://michalis.ii.uni.wroc.pl/castle-engine-snapshots/2015-10-28/ , works on all your systems? Anything changes?

[simon]

(copy of email)
the system demonstrating the issue is linux 64bit, can you compile for
this? i could get round this but then it wouldn't be exactly the
same.

[simon]

i have tried the card on 32bit debian stable, (Gallium 0.4 on AMD OLAND OpenGL 3.0 Mesa 10.3.2) and the issue is there also, and view3dscene without BuggyGLSLFrontFacing, makes no difference.

so it seems a card/mesa issue, fixed sometime after mesa, 10.3.2, but i couldn't see any reference in the mesa bug/fix listings.

but that does mean its in Ubuntu LTS and Debian Stable currently.

specifically my card is AMD R7 250 (aka HD8570 and HD8670) but this level has been replaced by new APU, so there might not be that many

[Michalis Kamburelis]

the system demonstrating the issue is linux 64bit, can you compile for
this

The latest view3dscene for Linux 64-bit is on:

https://michalis.ii.uni.wroc.pl/~michalis/tmp/view3dscene-2015-11-08-linux-x86_64/

Sorry for such delay...

In any case, your test on 32-bit probably shows that the problem is not fixable on our side (easily). Especially since the texture coords are also messed up --- this indicates that some state underneath gets messed up.

We could blacklist bump mapping on this GPU, it seems that checking for Mesa 10.x AND Renderer = 'Gallium 0.4 on AMD OLAND' is Ok to detect BuggyBumpMapping? Do you think it's worthwhile, since it's on Ubuntu LTS and Debian Stable?

[simon]

FWIW i seemed to remember that drivers are generally compiled 32bit internally even on 64bit os, but that was a while ago, so thats why i figured a failure on 32bit was vertually centainly the same issue.

[simon]

blacklisting? ummm

the next Ububtu LTS is, what, 6 months away, and that will have the fix, debian stable, i guess 18 months.

gamers/developers will know about the 'update the drivers' mantra, but a casual user, someone maybe more likely to install older (more reliable) software, the target for castle game engine?, might give up at the first sign of problems, being VERY dark i think will cause a give-up.

but, nobody noticed, my card has in various versions been out for about 2 years, it might be too small a problem-base to worry, i will be updating the drivers, but in a way i was keeping on the base distro/drivers to maximise compatability with stuff i do.

maybe Volcan/mantle is a recognitition of this being a symptom to a more general problem. that keeping the low level drivers simple, RISC, and have them then hopfully be more bug free, and let the next layer up, an 'engine' layer, do more, which with shaders was happening anyway, is needed. and i would say its in AMDs interests to improve generality in drivers and NVIDIAs interests to tie people in with more complexity, like microsoft OS's for many years, so i have some sypathy with AMD.

mesa drivers, although open, are maybe a double edged sword anyway, since they seem to emphasise INTEL gpus.

[simon]

close i think, because chances of someone having the driver bug conditions is now virtually non-existent.

[Michalis Kamburelis]

OK, closing. Thanks for remembering about this and sorry for now having the time to implement the workaround for affected GPUs earlier!