I'm currently evaluating the possibilities to implement a navigable 3D scene which allows to render multiple 2D layers. To be a bit more precise, I would like to display multiple graphs in a 3D environment in order to pinpoint simularities and differences between those graphs. Considering the following screenshot, there would be two graphs (one black, one grey), which are equivalent - for different graphs, deviant nodes might, i.e, be highlighted in red.
I am working with Qt's Graphic View Framework and established an editable graph editor using QGraphicsScene and several QGraphicsItems, which I separately from this project.
Qt provides OpenGL support, e.g., the QGLWidget and I had a look at the provided examples. Given, that I have not worked with OpenGL (I did some work with Java3D though) I would love if some people can share their experience.
Several solutions came to my mind:
Render every QGraphicsView to a QPixmap and display them in 3D, which would make the graphs navigatable but would prohibit any picking of elements etc.
Create an equivalent 3D element for every 2D graph element and "transform" every QGraphicsView into an 3D representation. I guess this would be quite some work (espacially as I have not worked with OpenGL)
Maybe there is an easy way to "place" the QGraphicScenes, the view, or just the QGraphicsItems in a QGLWidget without many adaptions and still register the usual "mouseclickevents" etc.
For a first implementation a plain navigable "viewer" which displayes multiple graphs in different layers would sufficient. But I would like to keep it extendable in order to add, e.g., picking, in the future.
The Qt3D project provides a class called QGraphicsEmbedScene which does exactly what you are asking for.
Related
I want to build a scene graph to store and manage my scene layout which will be painted using QPainter (like QPicture, but the layout should be modifiable).
The scene graph will contain nodes for transformations, clipping and primitives. The first two will need to store the current state of the painter to restore it afterwards. It seems natural to use QPainter::save() and QPainter::restore() respectively.
I am a bit concerned about the efficiency of these two functions. Qt's documentation gives no information here. Looking at Qt's source code, it seems
QPainter::save() copies every element of the state, e.g. the pen, the brush, the transformation, the clipping path, and many many more. It seems to me that storing the former state of the one or two relevant properties that I actually need by myself is far more efficient. Has anyone any experience with this?
I'm trying to build a small application for a specific problem in cartography. The workflow is like this:
in the field, use a compass and tape measure to obtain terrain data.
also in the field, sketch the plot being surveyed
using inkscape, create a vector drawing of that sketch
crunch the data to obtain the relevant information (implemented already)
put the vector and the data together (mostly warping and scaling the drawing - implemented already)
Now, I'd like to do the vectorizing, which I'm doing in inkscape now, directly in my custom application - this helps me characterize the sketch faster.
I had a look at the Inkscape and Karbon codebases, but the code responsible for the widgets that draw curves and paths, along with the whole user interaction parts, is quite involved. I'd like to stick to number crunching and make sure that works properly.
In short, I'm looking for something like Qwt (whichs provides plotting utilities), but directed to adding vector drawing/sketching functionality to an application. Then it'd be a matter of putting the GUI pieces together, and i'd be free to worry about the number crunching. So far I couldn't find anything like this - Inkscape, Karbon, Libreoffice, Printdesign, Gimp, they all implement their own path, curve widgets, using the graphics primitives of their frameworks and adding all the code that shows the curve moving with the mouse, the control points, etc.
Does anyone have an idea if such a pre-made framework for higher-level graphics - that lets me forget about the GUI code - exists?
Thanks!
QGraphicsScene and QGraphicsView provide enough for you to fairly simply implement the rest of it. Do note that Qt has a rather rich set of graphics primitives that you can trivially reuse, like bezier curves, paths, etc. You need to implement the application-specific bits, but the basics are done.
I am in the process of coding a level design tool in Qt with OpenGL (for a relevant example see Valve's Hammer, as Source games are what I'm primarily designing this for) and have currently written a few classes to represent 3D objects (vertices, edges, faces). I plan to implement an "object" class which ties the three together, keeps track of its own vertices, etc.
After having read up on rendering polygons on http://open.gl, I have a couple of questions regarding the most efficient way to render the content. Bear in mind that this is a level editor, so I am anticipating needing to render a large number of objects with arbitrary shapes and numbers of vertices/faces.
Edit: Updated to be less broad.
At what point would be the best point to create the VBO? The Qt OpenGL example creates a VBO when a viewport is initialized, but I'd expect it to be inefficient to create a close for each viewport.
Regarding the submitted answer, would it be a sensible idea to create one VBO for geometry, another for mesh models, etc? What happens if/when a VBO overflows?
VBOs should be re-/initialized whenever there's a need for it. Consider VBOs as memory pools. So you'd not allocate one VBO per object, but group similar objects into a single VBO. When you run out of space in one VBO you allocate a another one.
Today's GPUs are optimized for rendering indexed triangles. So GL_TRIANGLES will suffice in 90% of all cases.
Frankly modern OpenGL implementations completely ignore the buffer object access mode. So many programs did made ill use of that parameter, that it became more efficient to profile the usage pattern and adjust driver behavior toward that. However it's still a good idea to use the right mode. And in your case it's GL_STATIC_DRAW.
I have to display a tiled map to display the result of a simulation
One can zoom/unzoom on the map, so if the zoom is far, there will be much more tiles displayed.
I am using QGraphicsPixmapItem to add the tiles to a QGraphicsScene.
I wonder whether openGl would be able to speed things up
I am using QGraphicsPixmapItem to add the tiles to a QGraphicsScene.
QGraphicsScene already uses methods like spatial subdivision (Kd trees) to determine which parts of a scene are visible and which not. In addition QGraphicsScene can use OpenGL as a rendering backend.
I strongly suggest you stick with QGraphicsScene, you'll hardly get more efficient than this, especially considering your next question:
I wonder whether openGl would be able to speed things up
Not if used naively. OpenGL is not a scene graph. I can't cull away and not issue drawing commands for geometry not visible. If you send it drawing commands it will process them. Unlike QGraphicsScene, which maintains scene data, OpenGL will carry out whatever drawing operation you ask it to do. Even if the final result may be invisible. Only in the very last processing steps (clipping, early fragment rejection) invisible fragments are discarded.
Currently I'm trying to develop some simple plot prototype and I'm struggling with some kind of white/empty sheet syndrome.
I'm back to Qt after 2 years, so I feel quite retarded.
My application should:
plot and manage custom layers of data
plot on custom canvas background
manage markers on plot
My plan is to use following design:
QGraphicsScene /View/Item as a sprite like management widgets for background, markers, pointers and other "bitmap" objects etc.
QPainter/ Qpixmap or QPicture for actual data layers - and if possible set them as QGraphicItem to simplify management of dynamic graphics
I don't want to use Qwt or similar library, unless I can plot with it on custom background (I don't like the look of the qwt's graphic style).
Is my plan proper in scope of qt class usage and composition?
I'd like to have at least clear overview of the classes which should be involved for this kind of prototype.
Thanks in advance.
P.
I think you have the basic idea with QGraphicsView. Here are a few resources which might help:
Graphics View
Diagram Scene
If you want to use the new animation and state set classes:
Stickman
Also, take a look at gunnar's labs blog. He recently did a series on graphics performance.
All of these are strictly Qt (animation and state set are in 4.6). They are in C++ but hopefully you can translate what you need to python.
You don't say much about your project for me to propose a more helpful answer, but have a look at the Qt demos involving the graphics view, especially diagram scene and 40000 chips. I think you will find them inspiring for what you want to do.
May be MathGL is appropriate for you. It have Qt widget or you can use RGBA image directly to combine it with any background in your widget.
I recommend you to use QCustomPlot which is a Qt C++ library. It focuses on making good looking, publication quality 2D plots, graphs and charts and also has high performance for realtime visualization applications. You get it here: http://www.qcustomplot.com/
You may want to take a look at the Core Plot framework. Core Plot is OS X specific, but it is built on the the OS X Core Animation system which has a lot of conceptual similarity to the Qt Graphics View Framework. You'll have to learn to visually parse the Objective-C (a less-than-two day process for any competent C++ developer), but you should be able to see the general architecture relatively easily. The Core Plot wiki has some nice high-level documentation that might set you on your way without even needing to look at the code.