I have a Win32 app written in C++ that uses a lot of OpenGL code.
Right now we render all the GUI using OpenGL code, but I think using Unity3D as an interface layer would really simple things for us:
Is it possible to use our own c++ classes with OpenGL under a Unity3D app (in Windows?)
You should consider an alternative UI library that is capable of rendering directly to an OpenGL texture without imposing the burden of integrating with the entire Unity system.
I've played with QML, CEGUI, or libRocket.
QML is the most well designed of these three, although it's support for rendering directly to OpenGL textures is relatively recent, so there are some minor gotchas, but in general it's easy to use and the limitations can be worked around.
Related
As I mentioned in a question before, I am trying to make a simple game engine in C++ with OpenGL.
I am currently using GLFW for drawing the OpenGL context and I chose it because I heard it's one of the faster ones out there. However, it doesn't support widgets and I really don't want to write them myself. So I decided to get into Qt a bit, because it would allow me to have a pane for the render context and different handy bars as well as all the fancy elements for editing a world map, setting OpenGL rules, etc.
I want to use GLFW on the exported version of that game, though. Is that possible without an abstraction layer of some kind?
Thanks in advance! :)
Yes it is definitely possibile, infact I'm writing a 3D engine that is not coupled to any windowing library and can be used with Qt, SDL or whatever.
You of course have just to wrap regular GL calls into a higher level layer, this require you don't call "SwapBuffers" inside your GL code.
If by abstraction layer you mean "inversion of control" so, you don't want to override a "Render/Update" method that's exactly what I done. If by "abstraction layer" you mean you want to use GL directly than it is still possible.
Basically every windowing system have "some place" where you can make your GL calls (between MakeCurrent and SwapBuffers). Just read documentation of your windowing system.
I inspected the Qt GUI interfaces using window spy tools and I know that it does not use windows common controls or any custom window class to create its UI elements and animation effects. I asked before here about developing a custom GUI framework using GDI/GDI+ but most people responded against these technologies, so the question remains which graphics technology Qt or any other equivalent appropriator system uses to render their UI?
I am aware of DirectX/OpenGL but isn't it overkill for simple requirements? If the answer is going to be one of the above then again I wonder how one could implement robust font rendering and vector graphics solutions with these polygon rendering technology? the full featured text editor is another huge challenge.
Also there already exists solutions based on directx/opengl like MyGUI and CEGUI but I think they look ugly and nowhere near how Qt looks.
First things first, Qt-5 introduced a new rendering model, which can (but is not required to) use OpenGL for rendering the UI elements. The upshot of this is, that one can truly mix custom OpenGL rendering with Qt widgets. The downside is, that some kind of OpenGL support is required, which not all systems have.
So Qt also has these two other drawing systems: Native, which will use the hosts systems native graphics primitives (GDI, CoreGraphics, X11/XRender) and raster which does a complete rasterization of a whole window into pixel buffers, where then only those are blitted over to the underlying graphics system. raster is the slowest of the graphics backends, but it gives consistent results for all plattforms and target systems. Hence raster is usually used for programs where consistent appearance is strictly required.
I plan to embed an unmanaged C++ OpenGL viewer in WPF. The requirements are (apart from robustness and ease of development)
proper resizing
context menu for the OpenGL viewer area (only for viewer related actions)
events (e.g. triggered by selection of an object in the OpenGL viewer)
WPF dialogs should be drawn on top of the OpenGL space
So far I've found some blogs and discussions about using a hosted WinForm control (via C++/CLI wrapper), but it seems to be bit tricky (even a bit tinkery) to get all my above requirements done (if possible).
How about creating an ActiveX control? Despite having no experience with creating an ActiveX control, one advantage would already be that it runs in its own process.
Is it a good idea or would I run into even more tinkering?
EDIT: I should be clearer about the OpenGL viewer. It's an existing app based on an C++ 3D engine which only supports OpenGL. Porting to an DirectX capable engine is considered as last resort.
Although I didn't use ActiveX, I've accomplished what I believe you are trying to achieve. Two pieces of information helped me down this road.
Mixing Managed and Unmanaged code
It turns out, that managed C++ compiles completely differently than unmanaged C++, and data is stored on a completely different heap. Luckily you can mark sections of code as managed or unmanaged by using...
#pragma managed
#pragma unmanaged
See more info at this article
OpenGL context management
I followed a method similar to what's described in this article
wglMakeCurrent and wglShareLists will be your buddy if you need to manage multiple OpenGL windows
Good Luck!
Why you want an activex? There is some managed PInvoke based wrappers as SharpGL doing the job you need easyear.
But also, since you are using WPF and you have a Viewport3d object,why don't use it? If you are familiar with 3d engines you will appreciate the semplicity ( even if there is some drawback in term of speed).
Another point, since as per this question here I was forced to abandon WPF 3d rendering in favor of OpenGl due to the fact that Opengl can render in session 0, by using pure software mode. This is a requirement if you are planning to render something in off-screen bitmaps from a service or an asp.net application.
I have been using a few cross-platform GUI libraries (such as FLTK, wxWidgets, GTK++), however I feel like none fulfil my needs as I would like to create something that looks the same regardless of the platform (I understand that there will be people against building GUI's that don't have a native look on the platforms but that's not the issue here).
To build my controls, I usually rely on basic shapes provided by the library and make my way up binding & coding everything together...
So I decided to give it a try and do some opengl for 2D GUI programming (as it would still be cross-platform. With that in mind, I couldn't help to notice that the applications that I have written using wxWidgets & FLTK usually have a average RAM consume of 1/2MB, whereas a very basic openGL window with a simple background ranges from 6 to 9 MB.
This brings me to the actual question for this thread,
I thought that all the rendering of the screen was made using either opengl/direct (under the covers).
Could someone please explain or link me some sort of article that could give me some insight of how these things actually work?
Thanks for reading!
These multiplatform toolkits usually support quite a lot of backends which does the drawing. Even though some of the toolkits support OpenGL as their backend, the default is usually the "native" backend.
Take a look eg. at Qt. On Windows it uses GDI for drawing for its native backend. On linux it uses XRender I think. Same on Symbian and Mac. Qt also has its own software rasterizer. And of course there is an OpenGL backend.
So why the application using some of these GUI toolkits can take less memory than a simple OpenGL application? If the toolkit use the "native" backend, everything is already loaded in memory, because it is very likely that all visible GUI uses the same drawing API. The native APIs can also use only one buffer representing a whole screen in which all applications can draw.
However when using OpenGL you have your own buffer which represents the application window. Not to mention that an OpenGL application usually has several framebuffers, like z-buffer, stencil buffer, back buffer, which are not essential for 2D drawing, but they take some space (even though its probably the space in graphics card memory). Finally, when using OpenGL, it is possible that the necessary libraries are not yet loaded.
Your question is exceedingly vague, but it seems like you're asking about why your GL app takes up more memory than a basic GUI window.
It's because it's an OpenGL application. This means it has to store all of the machinery needed to make OpenGL work. It means it needs a hefty-sized framebuffer: back buffer, z-buffer, etc. It needs a lot of boilerplate to function.
Really, I wouldn't worry about it. It's something every application does.
I am looking for the ability to open OpenGL contexts and draw native OpenGL in windows, macOS, linux distros with X, android and iOS
I don't want to rely on the "native" device framework for the actual UI, I don't need to use native components, all I want is an OpenGL context to natively draw in OpenGL. Many of the cross platform SDKs like Marmalade and MoSync focus on making use of the native UI components and stuff like that, all I need is an OpenGl context to draw as I intend to, absolutely no native UI functionality is required, however, access to native hardware features like microphone, camera and other sensors is desired if possible, as well as access to audio/video/network.
I don't want to use QT, I want to do something that is closer to the hardware to work on the low level. The general idea is to make a lightweight cross platform hardware accelerated GUI, written on a level low enough to be truly hardware native, without relying on any native software framework. I know for android I may have to use a java wrapper to launch the native code, but the idea is to have this wrapper minimized, with very little modifications needed to deploy the low level and thus hopefully TRULY cross-platform code, that is only dependent on OpenGL hardware and OpenGL context for it to work wit.h
So I need a bare minimum solution to avoid using non-cross platform features as much as possible.
At the time the only library that comes to my mind is SDL, but I am not sure it supports android and iOS property, so besides library recommendations, more information on how SDL handles android and iOS devices and their hardware is welcomed too.
How about:
GLFW
SDL
GLUT (FreeGLUT or OpenGLUT)
Blender's GHOST framework?
Essentially they open a window, create a OpenGL context on it, deliver you the input events and leave the rest up to you.
What you want is nothing more than a platform-specific OpenGL context setup (which is quite simple and well documented: the NeHe OpenGL tutorial provides code for many environments that does just this here (the explanation is Windows specific, scroll down for the code on different OSes).
Once you have the OpenGL context, nothing prevents you from creating a full GUI with all OpenGL elements.
If you want, you could use Qt to only set up an OpenGL context (ie don't use any QWidgets or anything, other than the window showing you your OpenGL scene). It takes care of the whole setup process, but for only that, Qt becomes a huge dependency, as it only really replaces at most 100 lines of code per platform.
With regards to SDL+Android, have you checked the README?
And for iOS check the same file here.