Rendering with materials with shaders is broken on some Linux environments.

[juj]

This has been reported in two Linux boxes, the other has Ubuntu 11.1 and glxinfo as follows: https://dl.dropbox.com/u/40949268/Bugs/linux_tundra_avatarscene_glxinfo.txt .

The problem is that Ogre rendering with any materials that have programmatic shaders defined in them are completely broken. The result looks something like https://dl.dropbox.com/u/40949268/Bugs/linux_tundra_avatarscene.png . In the image, the red streching lines should instead show a gray ground plane with a fish (the Avatar demo scene).

It has been detected that Ogre fails to update any shader constants specified with param_named_auto or param_indexed_auto. For some reason it never goes into the code path that updates those registers to its internal array of constants. Materials which do not contain any shaders, or shaders which do not have any need for param_xxx_auto don't have any problem.

[evktalo]

I get this problem both on my work laptop and work desktop computers.

Here's the glxinfo dump from the laptop: https://gist.github.com/2875170

Will post the glxinfo from the desktop later, and also look for the commit when the bug started appearing.

--Eino

[msantala]

Same issue here.

glxinfo dump can be found from: http://pastebin.com/DD24StVi

I can provide further info on IRC (migu- @freenode) if needed.

[evktalo]

I tried to hunt down the offending commit.. but I failed to tweak/rebuild the dependencies manually to make their status the same as it was in the time of each commit.

In the process, I ended up building current master with Ogre 1.7.3, and such a build doesn't seem to exhibit the bug.

--Eino

[jonnenauha]

Am not sure if this is relevant but when we switched to ogre-safe fork, we had to switch to directx from opengl in Admino windows releases because this happened. We did not and still do not have anything special in the fork to cause this. The problem was probably the 1.7.3 -> 1.8u jump that the fork brought to windows.

Seems like keskitalo is saying it is fine in 1.7.3 also in linux.

http://dl.dropbox.com/u/3589544/rmp-platform-mesh-artifact.png http://dl.dropbox.com/u/3589544/rmp-platform-mesh-artifact2.png

Looks quite similar to what you have in the screen shot. Meshes stretching to hell and back :)

[evktalo]

I did a full rebuild of deps on the laptop, and it seemed to fix the problem. Running Tundra, it says it's using Ogre 1.8.0 (Byatis). This with the ace8492bab commit. I also ran the latest commit with deps built while ace8492bab was checked out without problem. Building the deps with the latest commit checked out too, just to be sure. Also I'm in the process of rebuilding the deps on the desktop machine, where I had the problem also. Let's see if the problem gets fixed that way there also.

Meanwhile, here are the graphic device & driver info, while I wait for the build to finish. Just in case it turns out it would be useful. This is from running "lspci -k":

desktop: ATI Technologies Inc RV610 [Radeon HD 2400 XT], Kernel driver in use: fglrx_pci laptop: nVidia Corporation G98M [Quadro NVS 160M], Kernel driver in use: nvidia

So it was both on ATI and nVidia chips.

edit: also, the glxinfo from the desktop: https://gist.github.com/2894250

--Eino

[evktalo]

All seems to show correctly both on the laptop and desktop, after building the deps from scratch.

--Eino

[juj]

So, if you're on a clean system, and clone and build latest tundra, and then rebuild all the deps once more, the problems go away? That sounds like some kind of build script issue. What cmdline steps do you use to clean the deps before rebuild?

[evktalo]

Just "rm -rf naali-deps" in the right directory really. :) I didn't start with a clean system in either case though, so I'd assume building on a clean system would work right.

--Eino