Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Maxim Stere]

Hi Robert,

You are right, Windows is missing most of the GL calls from 1.3 and on. 

I'm using Win7 VS2015 with OSG 3.4.1.

... 

Thank you!

Cheers,
Maxim


Thank you,
--Maxim

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72742#72742





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Robert Osfield]

Hi Maxim,

We just add #define as required rather than attempting to import all
features. As new GL features are added we may find temporarily a
#define is missed, when this occurs we add it as soon as we know about
it.

Not all GL headers are up to date so we generally have to backport
those missing features, WIndows gl.h is particular problem as it's
been deliberately held back my Microsoft.  Could you let us know which
version of the OSG and what platform you've seen this issue for?

Robert.

On 9 January 2018 at 19:05, Maxim Stere  wrote:
> Hi,
>
> Has this been resolved, or are there any news on keeping GL extensions 
> updated?
>
> I just ran into a problem where
>
> Code:
>
> #define GL_READ_ONLY 0x88B8
>
>
>
> was missing from  GL_VERSION_1_5 section. If GLEW was 
> included it of course worked.
>
> So having extensions updated to 4.6 would be very useful...
>
> ...
>
> Thank you!
>
> Cheers,
> Maxim
>
> 
> Thank you,
> --Maxim
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=72694#72694
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Maxim Stere]

Hi,

Has this been resolved, or are there any news on keeping GL extensions updated?

I just ran into a problem where 

Code:

#define GL_READ_ONLY 0x88B8



was missing from  GL_VERSION_1_5 section. If GLEW was 
included it of course worked. 

So having extensions updated to 4.6 would be very useful...

... 

Thank you!

Cheers,
Maxim


Thank you,
--Maxim

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72694#72694





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Robert Osfield]

Hi Paul,

On Fri, Feb 5, 2010 at 8:43 PM, Paul Martz pma...@skew-matrix.com wrote:
  2) Centralized management of extensions via external libs doesn't
 fit well with the ability to
      extend the OSG in 3rd party NodeKits, where the NodeKits support
 extensions that that
      the OSG version didn't support when shipped - these 3rd party
 NodeKits would be forced
      to only use the same version of the extension library that the
 OSG was linked to.

 This is really not an issue. We discussed something similar to this in
 OpenGL capture/logging in OSG and I'll paraphrase what I said there:
 External node kit developers can cook their own extension access solution
 until the extension is available (in core OSG or OSG's external feature
 support dependency).

If the external node kit developers have to cook up their own
extensions then we really aren't any further forward in try to unify
things.  What happens if we merge the 3rd party nodekits with the core
OSG?  Do we then convert across?

The better solution is to make sure that we have an extensions system
that is easily extensible.  A completely centralized system doesn't
achieve this.

  3) We need to be able to disable extensions when they don't work.

 (I'd question whether or not this feature even works in OSG today, given
 that OSG doesn't even query the extension string for many of the extension
 features it uses. But...) This is an interesting and possibly useful
 feature, so it should definitely be in any solution that you endorse before
 we start coding a submission.

 And finally regarding the dependency issue. It doesn't have to be a
 dependency any more than OpenThreads is a dependency. It could be an
 internal self-contained module. I know, I know, you're opposed to
 centralizing this. :-)

An external dependency even if compiled part of the core OSG is still
problematic as I said in my earlier post.  Such an approach will not
be merged with the core OSG as it's a backward step in too many areas.

This doesn't preclude us for coming up with a better way of organizing
extensions.  Whatever system we come up with it has extensionble, a GL
extension system that itself it's extensible rather defeats the whole
point of GL extensions.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Paul Martz]

Wojciech Lewandowski wrote:
Lots of older OpenGL extensions are now included in OpenGL specification 
(rel. 3.2). I'd like to propose a small cleaning movement of OSG sources


Hi Wojtek --

I agree that the kind of scrubbing you've proposed would break backwards 
compatibility, as Gordon described. However, OSG definitely needs some 
clean up and fixes in the area of querying for feature support and 
obtaining the appropriate entry points.


I was waiting for Robert to chime in on this thread, but I think I speak 
on his behalf when I say he supports a clean up effort. In the thread 
OpenGL capture/logging in OSG from mid-December, Robert said: I 
would, however, be happy to see a more formalized system for extension 
setup, as the current distributed approach has let the styles of 
implementation diverge as a series of different developers have got 
their hands dirty contributing code.


So now we just need to decide exactly what we mean by clean up. :-)

First, I don't want to limit the discussion by using the word 
extension. We should consider cleaning up code that queries for the 
presence of OpenGL features. They might be extensions, or they might be 
core functionality.


In most any OpenGL literature that you read, querying for feature 
support at run time should be done as follows;


  If the feature is part of the run time GL version's core spec
Use the core interface
  else if an ARB extension supports the feature
Use the ARB interface
  else if an EXT extension supports the feature
