OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

Goto page 1, 2  Next
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
Wojciech Lewandowski
Guest





PostPosted: Mon Feb 01, 2010 11:25 am    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

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

------------------
Post generated by Mail2Forum
Back to top
Tomlinson, Gordon
Guest





PostPosted: Mon Feb 01, 2010 1:46 pm    Post subject:
Lets slowly update extension gl symbols to latestOpenGL specification with each submission.
Reply with quote

Would these only be obsolete if your using Opengl 3.2 ?

What about when I'm on a machine and graphics card that only supports say OpenGL 2.1,

this is a very common case for us were users are in very controlled environments and running on older equipment that is unlikely to get upgraded or new drivers etc.

Gordon Tomlinson
Product Manager 3d Technology & Future Products
Overwatch®
[b][i]An Operating Unit of Textron Systems

[/i][/b]




From: [mailto:] On Behalf Of Wojciech Lewandowski
Sent: Monday, February 01, 2010 6:24 AM
To:
Subject: Lets slowly update extension gl symbols to latestOpenGL specification with each submission.



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

------------------
Post generated by Mail2Forum
Back to top
Wojciech Lewandowski
Guest





PostPosted: Mon Feb 01, 2010 3:24 pm    Post subject:
Lets slowly update extension gl symbols tolatestOpenGL specification with each submission.
Reply with quote

Hi Gordon,

What about when I'm on a machine and graphics card that only supports say OpenGL 2.1,

I guess this is an argument for reverse approach ie to use common denominator and use extension versions in their earliest forms....
It is a valid point, I must admit I have not thought about it. Maybe chnging _EXT, _ARB to non suffix versions is not such a good idea after all. Maybe it was too early to come up with this proposal...

Wojtek



