Details
-
Bug
-
Resolution: Done
-
P2: Important
-
6.0
-
None
-
7269ac7c02c6178c83e3468adddb5ee0aedcbdf6 (qt/qtquick3d/dev) d76240bc5483ce1f4a53b6579833b4c81e70311e (qt/qtquick3d/6.0) 1fafbc5e250be2db0f919157a709110e83ea85f5 (qt/qtquick3d/6.1)
-
Qt Quick 3D - 2021 - Weeks 7/8, Qt Quick 3D - 2021 Week 9 - 10
Description
In QQuick3DTexture::updateSpatialNode() we have this block:
m_textureProviderConnection = connect(provider, &QSGTextureProvider::textureChanged, this, [provider, imageNode] () {
// called on the render thread, if there is one; while not
// obvious, the gui thread is blocked too because one can
// get here only from either the textureProvider() call
// above, or from QQuickImage::updatePaintNode()
imageNode->m_qsgTexture = provider->texture();
// the QSGTexture may be different now, go through loadRenderImage() again
imageNode->m_flags.setFlag(QSSGRenderImage::Flag::Dirty);
}, Qt::DirectConnection);
Something is wrong about this, at least when the texture provider is a View3D. The following snippet will not lead to live rendering in the second View3D. Rather, it only updates when something else triggers an update.
View3D {
id: lightmapSource
renderMode: View3D.Offscreen // so a texture provider as well
...
}
...
View3D {
...
Model {
...
materials: DefaultMaterial {
lighting: DefaultMaterial.NoLighting
diffuseMap: Texture {
sourceItem: lightmapSource
indexUV: 1
}
}
}
}
The problem should not affect texture providers where the provided texture is an QSGDynamicTexture (this includes layers). An Image or a View3D are however not like that, there is no explicit updateTexture() step for those. So those still need to trigger proper updating upon textureChanged().