My impression is that the automotive industry is one of biggest customers for the Qt Company (TQtC) at the moment. 3D graphics and Qt Quick are vital to the automotive IVIs, so TQtC and their partners (like KDAB, a major contributor to Qt 3D) will continue to pour lots of resources into them. In general, I believe that any effort you invest into Qt Quick and Qt 3D is quite safe for the next 5-10 years.
The path forward isn't easy -- Vulkan, Metal, and DirectX 12 support are all far far behind the level of OpenGL support, so it will be years before they catch up. Nonetheless, my gut feeling tells me that dropping support for Apple is unthinkable, so TQtC will adapt to Apple's demands. And given Apple's history of viciously dropping backwards compatibility, the sense of urgency is definitely there.
Some possible ways forward are:
Use MoltenGL to keep the OpenGL backend usable on Apple platforms (TQtC either forms a direct partnership with Molten, or Qt customers buy MoltenGL themselves), OR
Add abstraction layers to decouple Qt from OpenGL and add a Metal backend directly, OR
Like #2 but provide a Vulkan backend for Qt 3D and Qt Quick, and then use MoltenVK to support Apple platforms (like how OpenGL + ANGLE is currently used to support Windows)
Personally, I think #3 makes most sense because Vulkan support directly benefits Qt on all platforms, not just Apple platforms. However, I can't tell if this is a feasible business strategy for TQtC or not, or what kind of tradeoffs exist compared to a direct Metal backend.
Ok, solution 2 was simpler than i expected. I'll post my code below, in case someone else needs something similar. It flips a QEntity along the x-axis and the winding of the triangles. It only works with the primitive type QGeometryRenderer.Triangles.
void mirrorEntity(Qt3DCore::QEntity *entity)
for (QNode* node: entity->childNodes())
if (QEntity* e = dynamic_cast<QEntity*>(node))
if (QGeometryRenderer* r = dynamic_cast<QGeometryRenderer*>(node))
void mirrorGeometryRenderer(QGeometryRenderer *geometryRenderer)
QGeometry* geometry = geometryRenderer->geometry();
for (QAttribute* a : geometry->attributes())
if (a->name() == QAttribute::defaultPositionAttributeName())
QByteArray data = a->buffer()->data();
// flip along x-axis
float *bufferContent = reinterpret_cast<float*>(data.data());
int chunkSize = a->byteStride()/sizeof(float);
int positionOffset = a->byteOffset();
for (uint i=0; i<a->count()*chunkSize; i+=chunkSize)
int offsetI = i + positionOffset;
bufferContent[offsetI] = -bufferContent[offsetI]; // invert x
// change winding
const int size = a->byteStride();
char* tmp = new char[size];
for (int i=0; i<data.length(); i+=a->byteStride()*3)
memcpy(tmp, &data.data()[i+size], size);
memcpy(&data.data()[i+size], &data.data()[i+size*2], size);
memcpy(&data.data()[i+size*2], tmp, size);
@zespy , hello!
I've been trying to do exactly same thing - print text with QText2DEntity.
And, unfortunately, that code doesn't work for me. I've been variating all parameters for a while and haven't reach any result - just nothing appears on screene.
Is it possible to add any other example or\and example project?
And thank's you for this thread, it's still biggest conversation about QText2DEntity usage
What I'd suggest is you get the QGeometryRenderer from the text entity. The geometry renderer has a QGeomemtry attribute, which in turn has a set of QAttributes. There must be an attribute with a name like "vertexPosition". You need to get the QBuffer from the attribute and retrieve the vertices starting at position byteOffset (that is an attribute of QAttribute). The next vertexSize (also an attribute of QAttribute) entries should belong to the vertex position. Then continute at position byteOffset + i * byteStride, while i being the index you're reading right now. Do this for count (also an attribute) times. This way you can get all vertex positions and calculate a bounding box based on them.
Well, 5.7.0 was Qt3D's first official release, and the code hasn't matured as much as the other modules, so some bumps along the road are expected. My biggest beef with Qt3D actually is its very thin documentation, but I'm sure that'll improve with time.:)
You can write to the Qt Interest mailing list, see http://lists.qt-project.org/mailman/listinfo. There Sean Harmer himself may answer the one or other question about Qt3D if you don't talk badly about his baby right in your first mail.
I assume its possible to do this as you have access to the QBuffer data via the buffer() function. You will have to know the internal structure, of course, and adapt the QAttribute members (number of vertices etc.) accordingly afterwards, then maybe even call some update routine on the Qt3DWindow as there was some doubt lately about it being done automatically when the data buffers change.
On the other hand, I assume the functor in the cylindrical and other mesh examples runs in another thread (as e.g. I was not allowed to update GUI objects from within the functor), so you should ask yourself whether you really need the additional complexity to edit the buffers by yourself.
Did you realize your CAD-Project with QT3D?
Looking for information about QT3D I found your posting.
I have to realize a small 3D-CAD as part of a project.
First I wanted to do it with OpenCascade, but the support....
With the techniques used in QOrbitCameraController you cannot yet handle wheel events. This will be implemented in Qt 5.8 AFAIK.
If you want to have something now you will have to implement it the old fashoined way i.e. override the virtual function void Qt3DWindow::wheelEvent(QWheelEvent *ev) and there change the field of view of the camera().
What you see is the "default" light. AFAIK you can get no pointer to the default light to change its position, color, intensity or the like. If you want to have control you will have to add your own light to the root entity which then replaces the "default" light by some internal magic.