You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Find if accepting external OpenGL context is viable #66
There are two possible approaches regarding this topic:
Find if user created OpenGL context can be used with Forge(glfw/sdl) windows. As of now, some internal state (loading default fonts, color maps etc.) is initialized during window object construction (Window constructor code). The logic in this initialization should be exposed via functions appropriately if external context usage is to be given as an option to the user.
Other approach would be to abstract renderable objects such as Image, Chart etc. to be able to render them on user provided OpenGL Window, where forge's window class is not used at all. In this case, just the Image/Chart objects are rendered to which ever viewport is active. The user has to do multiple views in single window by themselves.
I have a few questions here. I quickly hacked together an Qt5 window for forge that seems to work, caseymcc@a78f290
But as far as I could tell from the quick overview it to implement this. forge really doesn't care about the window as long as you don't call the window functions. Seems if you created a Chart and just called render making sure the current openGL context is properly setup it would draw.
Ill add a PR later for the Qt5 window (likely need a little info in the manner of how multiple windows are supposed the be handled), need to split it with the hunter functionality (cmake package manager) that I used.
@caseymcc That is true - forge rendering user's can use their own windowing functionality - that was the intention behind the such design. As you said, the user has to take care of GL context. What do you need to know about multiple windows ?
Is it intended that the user can open multiple windows? If so in the the case of Qt5 I could make them dockable, dialogs or or split in the same window.
@beojan Unfortunately, no, there has been much work done in this direction yet.
Currently, fonts are currently set via window object. Thus this needs to be separated from Window so that the they will work out of the box. So basically, except font rendering rest of the stuff should work fine in a user provided OpenGL context even now.
Because fonts won't work, chart won't make sense. Image object's should render fine though.
@beojan A quick update. I have looked at the code and as of today font object used by Window object is separate from the font object's created for chart's internal use. Thus, even if Window class from forge isn't used, one should be able to still use rendering logic from other classes in a different OpenGL context.
Note that, a valid OpenGL context should be available to use forge's non-Window classes in that fashion. Hope this helps for your use case.
Ah right, my bad. Window is being passed, although it can easily worked around since the object is only used to get unique window ID that is in turn used for internal book keeping of VAO objects.
If this object of Windows is replaced with a window identifier variable like int, then it should work out of the box. Unfortunately, that would require an API change and can't be done before 2.0 release.
Activity
9prady9 commentedon Sep 1, 2016
There are two possible approaches regarding this topic:
caseymcc commentedon Apr 28, 2017
I have a few questions here. I quickly hacked together an Qt5 window for forge that seems to work,
caseymcc@a78f290
But as far as I could tell from the quick overview it to implement this. forge really doesn't care about the window as long as you don't call the window functions. Seems if you created a Chart and just called render making sure the current openGL context is properly setup it would draw.
Ill add a PR later for the Qt5 window (likely need a little info in the manner of how multiple windows are supposed the be handled), need to split it with the hunter functionality (cmake package manager) that I used.
9prady9 commentedon Apr 29, 2017
@caseymcc That is true - forge rendering user's can use their own windowing functionality - that was the intention behind the such design. As you said, the user has to take care of GL context. What do you need to know about multiple windows ?
caseymcc commentedon Apr 29, 2017
Is it intended that the user can open multiple windows? If so in the the case of Qt5 I could make them dockable, dialogs or or split in the same window.
9prady9 commentedon Apr 29, 2017
Yes,we wanted to enable multi-window usage. However, this hasn't been tested extensively. You are welcome to try and report any bugs you may find!
beojan commentedon Jun 20, 2020
Any updates here? Is it still possible to just draw into the current context without setting up a window?
9prady9 commentedon Jun 20, 2020
@beojan Unfortunately, no, there has been much work done in this direction yet.
Currently, fonts are currently set via window object. Thus this needs to be separated from Window so that the they will work out of the box. So basically, except font rendering rest of the stuff should work fine in a user provided OpenGL context even now.
Because fonts won't work, chart won't make sense. Image object's should render fine though.
9prady9 commentedon Jul 8, 2020
@beojan A quick update. I have looked at the code and as of today
fontobject used by Window object is separate from the font object's created for chart's internal use. Thus, even if Window class from forge isn't used, one should be able to still use rendering logic from other classes in a different OpenGL context.Note that, a valid OpenGL context should be available to use forge's non-Window classes in that fashion. Hope this helps for your use case.
beojan commentedon Jul 8, 2020
It appears
Chart'srendermember function still requires a reference to a Window. Is there a dummy Window to be passed?9prady9 commentedon Jul 8, 2020
Ah right, my bad. Window is being passed, although it can easily worked around since the object is only used to get unique window ID that is in turn used for internal book keeping of VAO objects.
If this object of Windows is replaced with a window identifier variable like int, then it should work out of the box. Unfortunately, that would require an API change and can't be done before 2.0 release.