On 29.09.2016 08:36, Sebastiaan Couwenberg wrote:
On 09/28/2016 02:28 PM, Sandro Mani wrote:
I've had a look recently at adding osgEarth 2.8 support (and produced a
tentative patch [1]), however the rendering is completely broken. I've
not had time to investigate yet, but it looks like osgEarth2.8 puts a
hard minimum requirement on GLSL 3.30, i.e. debug log output:
FRAGMENT glCompileShader "main(fragment)" FAILED
FRAGMENT Shader "main(fragment)" infolog:
0:1(10): error: the compatibility profile is not supported
0:1(10): error: GLSL 3.30 is not supported. Supported versions are:
1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES
This makes me uncomfortable: I'm pretty sure many users running somewhat
older distros or older hardware will hit this. So upgrading to osgEarth
2.8 just for the sake of upgrading and braking the globe for many user
is in my view not the best of plans.
To me that just sounds like a normal price for progress.
Not really agreeing on this.
Technically nothing speaks against building osgEarth2.7 against Qt5 (for
clarity: osgEarth 2.7 supports Qt5 alread) and keeping that version
packaged for the forseable future.
Alternatively, distros wanting to upgrade could keep osgEarth 2.7
packaged as osgEarth27 and renaming library names (i.e. libosgEarthXXX
-> libosgEarth27XXX) and the header dirs. Up to this point it would be
fairly easy, the problem comes with osgPlugins - I'm not sure if it is
possible to install multiple versions simultaneously in
/usr/lib64/osgPlugins-3.4.0/ or similar.
Unless someone volunteers to maintain a separate source package for
osgEarth 2.7 in Debian, only a single version will be in Debian (the
latest). Unlike the OpenSceneGraph maintainers I'm not willing to
maintain two co-installable osgEarth versions in a stable release.
Then I suggest you use osgEarth28.patch and deal with the consequences.
Happy to hear other suggestions.
Since the Globe plugin is not very actively developed, and takes a lot
of time before it's adapted to new osgEarth versions, consider it not
appropriate to keep as a core plugin and move it out of the qgis tree.
This is not very fair. Whereas it had a period of being pretty much
unmaintained, the plugin is now actively maintained. But keep in mind
that osgEarth is a delicate upstream to deal with: they break things
without warning and without replacement within "minor" releases (though
they really should be bumping major digits of the version number...). So
finding new workarounds etc takes time and effort. So if distros don't
want to wait for it to be adapted, they are free to simply disable
building the plugin.
Sandro
_______________________________________________
Qgis-developer mailing list
[email protected]
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
