I'm writing an OpenGL game, and want native looking GUI elements. I was wondering if anyone has successfully hacked GTK+ using GtkOffscreenWindow and gtk_offscreen_window_get_pixbuf to render to an OpenGL texture, and whether this would have reasonable performance, considering repeated re-uploading of texture data every time the GUI is updated
While this is certainly possible, I'd instead use a real OpenGL widget toolkit like Clutter. If you want to render GTK+ with OpenGL, I'd start by creating a new GDK backend (X11/OpenGL or something like that), that (re-)implements all the GDK drawing functions using OpenGL. A nice side effect would be, that all GTK+ windows would allow for ordinary OpenGL rendering, too, i.e. no more need for a GtkGLWidget class.
Related
I'm currently developing a GameEngine API/framework so far I have an OpenGL 4.6 context where I load all the functions by myself (no OpenGL wrapper). The Engine is still under heavy construction, but some 3D stuff is already possible. Now the Engine was targeted to primarily draw 3D objects, but I'm also considering 2D stuff (though I haven't started yet to implement it).
Right now I'm creating kind of a user interface framework (which can be used instead of the 3D or 2D engine and likewise) "like" MFC, WinForms... you name it. For that, I'm using Windows's OpenGL 1.1 implementation, and that's where we get to my actual question.
Is using such an old OpenGL, or any legacy OpenGL version, considered as a bad practice? I know this question may be opinion-based, but especially in my case, I think it's the easiest way to create reusable controls; besides from that it's super interesting to create controls like a button all by myself, you have to think about everything. And I don't think Microsoft will remove it soon from their API if so, this would mean, we wouldn't be able to get an OpenGL context at all if I'm not completely wrong on that.
Additional information:
The way people/I should use the framework is, you would need to choose one of the types, the Engine can provide, such as 3D, 2D or creating a "normal" user-interface.
The reason I choose Windows's OpenGL implementation for the user-interface is, that it would also be possible to create a user-interface for Windows XP.
I currently use functions like glBegin(), glEnd(), glVertex2f() and glColor3f() to draw a button and wglUseFontBitmaps(), glPushAttrib(), glListBase(), glCallLists(), glPopAttrib() to draw the text.
Regarding the OpenGL context, I use Nehe's way to get a context:
http://nehe.gamedev.net/tutorial/creating_an_opengl_window_(win32)/13001/
So for the user-interface, I don't use the 4.6 context but 1.1
I want to write cross-platform 3D app (maybe game, who knows) with SFML and OpenGL 3.3 with the main purpose to learn C++.
SFML provides cool event model, handles textures, texts, inputs etc. I've done simple demo with cube (still in old glBegin/glEnd way, but I'll fix it when I'll find a way to attach OpenGL extensions).
The first problem which I got is a double bufferization. As you must know, usual (and logic) way to perform rendering uses two buffers, display buffer and render buffer. Rendering cycle performed on render buffer and when it ends, the result coping to display buffer (or maybe there's two same buffers just switching roles per cycle, don't know). That's prevents flickering and artifacts.
The trouble is that at any OpenGL example which I see authors using GLUT and functions like glutSwapBuffers. If I understand correct, double buffering is platform-specific (and that's strange for me, because I think it must be done on OpenGL part) and things like GLUT just hides platform-specific points. But I'm already using SFML for context and OpenGL initialization.
Is there any cross-platform way to deal with OpenGL double-buffering in pair with SFML? I'm not using SFML graphics in this project, but target is a RenderWindow.
SFML can handle double buffering, but if you are not using the SFML Graphics library you must use an sf::Window instance.
Double buffering is handled by calling sf::Window::setActive to set the window as the OpenGL rendering target, drawing content using OpenGL functions, and then calling sf::Window::display to swap the back buffer. More information can be found in the SFML API (linked version is v2.3.2).
I my collage i have to do a assignment in opengl and they intimidate us to do that in pure opengl. What it is just simply create and shown a transparent cube and put table inside it all of the model must create by the program they can't import by other modeling software like blender, 3dmax etc. And also they expect very high level lighting atmosphere in that cube. I am new to side and i heard that SDL is a game engine.
I wonder if i use SDL in my assignment may i end up with zero mark if it is not contain opengl? If there is good way to do this simple task please let me know!
Well, SDL is not a game engine and it is not pure OpenGL. However, you can build pure OpenGL applications using the windowing API that SDL gives you. SDL is just one of many options for window management and GL context creation.
SDL can set up a window for you, can set up the OpenGL context, and handle user input. From there, you can write pure OpenGL and render your cube or whatever. If you have not used OpenGL or SDL before, then you probably have a lot of work ahead of you.
As another difference, SDL does have an additional 2D rendering API. If your assignment is to do 3D with OpenGL, then obviously DO NOT use this 2D API.
What graphics engine Maya uses, OpenGL or DirectX? Does it at all use any? Since maya is written in C++.
For going deep into Maya, is it proper to learn to use OpenGL or one should go with DirectX?
My questions specially are associated with adding super new functionalities, such as new edge-system for a certain geometry in Maya.
What graphics engine Maya uses
Its own.
Neither OpenGL nor Direct3D are graphics engines. They're drawing APIs. You push in bunches of data and parameters and shaders to make sense of that data, and rasterized points, lines and triangles on a 2D framebuffer come out on the other side. That's it.
Maya, like every other graphics program out there implements its own engine or uses a graphics engine library that maybe uses Direct3D or OpenGL as a backend. In the case of Maya OpenGL is used for the interactive display. But the offline renderer is independent from that.
For going deep into Maya, is it proper to learn to use OpenGL or one should go with DirectX?
As long as you don't want to write lower-level-ish Maya plug-ins, you don't have to learn either.
My questions specially are associayted with adding super new functionalities, such as new edge-system for a certain geometry in Maya.
You surely want to make that available to the offline renderer as well. As such neiter OpenGL nor Direct3D are of use for you. You have to implement this using the graphics pipeline functions offered by Maya and its renderer. Note that you might also have to patch into external renderers if you want to use those with your news edge features.
I know GLUT's quadrics, I used it in a few programs when I was in school. Now I'm working on a real world application and I find myself in need of drawing some geometric primitives (cubes, spheres, cylinders), but now I also know that GLUT is a no longer supported and it's last update was in like 2005. So I'm wondering if there's anything other than GLUT's quadrics to draw such geometric shapes. I'm asking if there's anything made before I go ahead and start making my own from vertices arrays.
Yes, you can! You can use the native API of the OS to create a window with OpenGL capabilities.
The advantage of GLUT is that is makes this task easier and is a cross-platform solution.
There are other cross-platform libraries that are more complex to work with but provide the same functionality, like Qt.
NeHe has a huge amount of examples that use several different technologies to accomplish what you are looking for. Check the bottom of the page.
Here is a demo for Windows that creates a window and draws a simple OpenGL triangle inside it. This demo removes all the window frame to give the impression that a triangle is floating on the screen. And here is a similar demo for Linux.
GLUT is just some conveniece framework that came to life way after OpenGL. The problem is not, that GLUT is unmaintained. The problem is, that GLUT was not and never will be meant for serious applications.
Then there's also GLU providing some primitives, but just as GLUT it's merely a companion library. You don't need either.
The way OpenGL works is, that you deliver it arrays of vertex attributes (position, color, normal, texture coordinates, etc.) and tell to draw a set of primitives (points, lines, triangles) from those attributes from a second array of indices referencing into the vertex attribute arrays.
There used to be the immediate mode in versions prior to OpenGL-3 core, but that got depreceated – good riddance. It's only use was for populating display lists which used to have a slight performance advantage if one was using indirect GLX. With VBOs (server (=GPU) side vertex attribute storage) that's no longer an issue.
While GLUT has not been maintained, FreeGLUT has. There are still several alternatives though.
GLFW is a cross-platform windowing system which is easy to get up and running, and also provides the programmer with control of the main application loop.
SFML has support for many languages and also integration capabilities with other windowing schemes, in addition to being cross-platform.
Finally, Qt is another, popular, cross-platform windowing framework.
Now I'm working on a real world application and I find myself in need of drawing some geometric primitives (cubes, spheres, cylinders),
Actually, I don't remember anything except glut that would provide generic primitives. This might have something to do with the fact that those generic primitives are very easy to implement from scratch.
You can use other libraries (libsdl, for example, or Qt) to initialize OpenGL, though.
Most likely if you find generic library for loading meshes (or anything that provides "Mesh" object), then it will have primtives.
is a no longer supported and it's last update was in like 2005
Contrary to popular belief, code doesn't rot and it doesn't get worse with time. No matter how many years ago it was written, if it still works, you can use it.
Also there is FreeGLUT project. Last update: 2012.