mirror of
https://github.com/qmlnet/qmlnet.git
synced 2026-05-16 14:15:57 -06:00
[GH-ISSUE #79] OpenGL? #52
Labels
No labels
bug
enhancement
help wanted
help wanted
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/qmlnet#52
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @define-private-public on GitHub (Nov 8, 2018).
Original GitHub issue: https://github.com/qmlnet/qmlnet/issues/79
This has been some very nice work so far on a Qt/QML binding for .NET Core.
I'm trying to get an OpenGL context rendering inside of a QML.Net app. I haven't seen anything in the examples, or by doing a search for
openglin this repo. I tried adapting the the tutorial here over to C#: http://doc.qt.io/qt-5/qtquick-scenegraph-openglunderqml-example.htmlBut I've had no luck since I can't find anything related to OpenGL in this repo. Do you have any plans to add in OpenGL support? Or is there something else I could do right now to use OpenGL in this library?
@pauldotknopf commented on GitHub (Nov 9, 2018):
Calling OpenGL directly from .NET isn't supported, but it is possible in the future.
Even if it was supported though, you should consider developing native QML components and just use them.
What are you looking to build?
@define-private-public commented on GitHub (Nov 12, 2018):
I'm looking to build an OpenGL application. I'm not looking to use it to do drawing for components. I've seen a few other OpenGL packages though already on NuGet though, so I wouldn't say it's unsupported.
@pauldotknopf commented on GitHub (Nov 12, 2018):
What kind of application? A game?
I'm not saying the calling OpenGL from .NET isn't supported, I'm saying it isn't currently supported in Qml.Net.
Also, when using Qt, your first consideration should always be to not use OpenGL directly. First, look into using QML to render your scene. If that isn't enough, look to using Qt's scene graph API to build a custom QML component. If that doesn't work, then yes, it is possible to build a pure OpenGL scene in Qt, but at that point, what would you be using Qt for?
@ncatlin commented on GitHub (Nov 16, 2018):
I'm also looking to do this, hoping to port a graph analysis tool to .NET Core. The graphs are animated and rendered in OpenGL but they are loaded and manipulated using Qt
It would be amazing if this is feasible using qmlnet
@pauldotknopf commented on GitHub (Nov 16, 2018):
@ncatlin Nice!
So, currently, your app doesn't use .NET at all? Can you get into a little more detail?
@ncatlin commented on GitHub (Nov 16, 2018):
No it's all C++ Qt, but I want to move it to C# .NET because
@pauldotknopf commented on GitHub (Nov 16, 2018):
Do you have some code I can look at? I'd like to look and see what effort would be required to do this.
@ncatlin commented on GitHub (Nov 16, 2018):
I'm not asking anyone to do it, just if there is a way to use an OpenGL context with Qml Net! The code is at https://github.com/ncatlin/rgat though the readme hasn't been updated with the Qt interface.
@pauldotknopf commented on GitHub (Dec 27, 2018):
We will eventually add support for using the platform-independent OpenGL API that Qt provides.
http://doc.qt.io/qt-5/qtopengl-module.html
@john-stone-ics commented on GitHub (Feb 27, 2019):
I'm confused about what the issue is here.
You can create your own OpenGL QML items by:
2.) Deriving from QQuickFramebufferObject
3.) Deriving from QQuickItem and and using custom QSGRenderNode objects (or other QSGNode objects)
All of these custom items would written in C++ then be registered with QML and available in your scene graph ... no .NET integration required.
I can't imagine any scenario where you'd want to actually write these derived item in .NET
@TheRamsWay commented on GitHub (Apr 15, 2019):
Maybe it could be done in the future with OpenGL.Net for OpenGL code written in .NET, and the SceneGraph as explained in Qt documentation?
@pauldotknopf commented on GitHub (Apr 15, 2019):
That looks interesting. I would like to have this supported, but I haven't really dig into the details.
How would you make sure that you are using the correctly OpenGL for the given OS and Qt build? I think I'd like to see the native
libQmlNet.soprovide handles to the exported C functions, to ensure we are using the correct OpenGL implementation.What do you think?
@TheRamsWay commented on GitHub (Apr 15, 2019):
According to the OpenGL.Net readme, it doesn't care about the platform and toolkit used, so I suppose that you would just connect the OpenGL rendering code in .Net to the Scene Graph. Being able to use QML signals could be the most important part (if it does work the way I think it works, but I may be wrong, these things are quite new to me)
@pauldotknopf commented on GitHub (Apr 15, 2019):
I've posed some questions to OpenGL.Net, let's see what they say.
@shartte commented on GitHub (Apr 13, 2020):
I am doing something like this, Win32 only and with some crazy hacks.....
I rely on Qt using ANGLE under the hood, and retrieve the D3D11Device that ANGLE uses as it's backend. Using deferred context's I then render my own engine's 3D scene on the same device and context as Qt is using into a RenderTarget.
I then use a custom QuickItem+QSGImageNode to render my render target within the QML scene with as little performance overhead as possible, updating it each frame in the QQuickWindow::beforeRendering signal.
If one doesn't want to use the device hack, it's generally possible to do something very similar with shared textures across D3D11 devices, and I don't really know what the overhead of that is. One still will have to rely on 1) ANGLE being used and 2) some hacks to get the EGLDevice and query the D3D11 device using ANGLE OpenGL Extensions.
The other direction (D3D11Texture2D -> ANGLE GLuint texture id) can be achieved by using another ANGLE OpenGL extension to set the underlying D3D11Texture of an eGL surface.
I have high hopes for Qt6 actually because it should finally remove the native OpenGL path from QtQuick and port everything to QRHI, which would remove the need for such nasty hacks and expose the D3D11 device directly. :-)
@Metadorius commented on GitHub (Jun 26, 2022):
What's the state of this? I assume we still can't do OpenGL rendering the similar way like written in Qt docs? https://doc.qt.io/qt-6/qtquick-scenegraph-openglunderqml-example.html