----- Original Message -----
Quote:
From: Tomlinson, Gordon (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
To: OpenSceneGraph Users (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
Sent: Monday, February 01, 2010 2:47 PM
Subject: Re: Lets slowly update extension gl symbols tolatestOpenGL specification with each submission.


Would these only be obsolete if your using Opengl 3.2 ?

What about when I'm on a machine and graphics card that only supports say OpenGL 2.1,

this is a very common case for us were users are in very controlled environments and running on older equipment that is unlikely to get upgraded or new drivers etc.

Gordon Tomlinson
Product Manager 3d Technology & Future Products
Overwatch®
[b][i]An Operating Unit of Textron Systems

[/i][/b]




From: [mailto:] On Behalf Of Wojciech Lewandowski
Sent: Monday, February 01, 2010 6:24 AM
To:
Subject: Lets slowly update extension gl symbols to latestOpenGL specification with each submission.



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








------------------
Post generated by Mail2Forum
Back to top
Tomlinson, Gordon
Guest





PostPosted: Mon Feb 01, 2010 3:29 pm    Post subject:
Lets slowly update extension gl symbolstolatestOpenGL specification with each submission.
Reply with quote

Nothing against the proposal, simplification and clean up is good ...

I just know I fall into the situation where large groups of my end users will be on what we thinks of as very old cards ( and where they cannot update or update easily ) and my paranoia then takes me down the road of oh heck.... Smile


Gordon Tomlinson
Product Manager 3d Technology & Future Products
Overwatch®
[b][i]An Operating Unit of Textron Systems

[/i][/b]




From: [mailto:] On Behalf Of Wojciech Lewandowski
Sent: Monday, February 01, 2010 10:24 AM
To: OpenSceneGraph Users
Subject: Re: Lets slowly update extension gl symbolstolatestOpenGL specification with each submission.



Hi Gordon,

What about when I'm on a machine and graphics card that only supports say OpenGL 2.1,

I guess this is an argument for reverse approach ie to use common denominator and use extension versions in their earliest forms....
It is a valid point, I must admit I have not thought about it. Maybe chnging _EXT, _ARB to non suffix versions is not such a good idea after all. Maybe it was too early to come up with this proposal...

Wojtek



----- Original Message -----
Quote:
From: Tomlinson, Gordon (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
To: OpenSceneGraph Users (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
Sent: Monday, February 01, 2010 2:47 PM
Subject: Re: Lets slowly update extension gl symbols tolatestOpenGL specification with each submission.


Would these only be obsolete if your using Opengl 3.2 ?

What about when I'm on a machine and graphics card that only supports say OpenGL 2.1,

this is a very common case for us were users are in very controlled environments and running on older equipment that is unlikely to get upgraded or new drivers etc.

Gordon Tomlinson
Product Manager 3d Technology & Future Products
Overwatch®
[b][i]An Operating Unit of Textron Systems

[/i][/b]




From: [mailto:] On Behalf Of Wojciech Lewandowski
Sent: Monday, February 01, 2010 6:24 AM
To:
Subject: Lets slowly update extension gl symbols to latestOpenGL specification with each submission.



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








------------------
Post generated by Mail2Forum
Back to top
Wojciech Lewandowski
Guest





PostPosted: Mon Feb 01, 2010 3:42 pm    Post subject:
Lets slowly update extension glsymbolstolatestOpenGL specification with each submission.
Reply with quote

The longer I think of it the more I agree with your earlier post. I realized we could start such extension cleanning but only if OSG had defined bottom line requiremnt for OGL version. As long as its not clealy defined, such clean up practice may be more problematic than frutiful.

Wojtek

----- Original Message -----
Quote:
From: Tomlinson, Gordon (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
To: OpenSceneGraph Users (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
Sent: Monday, February 01, 2010 4:30 PM
Subject: Re: Lets slowly update extension glsymbolstolatestOpenGL specification with each submission.


Nothing against the proposal, simplification and clean up is good ...

I just know I fall into the situation where large groups of my end users will be on what we thinks of as very old cards ( and where they cannot update or update easily ) and my paranoia then takes me down the road of oh heck.... Smile


Gordon Tomlinson
Product Manager 3d Technology & Future Products
Overwatch®
[b][i]An Operating Unit of Textron Systems

[/i][/b]




From: [mailto:] On Behalf Of Wojciech Lewandowski
Sent: Monday, February 01, 2010 10:24 AM
To: OpenSceneGraph Users
Subject: Re: Lets slowly update extension gl symbolstolatestOpenGL specification with each submission.



Hi Gordon,

What about when I'm on a machine and graphics card that only supports say OpenGL 2.1,

I guess this is an argument for reverse approach ie to use common denominator and use extension versions in their earliest forms....
It is a valid point, I must admit I have not thought about it. Maybe chnging _EXT, _ARB to non suffix versions is not such a good idea after all. Maybe it was too early to come up with this proposal...

Wojtek



----- Original Message -----
Quote:
From: Tomlinson, Gordon (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
To: OpenSceneGraph Users (
Only registered users can see emails on this board!
Get registred or enter the forums!
)
Sent: Monday, February 01, 2010 2:47 PM
Subject: Re: Lets slowly update extension gl symbols tolatestOpenGL specification with each submission.


Would these only be obsolete if your using Opengl 3.2 ?

What about when I'm on a machine and graphics card that only supports say OpenGL 2.1,

this is a very common case for us were users are in very controlled environments and running on older equipment that is unlikely to get upgraded or new drivers etc.

Gordon Tomlinson
Product Manager 3d Technology & Future Products
Overwatch®
[b][i]An Operating Unit of Textron Systems

[/i][/b]




From: [mailto:] On Behalf Of Wojciech Lewandowski
Sent: Monday, February 01, 2010 6:24 AM
To:
Subject: Lets slowly update extension gl symbols to latestOpenGL specification with each submission.



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











------------------
Post generated by Mail2Forum
Back to top
Paul Martz
Guest





PostPosted: Fri Feb 05, 2010 4:03 pm    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

Wojciech Lewandowski wrote:
Quote:
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
making changes and submissions. (Hopefully this doesn't fall by the
wayside, as Sukender's proposal for plugin transformations did.)
-Paul




------------------
Post generated by Mail2Forum
Back to top
Chris 'Xenon' Hanson
Guest





PostPosted: Fri Feb 05, 2010 4:17 pm    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

Good topic, Paul.

On 2/5/2010 9:02 AM, Paul Martz wrote:
Quote:
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?

Quote:
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


------------------
Post generated by Mail2Forum
Back to top
Paul Martz
Guest





PostPosted: Fri Feb 05, 2010 5:58 pm    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

Paul Martz wrote:
Quote:
(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



------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11311

PostPosted: Fri Feb 05, 2010 6:16 pm    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

Hi Paul et. al,

On Fri, Feb 5, 2010 at 4:02 PM, Paul Martz <> wrote:
Quote:
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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Chris 'Xenon' Hanson
Guest





PostPosted: Fri Feb 05, 2010 6:59 pm    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

On 2/5/2010 11:16 AM, Robert Osfield wrote:
Quote:
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.

Quote:
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


------------------
Post generated by Mail2Forum
Back to top
Paul Martz
Guest





PostPosted: Fri Feb 05, 2010 8:45 pm    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

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:
Quote:
On Fri, Feb 5, 2010 at 4:02 PM, Paul Martz <> wrote:
Quote:
Finally, another thing to consider is replacing our existing feature query
infrastructure with something like GLEW. GLEW is lightweight, easily
...
Quote:
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.

Quote:
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).

Quote:
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. Smile
-Paul




------------------
Post generated by Mail2Forum
Back to top
Paul Martz
Guest





PostPosted: Fri Feb 05, 2010 10:21 pm    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

Paul Martz wrote:
Quote:
Quote:
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





------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11311

PostPosted: Sun Feb 07, 2010 1:50 pm    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

Hi Paul,

On Fri, Feb 5, 2010 at 8:43 PM, Paul Martz <> wrote:
Quote:
Quote:
 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.

Quote:
Quote:
 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. Smile

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
dieslower81
Newbie


Joined: 15 Feb 2010
Posts: 17

PostPosted: Tue Jan 09, 2018 7:05 pm    Post subject:
Reply with quote

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 <osg/BufferObject> 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
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11311

PostPosted: Tue Jan 09, 2018 8:35 pm    Post subject:
Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Reply with quote

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:
Quote:
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 <osg/BufferObject> 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








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts inactive Culling and update Near/Far Mathieu Submission 1 Mon Dec 04, 2017 9:46 am View latest post
No new posts Draw thread per opengl context instea... BenM General 6 Thu Nov 09, 2017 2:23 pm View latest post
No new posts RayTracedTechnique hangs with Intel H... Clement General 6 Fri Sep 01, 2017 7:12 am View latest post
No new posts Adding WOFF extension to freetype plugin robertosfield Submission 0 Mon Jul 17, 2017 3:48 pm View latest post
No new posts OpenGL Mottaghi, Arman General 1 Sun Jul 09, 2017 11:28 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP