Hi,
I disabled the shadows for now in the code. I'll try to find a better
solution, but I'm quite busy with other stuff right now, so I can't give
promises when this will be done.
Regards,
Jörg
Am 2014-02-19 10:06, schrieb Fabien Chéreau:
> Guillaume,
>
> that's great news!
>
> we discussed with Jörg in IRC, and I think the problem with the planet
> shadow code are that:
> - it uses floating point textures
> - it contains a large loop in the fragment shader.
>
> I personally think this code was not ready to be merged in trunk, as
> there are ways to get rid of both shortcomings. What about we
> temporarily revert this commit in trunk until the problems are fixed?
> Jörg would you agree with that?
>
> Fabien
>
>
>
>
>
> On Wed, Feb 19, 2014 at 9:49 AM, Guillaume Chéreau
> <[email protected] <mailto:[email protected]>> wrote:
>
> About the compilation problems with ANGLE, I am working on a branch
> that fixes those issues:
>
>
> https://code.launchpad.net/~stellarium/stellarium/windows-cleanup
> <https://code.launchpad.net/%7Estellarium/stellarium/windows-cleanup>
>
> It is based on r6538 (just before the planet shadow commit, because
> the shadows have some bugs on my machine).
>
> I was able to compile and run this branch both with mingw and msvc
> 2012 + ANGLE, with the default Qt 5.2 binaries, on windows 7, 32 bit.
>
> The major change to make it work with angle is in the CMakeLists,
> where we should not link with opengl but with the default Qt gui
> opengl libs.
>
> See
>
> http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6542
>
> <http://bazaar.launchpad.net/%7Estellarium/stellarium/windows-cleanup/revision/6542>
> and
>
> http://bazaar.launchpad.net/~stellarium/stellarium/windows-cleanup/revision/6544
>
> <http://bazaar.launchpad.net/%7Estellarium/stellarium/windows-cleanup/revision/6544>
>
> Regards,
>
> guillaume
>
>
> On Fri, Feb 14, 2014 at 11:28 PM, Georg Zotti
> <[email protected] <mailto:[email protected]>> wrote:
> > Dear Fabien!
> >
> > I also think that likely everything that's in trunk currently
> can run in
> > OpenGLES2.0 if that is almost equivalent to OpenGL2.1. However,
> some of
> > the things that still await integration in scenery3d are based on
> > OpenGL3.2. That 0.12 renderer class update prevented
> integration, but the
> > return of the previous API for the 0.13 series made me hope again.
> > Meanwhile also newer Intel HD systems support OpenGL4 (at least per
> > specs), so scenery3d should also run on them, if I ever get around
> > successfully calling initializeOpenGLFunctions() and subsequently
> > reactivating Andrei's code. (Unfortunately Andrei is no longer
> available.)
> >
> > Alex tried to compile Stellarium with MSVC/Qt/ANGLE a few weeks
> ago, it
> > did not work (cannot remember the details, but I think mostly
> OpenGL(ES)
> > related errors). I have not tried myself, but a working
> > Cmake/MSVC2012-free/Qt-Angle building path would be a useful
> starting
> > point to test and adapt to an optional OpenGLES2.0 build. (There
> is no
> > Qt-Angle for MinGW, and I wouldn't want to have to build it! I
> only have
> > my Atom 450 netbook to test that, and building Stellarium-MinGW
> for Qt4.8
> > took ages, that indicates at least overnight for Qt(?), and that is
> > reportedly difficult), so it's no fun developing with that. Not
> sure if
> > its already possible to have Angle and non-Angle installed at
> the same
> > time on a more powerful system, I remember having read it's not
> possible
> > with Qt5.0.
> >
> > So, if OpenGLES2.0 is just a few #ifdefs apart from "real"
> OpenGL2.1,
> > there may be two Windows versions: Angle/OpenGLES2 as successor
> of what
> > used to be "fallback mode" to run on legacy hardware (no problem
> not to
> > have scenery3d on a travel/mobile-telescope netbook or some 2006
> vintage
> > PC), and on the other hand an OpenGL version for systems with
> OpenGL2.1
> > and better drivers, where add-ons and plugins with higher OpenGL
> functions
> > may then easier mix. However, somebody please hit me with a
> working HOWTO
> > Qt5/OpenGL(ES) tutorial that applies to our class infrastructure.
> >
> > On GUI changes: Some things can be rearranged, but most GUI
> changes in the
> > last 2 years were also a question of available space. My
> candidate for
> > relocation would be the projection setting in the "Marks" tab, or
> > generally the first two tabs could be rearranged.
> > I think esp the DeltaT model switch (in the advanced settings
> anyway) is
> > a unique feature and very useful, if only for a handful of
> scientists.
> > Maybe a caution like "use only if you know what you are doing"
> should be
> > added if the default model is not in use, or a tick "Expert
> Mode" added
> > that deactivates the DeltaT panel if not active? Or add a new
> tab "Expert
> > settings" to the F2 menu? (This could actually go on a tab
> together with
> > the Planetarium settings, which are also definitely not for
> everybody.)
> >
> > Kind regards,
> > Georg
> >
> >
> > On Fr, 14.02.2014, 14:21, Fabien Chéreau wrote:
> >> Hi Georg,
> >> thanks for the detailed email.
> >>
> >> In term of code, stellarium needs only quite limited opengl
> features.
> >> OpenGL ES2.0 should be enough, or OpenGL 2.1 (on desktop)
> should also be
> >> enough. However, on windows, we should only use the ANGLE
> version of Qt,
> >> from Qt website:
> >> "For QtQuick
> >> <https://qt-project.org/doc/qt-5.1/qtquick/qtquick-module.html>
> >> 2.0
> >> to work, a graphics driver that provides OpenGL 2.1 or higher
> is required.
> >> The Windows default driver provides only OpenGL 1.1, which is not
> >> sufficient. To work around this limitation, Qt now includes a
> version of
> >> the ANGLE <http://code.google.com/p/angleproject/> project
> which is used
> >> by
> >> default. ANGLE implements the OpenGL ES 2.0 API on top of
> DirectX 9. ANGLE
> >> requires that the DirectX SDK is installed when building Qt."
> >>
> >> -> So in theory using Qt5 ANGLE version, the requirement on
> windows should
> >> be DirectX 9c, and on Mac/Linux OpenGL 2.1
> >> What kind of advanced features would you like to use in the code?
> >>
> >> For coming versions of Stellarium, we should try to stop using
> >> GraphicsView, i.e. re-implement the base button bars GUI in
> QtQuick2, and
> >> try to preserve our current dialogs code using code like the
> >> createWindowContainer
> >> stuff mentioned by Guillaume.
> >> We should also start to think about a roadmap for moving all
> GUI to QML.
> >> For the basic GUI it should actually not be that difficult, I'm
> not too
> >> sure about the GUI in plugins. Maybe it would be a good
> opportunity to
> >> re-think and simplify the main GUI which is getting a bit too
> complicated:
> >> for example choosing the delta T model should definitely not be
> something
> >> that a regular user see in the main GUI.
> >>
> >> Fabien
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Feb 13, 2014 at 11:36 AM, Georg Zotti
> >> <[email protected] <mailto:[email protected]>>wrote:
> >>
> >>> Dear Guillaume!
> >>>
> >>> First, thank you for looking into this. This is a major
> architectural
> >>> change, so I can imagine it's not simple.
> >>>
> >>> When I wrote the bug report, I tried alpha5 (?) on an Intel PC
> that
> >>> should
> >>> support OpenGL2.1. I have no build environment on this and
> cannot spend
> >>> much time on Stellarium there. It complains in the logfile about
> >>> unresolved OpenGL functions, and in night mode displays a big
> dark-red
> >>> rectangle in the lower left corner (limited by the extents of the
> >>> sliding
> >>> button bars). I also tried with the Mesa library, here it
> worked, but of
> >>> course quite slow (it is a dual-core2 though, so still not too bad
> >>> (2009?)). That means, once again it's mostly an Intel driver
> problem,
> >>> but
> >>> that PC is not so old and should support current Qt, and may
> represent a
> >>> considerable fraction of users' PCs. I think I have also
> reproduced the
> >>> same issue on an i3 notebook (HD3000 graphics). Maybe also
> that Intel
> >>> driver is just pickier about having to use
> initializeOpenGLfunctions(?)
> >>> or
> >>> such, but for OpenGL2.1 I had thought it is not necessary?
> Apparently
> >>> this
> >>> call gives different results on Win and Linux, my scenery3d
> branch seems
> >>> to initialize OK on Linux (Alex reported) and always failed on my
> >>> Win7/NVidia system.
> >>>
> >>> I can also only guess when QtDeclarative will be removed from
> Qt, but I
> >>> can imagine that Qt devs will not invest much time into
> keeping it alive
> >>> when they talk so much more about, and want devs to convert to
> use,
> >>> QtQuick2. So my thoughts were that all things documented in Qt
> work only
> >>> reliably with the newer classes.
> >>>
> >>> Else, on the cheap-hardware base, I don't know where we should
> go: Shall
> >>> Stellarium rather be converted to work on OpenGL-ES2.0 with no
> higher
> >>> OpenGL functionality, or can we mix development that involves
> higher
> >>> GPUs'
> >>> OpenGL3.2 or better with just a few #ifdefs? I am afraid I
> don't know
> >>> the
> >>> programming details and differences concerning OpenGLES. Given the
> >>> enormous popularity of Stellarium from schools to world-class
> >>> observatories (wow!), it would be nice to have our application
> in basic
> >>> functionality available on all Qt platforms: Androids,
> netbooks (using
> >>> the
> >>> Angle crutch) and toy computers (Raspberries etc.), but advanced
> >>> versions
> >>> available in plugins that would then work only on powerful
> hardware, if
> >>> that is possible. Cheap/old hardware with Mesa (esp.
> single-core CPUs)
> >>> is
> >>> too slow. Better old hardware (like that Intel used above) can
> be kicked
> >>> to work with Mesa. If only one type of OpenGL is possible, I
> strongly
> >>> vote
> >>> for higher quality thingies (dropping hopes in OpenGL1.4
> hardware and
> >>> Angle translating OpenGLES2.0 to DirectX9c), and would like to
> see a
> >>> working example of initializeOpenGLfunctions() on Windows...
> >>>
> >>> Best regards, and good luck and rapid success with trials,
> >>> Georg
> >>>
> >>>
> >>> On Do, 13.02.2014, 09:16, Guillaume Chéreau wrote:
> >>> > OK, I did some tests. So far I have no luck using
> >>> > createWindowContainer: each time the container hides any
> other widget
> >>> > no matter how I try. This is not good because for
> stellarium we need
> >>> > to show first the qml view, and then the normal widgets (for the
> >>> > settings windows) on top of it.
> >>> >
> >>> > I will try to ask the Qt dev how to achieve that.
> >>> >
> >>> > Meanwhile what exactly is the problem with the current qml
> fragment
> >>> > shader? For me it seems to work on windows, linux and OSX.
> Do we
> >>> > have more info about when QDeclarativeView will be
> deprecated? One
> >>> > thing I could do is start to work on the qml UI using
> QtQuick 1.0 in a
> >>> > branch, then later switch it to QtQuick 2.0.
> >>> >
> >>> > gui
> >>> >
> >>> > On Thu, Feb 13, 2014 at 11:41 AM, Guillaume Chéreau
> >>> > <[email protected]
> <mailto:[email protected]>> wrote:
> >>> >> On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti
> >>> <[email protected] <mailto:[email protected]>>
> >>> >> wrote:
> >>> >>> I had the same fear for weeks now that the deprecation of
> >>> QtDeclarative
> >>> >>> will sooner than later hit us. Is anybody working on this?
> >>> >>> Fabien, Guillaume? Anybody else with deep enough insight
> into Qt?
> >>> What
> >>> >>> has
> >>> >>> to be done, where?
> >>> >>
> >>> >> I had a look at this yesterday. The problem is that
> currently Qt
> >>> does
> >>> >> not allow to mix QtQuick 2.0 and widgets very well. There is
> >>> >> QWidget::createWindowContainer() that might help :
> >>> >>
> >>> >>
> >>>
>
> https://blog.qt.digia.com/blog/2013/02/19/introducing-qwidgetcreatewindowcontainer/
> >>> >>
> >>> >> With this we could maybe have the sky + the basic UI
> (bottom and left
> >>> >> bars) written in qml (with QtQuick 2.0), and keep the settings
> >>> windows
> >>> >> as they are now.
> >>> >>
> >>> >> An other way would be to rewrite the entire UI in qml, but
> this would
> >>> >> take a lot of effort.
> >>> >>
> >>> >> Anyway I am going to make more tests to see how we can do the
> >>> >> transition. I think having the bottom and left bars in qml
> would be
> >>> >> an improvement to the code anyway.
> >>> >>
> >>> >> Regards,
> >>> >>
> >>> >> guillaume
> >>> >>
> >>> >>>
> >>> >>> Still very much hoping for a "Yes, I do",
> >>> >>>
> >>> >>> Best regards, Georg
> >>> >>>
> >>> >>>
> >>> >>> On Fr, 10.01.2014, 19:23, Reaves, Timothy wrote:
> >>> >>>> Until this is completed, Stellarium is now completely broken.
> >>> >>>>
> >>> >>>> The shaders the app uses require QtQuick 2.0 now, as that
> is where
> >>> the
> >>> >>>> labs
> >>> >>>> stuff was moved. When moving to QtQuick 2.0, we need to
> replace
> >>> >>>> QDeclarativeView with QQuickView.
> >>> >>>>
> >>> >>>>>From the docs: "When porting from QDeclarativeView to
> QQuickView,
> >>> note
> >>> >>>>> that
> >>> >>>> QDeclarativeItem inherited from QGraphicsView. In contrast,
> >>> QQuickView
> >>> >>>> inherits from QQuickWindow and uses the QWindow
> infrastructure
> >>> >>>> introduced
> >>> >>>> in Qt 5; any QGraphicsView-specific functionality is no
> longer
> >>> >>>> available."
> >>> >>>>
> >>> >>>> This is some major work around the windowing code; dialogs,
> >>> widgets,
> >>> >>>> menus,
> >>> >>>> etc.
> >>> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
>
> ------------------------------------------------------------------------------
> >>> Android apps run on BlackBerry 10
> >>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> >>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> >>> Get your Android app in front of a whole new audience. Start now.
> >>>
> >>>
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> Stellarium-pubdevel mailing list
> >>> [email protected]
> <mailto:[email protected]>
> >>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
> >>>
> >>
>
> ------------------------------------------------------------------------------
> >> Android apps run on BlackBerry 10
> >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> >> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> >> Get your Android app in front of a whole new audience. Start now.
> >>
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> >> Stellarium-pubdevel mailing list
> >> [email protected]
> <mailto:[email protected]>
> >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
> >>
> >
> >
> > --
> > Dipl.-Ing. Dr. Georg Zotti
> > Ludwig Boltzmann Institute for
> > Archaeological Prospection and
> > Virtual Archaeology
> > (LBI ArchPro)
> > Hohe Warte 38
> > A-1190 Wien
> >
> >
> >
> >
>
> ------------------------------------------------------------------------------
> > Android apps run on BlackBerry 10
> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
> > Get your Android app in front of a whole new audience. Start now.
> >
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Stellarium-pubdevel mailing list
> > [email protected]
> <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
>
>
> --
> Guillaume
> [email protected] <mailto:[email protected]>
> +886 970422910 <tel:%2B886%20970422910>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Stellarium-pubdevel mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Stellarium-pubdevel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Stellarium-pubdevel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
