Moving an application from compatibility profile to core profile: what changes and how much effort?

[CrabExtra]

I'm looking into moving an OpenSceneGraph application from the compatibility profile build to core profile, and I'm trying to understand what that actually involves before committing to it.
I've read the existing threads on building OSG with OPENGL_PROFILE=GLCORE, and I understand the headline point that core means no fixed function pipeline, so everything in the scene graph has to be shader based. What I can't judge from the outside is the rest of it.

How do the two modes actually differ from OSG's side, beyond the build flags?
What has to change in an application for it to work under core?
Is this a realistic thing to attempt, or is it something you'd advise against?
Roughly how much effort does it tend to be?
If anyone here has been through this migration, I'd be interested in what took the most time and what you didn't see coming. Sample code or a project I can look at would be very welcome.

Thanks.

[XenonofArcticus]

It can be done. Mostly it's a matter of either hand-writing shaders or using a shadergen tool (OSG includes one, though it's not super full-featured) whenever geometry is added to the scenegraph or changed. If you mostly load data and then just view it without loading / adding / changing data, it can be pretty benign. If you actively change the scene geometry (other than just the viewpoint, etc) it can be more cumbersome. From OSG's side, it disables a lot of legacy OpenGL code, and replaces it with stubs that will log errors when they get hit. Effort is completely impossible to estimate without knowing more. It is definitely possible and feasible for most applications. Generally, the trick is to build OSG with GLCORE< and then see what doesn't render and what throws errors at render time. Then you hunt down those errors and fix them until there aren't any more. I've done it more than a few times. On the plus side, changing to GLCORE gets you one step closer to being able to migrate to Vulkan/VSG (which lacks an FFP capability).

…

On Tue, Aug 4, 2026 at 7:30 AM Abbas Garousi ***@***.***> wrote: I'm looking into moving an OpenSceneGraph application from the compatibility profile build to core profile, and I'm trying to understand what that actually involves before committing to it. I've read the existing threads on building OSG with OPENGL_PROFILE=GLCORE, and I understand the headline point that core means no fixed function pipeline, so everything in the scene graph has to be shader based. What I can't judge from the outside is the rest of it. How do the two modes actually differ from OSG's side, beyond the build flags? What has to change in an application for it to work under core? Is this a realistic thing to attempt, or is it something you'd advise against? Roughly how much effort does it tend to be? If anyone here has been through this migration, I'd be interested in what took the most time and what you didn't see coming. Sample code or a project I can look at would be very welcome. Thanks. — Reply to this email directly, view it on GitHub <#1382?email_source=notifications&email_token=AAPFE3FHPKBACHCM4S6BEZL5IHQPDA5CNFSNUABBM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63RPGEYDKNJRGI4TBJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPFE3HYW43YKPSHE5R3TEL5IHQPDAVCNFSNUABFKJSXA33TNF2G64TZHM2TIMJRGA4TWRDJONRXK43TNFXW4OZRGA2TKMJSHEYKC5QC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dan-t]

Hi,

On Tue, Aug 04, 2026 at 12:51:55PM -0700, XenonofArcticus wrote: Mostly it's a matter of either hand-writing shaders or using a shadergen tool (OSG includes one, though it's not super full-featured) whenever geometry is added to the scenegraph or changed.

can you please explain why adding geometry is a problem for shadergen? About changing FFP calls into shaders, I wonder how to tackle it for a complex scenegraph with FFP calls at different levels of the scenegraph. Thanks for any hints! Greetings, Daniel

[XenonofArcticus]

Well, the Shadergen analyzes the geometry in the scenegraph, and writes, configures (uniforms) and installs a custom shader "above" that object in the scenegraph to implement the FFP capabilities utilized (materials, etc). If you later add FFP-using geometry, it will not have the shadergen and uniform process applied, you will need to remember to apply it when you add (or change) the new geometry. It's best if you then rewrite your geometry producing code (loaders or on-the-fly geometry builders) to just make shader-based geometry so you don't need shadergen. On Wed, Aug 5, 2026 at 2:21 AM Daniel Trstenjak ***@***.***> wrote:

…

Hi, On Tue, Aug 04, 2026 at 12:51:55PM -0700, XenonofArcticus wrote: > Mostly it's a matter of either hand-writing shaders or > using a shadergen tool (OSG includes one, though it's not super > full-featured) whenever geometry is added to the scenegraph or changed. can you please explain why adding geometry is a problem for shadergen? About changing FFP calls into shaders, I wonder how to tackle it for a complex scenegraph with FFP calls at different levels of the scenegraph. Thanks for any hints! Greetings, Daniel — Reply to this email directly, view it on GitHub <#1382?email_source=notifications&email_token=AAPFE3FMO3XLBOH2LPWSFVT5ILVARA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGAZTIOBSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17903482>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPFE3E7YPJYUHDBJAEJ7ND5ILVARAVCNFSNUABFKJSXA33TNF2G64TZHM2TIMJRGA4TWRDJONRXK43TNFXW4OZRGA2TKMJSHEYKC5QC> . You are receiving this because you commented.Message ID: <openscenegraph/OpenSceneGraph/repo-discussions/1382/comments/17903482@ github.com>