Or you can fix the macdeployqt code and build it to replace your version. That way you benefit from all the file processing done during the deployment process.

Hi, I can't answer to that directly. Can you provide a minimal compilable example that shows that behaviour ?

opencv (extra characters to make response longer than 8 characters...lame!)

OK, Finally we found the solution. The tip is to create a Scene3D in the qml file. And to create the camera and ForwaqrdRenderer in the QML too (and not in the C++). Scene3D { id: scene3D anchors.fill: parent anchors.margins: 10 focus: true Root3DEntity { id : root3DEntity renderSettings : RenderSettings { id : renderSettings pickingSettings.pickMethod : pickingSettings.PrimitivePicking activeFrameGraph: ForwardRenderer { id: renderer clearColor: "#4d4d4f" camera: Camera { id: camera projectionType: CameraLens.PerspectiveProjection fieldOfView: 45 nearPlane: 0.1 farPlane: 1000.0 position: Qt.vector3d(0.0, 0.0, 2.0) upVector: Qt.vector3d(0.0, 1.0, 0.0) viewCenter: Qt.vector3d(0.0, 0.0, 0.0) } } } } }

Correction. I do not why. But my proposal no more works. But I found another way that seems to work. In fact the QDiffuseSpecularMaterial that we are supposed to use (other materials are deprecated), disable the depth buffer. So, this is a working code to force the enable (create a new effect does not work): Qt3DRender::QEffect *effect = material->effect(); if (effect) { for (Qt3DRender::QTechnique* currentTechnique : effect->techniques()) { for (Qt3DRender::QRenderPass * currentPass : currentTechnique->renderPasses()) { for (Qt3DRender::QRenderState * currentState : currentPass->renderStates()) { if (dynamic_cast<Qt3DRender::QNoDepthMask *>(currentState)) { currentPass->removeRenderState(currentState); Qt3DRender::QDepthTest* depthTest = new Qt3DRender::QDepthTest; depthTest ->setDepthFunction(Qt3DRender::QDepthTest::Less); currentPass->addRenderState(depthTest); break; } } } } } Warning: if you have fully transparent (alpha = 0) objects, the test fails. So the objects behind the invisible one are not displayed.

@Alain38-0 OK. Now I have found a way to always have a displayed text. For this, in the initial setText (when scene is not yet rendered) I'm putting all the characters that can appear in the strings that will be displayed. Then, I have something displayed. But it is often wrong. To be more explicit I'm doing this: void createScene() { ... myTextEntity->setText("?CLRT0123456789"); ... } void pageDisplayed() { ... myTextEntity->setText("???"); ... } void onButtonCLicked() { myTextEntity->setText("C23"); } setText("C23") displays another string of three characters (like "2R7"). But, at least strings have a coherency (all 'L' are replaced by '0', and so on).

@julianm You will have to set setSyncData(true); on the attribute-buffers and also synch the index buffers to get the right vertices.

Ok I found what is causing that - the torus is created facing Z. Thanks.

Great question, @GerryH! 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. But anyway, for a more reliable source, this recent email from a TQtC employee suggests that they are currently planning the direct-Metal route: https://lists.qt-project.org/pipermail/interest/2018-December/063503.html There should be a more formal announcement sometime this year. (Disclaimer: I, too, am a mere community member who lacks a crystal ball)

I found a solution. Please see my stackoverflow post.

I saw terrain rendering in this old video, but I couldn't find the code to it: https://www.youtube.com/watch?v=bYgSxoXgSU8 Maybe you have more luck.