I can see through Bowfin and space stations

[Tichy]

That issue occours only with Bowfin and space stations. Every other ship looks good.

My opengl.txt
https://gist.github.com/Tichy/6ecbe05b46511798619f

My output.txt
https://gist.github.com/Tichy/b755b6465a63783ac136

[impaktor]

Conversation with @robn Friday March 11 2016:

<robn> I'm guessing the big ring station interior isn't supposed to be
       seethrough?  [12:12]
<robn> http://i.imgur.com/aOk0SWa.png
<impaktor> Wow, how did that happen?  [12:13]
<robn> stock build, this very second
<impaktor> Arrrghhh!
<robn> OpenGL version 3.3 (Core Profile) Mesa 11.1.2, running on Intel Open
       Source Technology Center Mesa DRI Intel(R) Haswell Mobile
<robn> I'll try the nvidia
<fluffyfreak> back 5 minutes and already breaking stuff ;)
<robn> devops mate  [12:14]
<robn> that's how we roll
<impaktor> master works fine on my system.  [12:15]
<robn> http://i.imgur.com/yWNMHp2.png
<robn> nvidia is the same, but with prettier lights
<robn> OpenGL version 3.1.0 NVIDIA 352.79, running on NVIDIA Corporation
       GeForce GTX 770M/PCIe/SSE2
* robn squints at GL3
<robn> that's supposed to be GL 4.lots on the nvidia
<fluffyfreak> yeah but nvidia gives you what you ask for  [12:16]
<robn> I dunno what garbage debian is shipping these days though
<fluffyfreak> we request 3.1 interface
<robn> ohh
<robn> ok
<robn> just different to last time I was here
<robn> all good then
<robn> so, you got _bugs_
<robn> but works fine for impaktor, hmm  [12:17]
<fluffyfreak> *features* mean, now you can see where you're gonna land ;)
<robn> that could be anything though, our systems are likely very different
<robn> totes
<robn> the whole hub was lit up for miles
<robn> I wonder what it looks like from the inside
<fluffyfreak> err, Xmas mode? yeah that needs fixing :)  [12:18]
<robn> http://i.imgur.com/1ojwH4E.png  [12:19]
<robn> interior would be mostly ok if it wasn't bathed in the light of a
       thousand suns  [12:20]
<robn> mesh edges are visible, of course
* robn fiddles with some graphics options
<fluffyfreak> fine here too, why is it that every linux install is like a
              special and unique snowflake?  [12:21]
<robn> multisampling and anisotropic filtering make no difference (well, they
       smooth up things, of course)
<robn> hey, am not! my fonts are totally not a mess atm because debian screwed
       something in the last nightly  [12:22]
<robn> yeah, feel free to blame me if you can't repro

[bszlrd]

Hmm, that sure looks odd.
It doesn't happen on my end either. (win7, nvidia 660ti)
At first my culprit would be the normal maps, but the station doesn't have that, only the Bowfin and the Kanara,
What I notice on those screenshots, that the station has all the textures/materials messed up, and it seems that all parts have the floor material.

[Tichy]

Maybe related to Mesa Gallium drivers?

[fluffyfreak]

Maybe, I have an AMD gpu in my linux boxen, will grab latest, update kernel etc and give it a go.

[fluffyfreak]

@Tichy can you post the results of a glxinfo | grep OpenGL here or in a gist? My LLVM version (3.6.2) differs from yours (3.7.1) but that's the only difference I can see right now.

[Tichy]

Here you are :-)

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD JUNIPER (DRM 2.43.0, LLVM 3.7.1)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.1.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.1.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

And if you also need my config.ini
https://gist.github.com/Tichy/051f02d64ae40cfec73a

[fluffyfreak]

Ok, I haven't been able to reproduce this so I guess it's time to try and figure out when it got introduced.

Could you try again with all of the SGM files deleted. Then

if that still breaks I don't suppose either @Tichy or @robn know if the last February or January release tags work?

Would you be able to try those releases? Either by downloading or building them locally.

[Tichy]

Il 2016-03-30 09:58 Andrew Copland ha scritto:

Ok, I haven't been able to reproduce this so I guess it's time to try and figure out when it got introduced.

Could you try again with all of the SGM files deleted.

Ok. I'll try as soon as I get back home. How do I restore the SGM files?

Then if that still breaks I don't suppose either @Tichy [1] or @robn [2] know if the last February [3] or January [4] release tags work?

Would you be able to try those releases? Either by downloading or building them locally.

If restoring the SGM files doesn't work, I'll try to find the last
release that works :)

