in a project I want to render a lot of shapes with different colors.
I created the color of the shape with a QGLMaterial and add the shape to the QGLBuilder with this commands:
//Build SceneNode
m_lpBuilder->newSection();
...
m_lpBuilder->currentNode()->setMaterialIndex(idxMaterial); //idx in range of 0 to 1000
m_lpBuilder->currentNode()->setEffect(QGL::LitMaterial);
when I only have a few colors (QGLMaterial) the scene is rendered very fast but with a large kind of colors it is very slow.
is there a way to improve this?
I really recommend you use OpenGL directly. It will be much more obvious how much each operation costs you.
Here it's likely that Qt changes a Uniform and calls DrawArrays each time it renders with a different material, while the correct way to do this is to make the color a vertex attribute and put all your geometry into the same VAO. Perhaps it's possible to achieve with Qt, but I don't know how.
Related
If this was a texture that I created, I'd simply make its internalFormat be GL_SRGB. But I'm passing a Qt Quick Item foo into my custom QQuickFramebufferObject GL code, where I take foo->textureProvider()->texture() and use that texture to render.
So can I make the filtering of the texture (when bilinearly sampling it) be gamma-correct?
Note: I'm aware I could implement manual bilinear filtering with 4 texture taps and lerping, but that would hurt performance somewhat, so I'm looking for a better way.
Or I could blit from the Qt Quick texture into a GL_SRGB texture of my own, then use that texture, but that's more complex and would need to happen every time the source texture is updated, hurting performance (and RAM usage).
I've searched google for hooks Qt may provide to configure this, but found nothing except QQuickTextureFactory which, however, does not solve my problem, at least AFAICS.
I need to support OpenGL ES 2.0.
Note: I'm aware I could implement manual bilinear filtering with 4 texture taps and lerping, but that would hurt performance somewhat, so I'm looking for a better way.
Well, from the filtered result color, there is simply no way to get back the original colors used as input, even if you know the interpolation factors.
Or I could blit from the Qt Quick texture into a GL_SRGB texture of my own, then use that texture, but that's more complex and would need to happen every time the source texture is updated, hurting performance (and RAM usage).
A more efficient variation of this strategy would be creating a second view onto the texture data, with an SRGB format (see GL_ARB_texture_view extension, core since GL 4.3), which completely avoids the copy and additional RAM usage.
Is there a way to have a BABYLON.Sprite affected by lights just the way meshes are?
The Sprite API has access to the RGB values, so indirectly it can be done, but I'm not sure there is a better way to do this.
Hello if you want to get access to standard shades, the best way is then to use meshes with mesh.billboardMode = BABYLON.MESH.BILLBOARD_ALL
(http://doc.babylonjs.com/classes/2.3/AbstractMesh#billboardmode-number)
http://app.geokone.net/ is an open source javascript app for generating shapes (if you can look at it, it's really fast, for 5 seconds, I'm sure you'll get the idea).
It's hard for me to go through it because it's a lot of code, what is the general idea?
also, I need those shapes as GameObject with polygon collider around them (anything from 0 to 20 of them on the screen at the same time, could be different shapes also), is it even possible with GL?
would GL help me? I think GL would be fast for just 1 shape or something (as it's using recursion), but for what I want, I think drawing them in real time to a texture, then using the texture as a sprite would be faster (as I can save the sprite for shapes that are the same), or maybe I should use a shader? any other method that you can think of?
and for the algorithm itself, what is the general idea?
You don't want to use GL, look into custom mesh generation with MeshFilter. It is required for the colliders anyway.
Meshes have to be updated just once and probably will be faster than any optimisation you proposed. You might need a shader to draw it, though.
As for the algorithm, I'm afraid you have to look into it yourself or hire someone for it. StackOverflow is for helping with issues, not doing the work for you. If you need a hint, look into basic fractals
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.
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.