OK, finally I completely reverted the current planet shadow's code.
Even though the rendering is good, it suffers from several defects:
- very slow, mainly because the fragment shaders loops through all the
solar system objects (per pixel!)
- uses OpenGL features not very portable without real need (GL_RGBA32F
textures)
- badly integrated (the StelPainter class should not know about planet
shadows!)
This codes needs to be re-worked in a dedicated branch, not in trunk.
So Guillaume one of the problems is now fixed.
Fabien
On Fri, May 23, 2014 at 11:18 PM, Fabien Chéreau
<[email protected]>wrote:
>
>
>
> On Fri, May 23, 2014 at 11:14 PM, Fabien Chéreau <[email protected]
> > wrote:
>
>> Hi,
>>
>> On Thu, May 22, 2014 at 11:41 AM, Guillaume Chereau <
>> [email protected]> wrote:
>>
>>> Hello,
>>>
>>> The compilation of stellarium is broken with the new release of Qt (Qt
>>> 5.3) due to a change of API in QOpenglFunctions class.
>>>
>>> I consider this a regression of Qt, and I filled a bug report:
>>> https://bugreports.qt-project.org/browse/QTBUG-39095
>>>
>>> That being said, I tried the Windows ANGLE version of Qt, and it seems
>>> to work fine, at least on my Windows 7 machine.
>>>
>>> If we only use OpenGL ES 2 API, and compile with ANGLE on Windows, we
>>> don't need to use the QOpenglFunctions class at all, and I feel that it
>>> would actually be the easiest solution. I created a branch to work on
>>> that: lp:~guillaume.chereau/stellarium/angle-opengl
>>>
>>> In the core of Stellarium there is only one opengl call that is not
>>> Opengl ES 2 compatible: in the PlanetShadows module. I think it would
>>> be trivial to change the code a bit to make it OpenGL ES 2 compliant.
>>>
>>
>> Yes there is some work to be done on this code.. Also there was a patch
>> that we reverted some month ago because it was very slow and used non
>> standard opengl calls. It would really be necessary to re-work that.
>>
>
> More precisely, it was in commit 6589 that Jörg de-activated planet shaow
> code, but it's at runtime only, so the non openglES2 calls remain.
>
>
>>
>>
>>>
>>> There are also a few plugins that won't compile with OpenGL ES 2 but I
>>> also think the work needed to make them work with ES 2 would be easier
>>> than the work needed to make Stellarium work with Openg GL Desktop on
>>> Windows.
>>>
>>> What do you think?
>>>
>>
>> Fine for me, but I'm a bit concerned with side effects on some
>> pateforms... For the const problem, it's also possible to create a local
>> instance of QOpenGLFunctions.
>>
>> Fabien
>>
>>
>>>
>>> Regards,
>>>
>>> gui
>>>
>>>
>>>
>>> --
>>> Guillaume Chéreau <[email protected]>
>>> http://www.noctua-software.com
>>> tel: +886-970-422-910
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos.
>>> Get unparalleled scalability from the best Selenium testing platform
>>> available
>>> Simple to use. Nothing to install. Get started now for free."
>>> http://p.sf.net/sfu/SauceLabs
>>> _______________________________________________
>>> Stellarium-pubdevel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>>>
>>
>>
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Stellarium-pubdevel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