Links:

[1] https://github.com/Tichy
[2] https://github.com/robn
[3] https://github.com/pioneerspacesim/pioneer/tree/20160225
[4] https://github.com/pioneerspacesim/pioneer/tree/20160129

[fluffyfreak]

To (re)build sgm files you can run the following:
If downloaded build: ./modelcompiler -b inplace
If git checkout build: ./src/modelcompiler -b inplace

[Tichy]

I'm preparing a clean git clone to try to rebuild the sgm files.
I'll update as soon as i get it cloned and compiled.

Meanwhile I tried the precompiled builds, but I can't run them, because they complain abount my libcurl version: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./pioneer)

[Tichy]

rebuilding the sgm files doesn't solve the problem. :(

[fluffyfreak]

ok, if you want to do a local build of those older releases then git checkout 20160225 or git checkout 20160129 will fetch you everything tagged at that time.

You'll need to remove those sgm files you built in case there have been changes to the sgm format inbetween release.

[Tichy]

I tried almost every build back since 20151130 and all of them, now, displays that problem. To be sure to avoid mistakes with git, I even tried the zipped source releases from here: https://github.com/pioneerspacesim/pioneer/releases

I'm sure that prevoiusly I played most of them without this issue.
Could be that something changed in mesa/drm/kernel (4.4.5)?

[fluffyfreak]

Ah ha! Now that's interesting @robn perhaps you have something in common with @Tichy setup.

What distro is it you use? Window manager? Anything else that you can think of. It's hard to fix what we can't reproduce on our own hardware.

Also, thanks for taking the time to test these builds!

[Tichy]

Il 2016-04-01 11:26 Andrew Copland ha scritto:

What distro is it you use? Window manager? Anything else that you can think of. It's hard to fix what we can't reproduce on our own hardware.

Also, thanks for taking the time to test these builds!

Distro: Arch Linux with latest updates

Window Manager: dwm or i3; with or without a compositing manager
(compton in that case)

Drivers are the open source ones with binary blobs.

I launch pioneer in window, because it doesn't stay fullscreen. See
#3657

[johnbartholomew]

I see two problems running current master (ArchLinux, Intel graphics). One is transparency, the other is that the ship's lights are using totally the wrong texture.

The transparency problem is due to the wrong materials being picked by the model loader. The warning messages visible on the right in my screenshot show this. The bowfin.model file contains materials named like material Fuselage-material. The DAE file contains reference to materials like this: <material id="Fuselage-material" name="Fuselage">. Assimp, in current git HEAD, uses the 'name' attribute to fill in its general AI_MATKEY_NAME field, which is what Pioneer's assimp loading code looks for. This causes a mismatch -- the .dae file refers to a material with name "Fuselage", but the .model file provides a material called "Fuselage-material".

Assimp HEAD:

• ColladaParser::ReadMaterialLibrary()
• ColladaLoader::BuildMaterials

Assimp in pioneer-thirdparty (which hasn't been updated for a few years) instead uses the 'id' field:

• ColladaParser::ReadMaterialLibrary
• ColladaLoader::BuildMaterials

I don't use pioneer-thirdparty for my normal (dev) builds because all the necessary libraries are already available and installed through the distro package manager. I would guess the same is true for Tichy (since we're both on Arch), and I assume also robn. Someone using the official binaries (which should be built with pioneer-thirdparty libs) or building on Windows will be getting the older assimp and so won't see this problem.

[fluffyfreak]

Ships lights are due to my latest change, I've gotten something wrong with the texture and it looks like they're being released before being used... bizarre issue.

Thanks for the Assimp hint though I'll grab the latest and update my 3rd party to repro it locally.

[fluffyfreak]

There's some data changes required too as can be seen in 1752a97

[walterar]

Arch + Pioneer is too much :))

Assimp 3.2 is only available on the latest Linux distributions. With #3671 solution, many left out.

[Tichy]

I just compiled it using pioneer-thirdparty and everyting seems to look fine.

[fluffyfreak]

Ok so this leaves me in a quandry about what to do.
@robn what do you think here? We could use pioneer-thirdparty for Linux/OSX/Windows and thus only use the old 3.0(?) version. Or we could use pioneer-thirdparty for all but upgrade to 3.2 at the same time.

Kinda depends on MXE for the cross-compiling madness.

[walterar]

@fluffyfreak MXE with Assimp 3.2 works fine now, but I think we'll have a lot of problems with models.

[impaktor]

@fluffyfreak fixed now with the assimp 3.2 merge?

[fluffyfreak]

Yes I think so.