Enabling all OpenGL version in OSG-3.6.5 #1250
-
|
Hi @robertosfield, I'm trying to build an application that uses osgearth, so it requires opengl3 to work with, and I want to use some in-built osg lights that use a fixed-function pipeline like osg::Light. I know that I can implement the lights using the vertex and fragment shaders in opengl3 but, I really want to use other fixed-function pipeline features in the application. Is there any way that I can enable all opengl version in OSG? If I enable all the options such as OSG_GL1_AVAILABLE, OSG_GL2_AVAILABLE, and OSG_GL3_AVAILABLE, with other related options, the code compiles just fine, but when I run the viewer application, it'll not show the model and will give some 'invalid enumerant' and 'invalid operation' errors, which might be occurring due to, me, specifying 'GL3' as OPENGL_PROFILE. Also, I'm keeping the context version as 4.6. Can you please help here? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
The OSG by default will enable all extensions that are available, however, some drivers required GL Core Profile and to use you have to build the OSG without the fixed function pipeline. Personally I think the Khonros' choice of introducing OpenGL Core Profile was a big step back for OpenGL as it's caused a major fracture point that make managing OpenGL based applications over long period far harder. In hindsight Khronos should have kept OpenGL working the way it did with OpenGL 2.x and just focus on successor to OpenGL for the lean and mean API. Khonoros have of course now developed Vulkan which the lean and mean API, and almost all of my work is now focused on the OpenSceneGraph's successor VulkanSceneGraph. So far Vulkan doesn't have this fault line and works well on embedded/mobile systems and desktop system. Like OpenGL itself, the OpenSceneGraph is now in maintenance mode. There are difficulties in OpenGL and the OpenSceneGraph with the whole fracture line of fixed function and shader approaches, and there isn't any easy solution to it and I'm afraid there never will be so it's a case of making do. The other alternative is to port to Vulkan/VulkanSceneGraph. This requires quite a bit of work but they are modern, perform far better and are cleaner and better designed. All within one API you get to use compute, graphics that include latest features like mesh shaders, ray tracing so ti's possible leap-frog what you currently can achieve. |
Beta Was this translation helpful? Give feedback.
-
|
Ah! A huge setback indeed! So basically, either I can port to VulkanSceneGraph or I can implement all the fixed function pipeline features into the osg built on the core profile! |
Beta Was this translation helpful? Give feedback.
-
|
Recent version of osgEarth require a core profile build of the OSG so you are forced to drop the fixed function compatibility, older versions didn't have this requirement so you could possible look back to see which version of osgEarth can work with default build of the OSG. However, if you writing a new application then using legacy APIs like OpenGL, OpenSceneGraph and osgEarth then may not be the most productive route, and you'd be better off using Vulkan, VulkanSceneGraph, vsgCs and/or Pelican Mappings successor to osgEarth. The late are newer and less feature complete but raise the bar of performance and advanced capabilities. As time goes on the fact that OpenGL and OpenSceneGraph are in maintenance mode and just maintain for legacy applications is likely to hold your applications back compared to ones that embrace Vulkan etc. Successful software can last decades and much can change during this period - just look at how the much OpenGL and hardware has changes since OpenSceneGraph inception nearly a quart of century ago. Over 2 decades into it's life folks are still using it. Fast forward another decade and will OpenGL and OpenSceneGraph still be relevant even if you can still compile and run applications using them. My expectation though this decade folks will transition to the likes of VulkanSceneGraph to future proof themselves and remain competitive. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, makes sense to me! The application I'm working with is already built on osgearth and OSG-3.6.5. I better be creating new applications using the latest APIs and libraries for long-term support. |
Beta Was this translation helpful? Give feedback.
-
|
No, I don't think it's a setback. Fixed function pipeline is obsolete since many many years and ignoring this is not a mistake of OSG.
…On 30. Juli 2023 04:17:08 MESZ, Harsh Patel ***@***.***> wrote:
Ah! A huge setback indeed! So basically, either I can port to
VulkanSceneGraph or I can implement all the fixed function pipeline
features into the osg built on the core profile!
--
Reply to this email directly or view it on GitHub:
#1250 (reply in thread)
You are receiving this because you are subscribed to this thread.
Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
The OSG by default will enable all extensions that are available, however, some drivers required GL Core Profile and to use you have to build the OSG without the fixed function pipeline.
Personally I think the Khonros' choice of introducing OpenGL Core Profile was a big step back for OpenGL as it's caused a major fracture point that make managing OpenGL based applications over long period far harder. In hindsight Khronos should have kept OpenGL working the way it did with OpenGL 2.x and just focus on successor to OpenGL for the lean and mean API.
Khonoros have of course now developed Vulkan which the lean and mean API, and almost all of my work is now focused on the OpenSceneGraph's succe…