Use the EXT interface
  else
Similar checks for possibly multiple vendor extensions

OSG should do this as well, but in most cases it doesn't. Instead, OSG 
simply checks for the availability of entry points and uses them if 
present. This is a dangerous approach, as many drivers contain entry 
points for the purpose of testing beta features. This is one thing I'd 
definitely like to see cleaned up.


(In fact, this is currently a bug in OSG. If I open a v3.0 context, OSG 
uses the v3.2 core FBO entry points exposed by my device driver, not the 
ARB FBO extension interface.)


I'd also like to see a function pointer name clean up effort. Function 
pointers should be named generically (glGenBuffers, not 
glGenBuffersARB or glGenBuffersEXT). In 90% of all features, we're 
just concerned with which feature it references, not which specific 
extension interface is being used. With an initialization system like I 
described in the pseudocode above, or even with OSG as it currently 
stands today, the function pointer could be loaded with just about any 
interface entry point, so it should have a name that isn't 
interface-specific.


Another thing to consider is the wrapper pattern currently employed in 
many of OSG's OpenGL function pointers. The wrapper pattern has the 
following form:


  void glFunctionWRAPPER( ... )
  {
if( _glFunction != NULL )
  _glFunction( ... );
else
  Log an error
  }

Checking on the validity of the pointer every time app code calls into 
the wrapper seems a little heavy. I'd rather see a system that lets 
calling code query for the presence or absence of a feature. If the 
feature is absent, calling code should avoid calling into the feature's 
function wrappers, eliminating the need for per-wrapper checks for 
function pointer validity. (I believe this is a better approach for 
calling code too, as that code will usually want to take one path or 
another based on the presence or absence of certain GL features.)


(Note that I'm not opposed to wrappers in general. An OpenGL wrapper 
system should probably be at the core of every major OpenGL app. It 
simply needs to be designed for lightweight production builds.)


There's the topic of centralization. I've proposed moving all OpenGL 
function pointers an related initialization into a single class. Among 
other reasons, this would make it easier for future developers to ensure 
that they're implementing feature query and initialization consistent 
with OSG's best practice. But Robert has expressed disagreement with 
this approach (again, see the thread OpenGL capture/logging in OSG). 
So for now, any type of new system we implement for feature querying and 
initialization will need to be cut and pasted across several source files.


Finally, another thing to consider is replacing our existing feature 
query infrastructure with something like GLEW. GLEW is lightweight, 
easily extensible, and already handles much of what we need for GL 
feature support. But we have discussed this in the past, and if I 
remember correctly Robert was opposed to GLEW on the grounds of the new 
third party dependency it would require.


Well, I know this is a bit more extensive that the slow, piece-by-piece 
clean up effort that you had in mind with your original post. But I 
wanted to throw this out there for consideration by you and the rest of 
the community.


If we can all come to some consensus on how to proceed, we can start 

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Chris 'Xenon' Hanson]

 Good topic, Paul.

On 2/5/2010 9:02 AM, Paul Martz wrote:
 There's the topic of centralization. I've proposed moving all OpenGL
 function pointers an related initialization into a single class. Among
 other reasons, this would make it easier for future developers to ensure
 that they're implementing feature query and initialization consistent
 with OSG's best practice. But Robert has expressed disagreement with
 this approach (again, see the thread OpenGL capture/logging in OSG).
 So for now, any type of new system we implement for feature querying and
 initialization will need to be cut and pasted across several source files.

  I would be in support of _some_ centralization. I feel like maybe we could 
put generic
support code for this system in one place, and somehow call it from wherever it 
was
needed. Could we somehow come up with a template that did the dirty work for 
us, and just
employ the template in a distributed fashion? A basic template could do 
everything most
situation would need, and maybe a more advanced and customizable template with 
some sort
of callback or functor could be employed in situations that needed to go beyond 
the simple
case?

 Finally, another thing to consider is replacing our existing feature
 query infrastructure with something like GLEW. GLEW is lightweight,
 easily extensible, and already handles much of what we need for GL
 feature support. But we have discussed this in the past, and if I
 remember correctly Robert was opposed to GLEW on the grounds of the new
 third party dependency it would require.

  I'm not wholly opposed to GLEW.

  http://glew.sourceforge.net/

  I agree about more dependencies, but I also dislike re-inventing the wheel. I 
know GLEW
is attaining popular support, and the new OpenGL SuperBible uses it extensively 
(funny
joke!). So, it's not something that's a relative unknown.

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
There is no Truth. There is only Perception. To Perceive is to Exist. - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Paul Martz]

Paul Martz wrote:
(In fact, this is currently a bug in OSG. If I open a v3.0 context, OSG 
uses the v3.2 core FBO entry points exposed by my device driver, not the 
ARB FBO extension interface.)


Open mouth, insert foot: This is not a bug in OSG. As everyone knows, 
FBO was part of v3.0. I was temporarily confused with geometry shaders. 
Sorry!

   -Paul

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Robert Osfield]

Hi Paul et. al,

On Fri, Feb 5, 2010 at 4:02 PM, Paul Martz pma...@skew-matrix.com wrote:
 Finally, another thing to consider is replacing our existing feature query
 infrastructure with something like GLEW. GLEW is lightweight, easily
 extensible, and already handles much of what we need for GL feature support.
 But we have discussed this in the past, and if I remember correctly Robert
 was opposed to GLEW on the grounds of the new third party dependency it
 would require.

My opposition to API's like GLEW are:

  1) Don't typically support multiple graphics contexts - a critical
issue under Windows as the
  extension entry points can be different for each graphics context

  2) Centralized management of extensions via external libs doesn't
fit well with the ability to
  extend the OSG in 3rd party NodeKits, where the NodeKits support
extensions that that
  the OSG version didn't support when shipped - these 3rd party
NodeKits would be forced
  to only use the same version of the extension library that the
OSG was linked to.

  3) We need to be able to disable extensions when they don't work.

  4) Extra dependency

For sure we can do better than what we currently do in an adhoc way,
but it absolutely has to do the job better than the likes of GLEW, it
*has* to decentralized, it *has* to support multiple graphics
contexts, it *has* to extensible.  For all the flaws of the current
extension support in the OSG it does at least do all of these and has
proven workable for a decade now.  The attraction of GLEW and similar
libs is pretty skin deep.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Chris 'Xenon' Hanson]

On 2/5/2010 11:16 AM, Robert Osfield wrote:
 For sure we can do better than what we currently do in an adhoc way,
 but it absolutely has to do the job better than the likes of GLEW, it
 *has* to decentralized, it *has* to support multiple graphics
 contexts, it *has* to extensible.  For all the flaws of the current
 extension support in the OSG it does at least do all of these and has
 proven workable for a decade now.  The attraction of GLEW and similar
 libs is pretty skin deep.

  Maybe then, we should start writing down the actual requirements of what we 
need, and
when that looks solid we can figure out how to achieve all of them.

 Robert.

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
There is no Truth. There is only Perception. To Perceive is to Exist. - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Paul Martz]

Hi Robert -- Thanks for your comments on this. I'd really appreciate 
feedback on the other items I discussed in my email, before I proceed 
with any submissions, so more input is welcome.


Robert Osfield wrote:

On Fri, Feb 5, 2010 at 4:02 PM, Paul Martz pma...@skew-matrix.com wrote:

Finally, another thing to consider is replacing our existing feature query
infrastructure with something like GLEW. GLEW is lightweight, easily

...

  1) Don't typically support multiple graphics contexts - a critical
issue under Windows as the
  extension entry points can be different for each graphics context


Right, but something like GLEW might support multiple contexts.


  2) Centralized management of extensions via external libs doesn't
fit well with the ability to
  extend the OSG in 3rd party NodeKits, where the NodeKits support
extensions that that
  the OSG version didn't support when shipped - these 3rd party
NodeKits would be forced
  to only use the same version of the extension library that the
OSG was linked to.


This is really not an issue. We discussed something similar to this in 
OpenGL capture/logging in OSG and I'll paraphrase what I said there: 
External node kit developers can cook their own extension access 
solution until the extension is available (in core OSG or OSG's external 
feature support dependency).



  3) We need to be able to disable extensions when they don't work.


(I'd question whether or not this feature even works in OSG today, given 
that OSG doesn't even query the extension string for many of the 
extension features it uses. But...) This is an interesting and possibly 
useful feature, so it should definitely be in any solution that you 
endorse before we start coding a submission.


And finally regarding the dependency issue. It doesn't have to be a 
dependency any more than OpenThreads is a dependency. It could be an 
internal self-contained module. I know, I know, you're opposed to 
centralizing this. :-)

   -Paul


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Paul Martz]

Paul Martz wrote:

  1) Don't typically support multiple graphics contexts - a critical
issue under Windows as the
  extension entry points can be different for each graphics context


Right, but something like GLEW might support multiple contexts.


For the record, GLEW does support multiple contexts:
http://www.opengl.org/sdk/libs/GLEW/
   -Paul



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Wojciech Lewandowski]

Hi Everyone,

Lots of older OpenGL extensions are now included in OpenGL specification (rel. 
3.2). I'd like to propose a small cleaning movement of OSG sources
 
Every time we submit a change of some OSG file we could also check for obsolete 
GL extension:  EXT, ARB, NV, ATI etc symbols and replace them with most current 
OpenGL names.

Idea is to take it easy and slow. Lets change only these header and source 
files which would get submitted anyways. Changing and submitting all OSG source 
at once could easily swamp Robert.

Cheers,
Wojtek Lewandowski


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org