Help needed to update our use of OpenGL

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Help needed to update our use of OpenGL

John W. Eaton
Administrator
I would like to update Octave's use of OpenGL so that it avoids
deprecated OpenGL features but I have little real experience with OpenGL
programming and could use some help.

As I understand it, these changes will primarily involve migrating from
"immediate mode vertex attribute specification" (code starting with a
call to glBegin ending with a call to glEnd) to using vertex
array/buffer objects and modifying the way lighting is handled.

Are there any experts out there who could help with this job?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Help needed to update our use of OpenGL

mmuetzel
What needs to be changed with the way lighting is handled?
I am by no means an expert in OpenGL. But I don't remember using deprecated
functions when I added the light graphic object.
If you could point to the problematic functions or constructs, I might be
able to have a look at it.

If someone else wants to help or prefer to do that, I won't mind either. ;-)

Markus



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Help needed to update our use of OpenGL

John W. Eaton
Administrator
On 09/12/2018 11:21 AM, mmuetzel wrote:
> What needs to be changed with the way lighting is handled?
> I am by no means an expert in OpenGL. But I don't remember using deprecated
> functions when I added the light graphic object.
> If you could point to the problematic functions or constructs, I might be
> able to have a look at it.
>
> If someone else wants to help or prefer to do that, I won't mind either. ;-)

To begin, see this page:

   https://www.khronos.org/opengl/wiki/Legacy_OpenGL

also this page specifically about lighting notes that the fixed-pipeline
glMaterial and glLight functions are part of the legacy APIs:

   https://www.khronos.org/opengl/wiki/How_lighting_works

Here's a interesting blog post about the difficulty (or not, depending
on the specific features used) of moving to current core OpenGL
functionality:

   https://retokoradi.com/2014/03/30/opengl-transition-to-core-profile/

 From what I see with Octave, it looks like we have some work to do.
OTOH, our use of OpenGL is fairly localized and does not seem overly
complicated, so maybe it will not be an impossible task.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Help needed to update our use of OpenGL

Pantxo
Hi,

Yes, among what we use, the so called fixed pipeline is deprecated and won't
be necessarily part of future implementations. At best, those functions will
get no attention and stay there but become more and more buggy without a
hope for a fix.
The GL_FEEDBACK mode, on which we rely for printing, is also deprecated and
I have no hope that e.g. the bug below will get fixed:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=48689

VTK is already using modern OpenGL so it may be worth looking at their code.
For printing, they directly feed gl2ps with primitives they fetched in a
transform feedback buffer(see [1] and [2]).
 
I never programmed anything in modern OpenGL, so I can't really help, but if
such restructuring should happen I'd be happy to discuss the opportunity of
abstracting our current opengl_renderer into something more general, say
base_render. The latter would be "rendering technology agnostic" (actual
drawing and property changes are done in pure virtual functions) and would
serve as a base for the opengl_renderer and eventually for any kind of 2D-3D
renderer someone may want to implement (I was thinking about qt_renderer,
cairo_renderer for 2D printing).

Pantxo

[1] http://www.geuz.org/pipermail/gl2ps/2016/000424.html
[2]
https://www.vtk.org/doc/release/7.1/html/classvtkOpenGLGL2PSHelperImpl.html



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Help needed to update our use of OpenGL

John W. Eaton
Administrator
On 09/12/2018 03:54 PM, Pantxo wrote:

> Yes, among what we use, the so called fixed pipeline is deprecated and won't
> be necessarily part of future implementations. At best, those functions will
> get no attention and stay there but become more and more buggy without a
> hope for a fix.
> The GL_FEEDBACK mode, on which we rely for printing, is also deprecated and
> I have no hope that e.g. the bug below will get fixed:
> https://savannah.gnu.org/bugs/?func=detailitem&item_id=48689


That's also my thinking.  Even though these interfaces are not likely to
go away any time soon, it probably doesn't help us to continue using them.

> VTK is already using modern OpenGL so it may be worth looking at their code.
> For printing, they directly feed gl2ps with primitives they fetched in a
> transform feedback buffer(see [1] and [2]).

Thanks for the pointers.  Having examples is helpful.

> I never programmed anything in modern OpenGL, so I can't really help, but if
> such restructuring should happen I'd be happy to discuss the opportunity of
> abstracting our current opengl_renderer into something more general, say
> base_render. The latter would be "rendering technology agnostic" (actual
> drawing and property changes are done in pure virtual functions) and would
> serve as a base for the opengl_renderer and eventually for any kind of 2D-3D
> renderer someone may want to implement (I was thinking about qt_renderer,
> cairo_renderer for 2D printing).
Yes, I think this kind of refactoring would be good.  We could also move
in this direction independently of updating our use of OpenGL.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Help needed to update our use of OpenGL

Pantxo

>
>> I never programmed anything in modern OpenGL, so I can't really help,
>> but if
>> such restructuring should happen I'd be happy to discuss the
>> opportunity of
>> abstracting our current opengl_renderer into something more general, say
>> base_render. The latter would be "rendering technology agnostic" (actual
>> drawing and property changes are done in pure virtual functions) and
>> would
>> serve as a base for the opengl_renderer and eventually for any kind
>> of 2D-3D
>> renderer someone may want to implement (I was thinking about
>> qt_renderer,
>> cairo_renderer for 2D printing).
> Yes, I think this kind of refactoring would be good.  We could also
> move in this direction independently of updating our use of OpenGL.
>
> jwe


Yes, and I already gave it a shot independently a few month ago but got
lost quite early when trying to make a general interface for glCallList,
which happens to be one of the features we will have to reimplement when
switching to modern OpenGL API. That is why I am under the impression
that the two goals are not completely independent.

Pantxo



Reply | Threaded
Open this post in threaded view
|

Aw: Re: Help needed to update our use of OpenGL

mmuetzel
In reply to this post by John W. Eaton
> Gesendet: Mittwoch, 12. September 2018 um 19:00 Uhr
> Von: "John W. Eaton" <[hidden email]>
> An: mmuetzel <[hidden email]>, [hidden email]
> Betreff: Re: Help needed to update our use of OpenGL
>
> On 09/12/2018 11:21 AM, mmuetzel wrote:
> > What needs to be changed with the way lighting is handled?
> > I am by no means an expert in OpenGL. But I don't remember using deprecated
> > functions when I added the light graphic object.
> > If you could point to the problematic functions or constructs, I might be
> > able to have a look at it.
> >
> > If someone else wants to help or prefer to do that, I won't mind either. ;-)
>
> To begin, see this page:
>
>    https://www.khronos.org/opengl/wiki/Legacy_OpenGL
>
> also this page specifically about lighting notes that the fixed-pipeline
> glMaterial and glLight functions are part of the legacy APIs:
>
>    https://www.khronos.org/opengl/wiki/How_lighting_works

IIRC, that is the page I used as a reference to implement lighting.  Looks like
I completely ignored or forgot about the deprecation warning at the top of the
page... :-/

As a side note: GLSL was first introduced with OpenGL 2.0.  The default OpenGL
version that is supported by Windows (without drivers) is OpenGL 1.1 (software
rendering).  Most graphic hardware should be able to support OpenGL 2.0 now
(released 2004).  But users need to install the appropriate drivers for their
graphics hardware to run software that requires OpenGL 2.0.  That might not be
necessary for Octave since we ship an OpenGL software renderer with the Windows
installer.
I don't know how the Qt software fallback would behave with this in mind.

I hope we won't need to support both OpenGL "dialects"...

Markus