1. 07 Aug, 2022 2 commits
    • Andy Nichols's avatar
      Don't try and execute a draw call with an instance count of 0 · 64d135bc
      Andy Nichols authored
      It is invalid to call a draw call with an instance count of 0 with metal
      and this can lead to a validation error. Better to bail out as soon as
      we know the instance count will be 0.
      Pick-to: 6.4
      Change-Id: I16fdc17ebb1d75624f04cd680bf9e4df9e27729d
      Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@qt.io>
    • Andy Nichols's avatar
      Fix some unused variable warnings when using Metal · 5317f6c5
      Andy Nichols authored
      We were being pretty careless about creating shader variables just
      assuming that the shader compilers would optimize away things that were
      unused, so more conditionals have been added to only add local variables
      when needed when generating shaders at runtime. In the case of binormal
      and tangents this lead to the uncessary generation due to an overly
      broad conditional (all specular rendering).
      Change-Id: Id97726a7321040e70cdde7dfd92655ab784e0356
      Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@qt.io>
  2. 05 Aug, 2022 1 commit
  3. 04 Aug, 2022 3 commits
  4. 03 Aug, 2022 5 commits
  5. 01 Aug, 2022 7 commits
    • Laszlo Agocs's avatar
      embree: Apply a C++20 build patch · 62fb6131
      Laszlo Agocs authored
      Pick-to: 6.4
      Fixes: QTBUG-105131
      Change-Id: I1264cfccf1165ddc7a9177830376fb37176ece35
      Reviewed-by: default avatarAndy Nichols <andy.nichols@qt.io>
    • Alexey Edelev's avatar
      Add the missing header files to a CMake source tree · b8c8e214
      Alexey Edelev authored
      Task-number: QTBUG-103196
      Change-Id: Iaa6cf8167c8ca7745ebf99e067b0fe117c25f674
      Reviewed-by: default avatarAlexandru Croitor <alexandru.croitor@qt.io>
    • Laszlo Agocs's avatar
      Tonemap the clear color · afa61e9b
      Laszlo Agocs authored
      The color needs to go through sRGB->linear like all other colors.
      Then based on the tonemapMode it needs to be converted as we would do
      for a fragment color in the material or skybox shaders.
      With the default tonemap mode Linear this brings no visible change,
      whereas the other tonemap modes will now have a proper effect on the
      clear color (even None, because now we treat the color as sRGB like
      with all other color properties, meaning no tonemapping implies
      passing in a linearized value to the 3D API).
      This also means that post-processing effects, when they perform the
      built-in tonemapping in the last effect, will now output an image
      where the background looks as expected, i.e. not different from when
      there is no effect, because all code paths perform tonemapping
      correctly now.
      Fixes: QTBUG-104885
      Task-number: QTBUG-104759
      Change-Id: Ia2bba81dbaecb09c1836314e9861ba619ae36b37
      Reviewed-by: default avatarAndy Nichols <andy.nichols@qt.io>
      Reviewed-by: default avatarQt CI Bot <qt_ci_bot@qt-project.org>
    • Laszlo Agocs's avatar
      Enable proper tonemapping for effects · 8211cfc1
      Laszlo Agocs authored
      On its own this patch is sufficient to get proper results with a
      single effect in the environment's effect list, or with multiple ones
      in case the effect list is static enough. However, dynamically altered
      effect lists need more dynamic behavior, as all effects need to be
      able to reevaluate certain things then (like what is now the last
      effect when it comes to tonemapping, and perhaps update the shaders),
      but effects miss this completely: they do not even react when the
      shader source properties change and lack any sort of dirty mechanism
      for non-user properties. Therefore, this is going to be fixed in
      separate patches only.
      The last effect's last pass will now perform automatically the same
      tonemapping as the main render pass would, depending on the
      SceneEnvironment's tonemapMode. If it is TonemapModeNone, there is no
      visual change in the result.
      There is another problem to be fixed separately: consider a scene with
      a given background clear color. The main pass's tonemapping does not
      tonemap the background (as the color just gets passed to the QRhi as
      the render pass's clear color; there is no srgb->linear conversion
      either which all works if the tonemap mode is the default Linear but
      incorrect if the mode is anything else). When run through an effect,
      that can only operate on a texture with all the content, background
      included, so now it will tonemap the background pixels too.
      A skybox should work as expected however, because there we can apply
      the same logic as in the main pass, i.e. use the non-tonemapped skybox
      shaders when there is an effect present, so no problem there.
      So the case of the Color background mode has to be fixed separately,
      otherwise the output from an effect will lead to a background color
      different from what's shown when there are no effects in the scene.
      Task-number: QTBUG-104759
      Change-Id: Icd2ea78c659cd0ba3dbbc0a2fe10db3db64b1841
      Reviewed-by: default avatarAndy Nichols <andy.nichols@qt.io>
      Reviewed-by: default avatarQt CI Bot <qt_ci_bot@qt-project.org>
    • Laszlo Agocs's avatar
      Destroy the postproc effect command list · 1d8b40ca
      Laszlo Agocs authored
      Won't matter much for now because backend objects (QSSGRenderEffect)
      are not destroyed either (and that's a slightly bigger problem), but
      if they were they would now free the command objects as expected.
      Task-number: QTBUG-104759
      Change-Id: I506683bc46399bcf50a10557507425d8869552da
      Reviewed-by: default avatarAndy Nichols <andy.nichols@qt.io>
      Reviewed-by: default avatarQt CI Bot <qt_ci_bot@qt-project.org>
    • Laszlo Agocs's avatar
      Split effect shader prep into two · 2ba605f7
      Laszlo Agocs authored
      This does not change the visible behavior yet in any way. It allows
      taking layer (SceneEnvironment) settings into account, the prime
      example of which is going to be the tonemapping mode. To enable this,
      some of the work that was previously performed in
      QQuick3DEffect::updateSpatialNode() is moved to the backend object and
      triggered only in QQuick3DSceneRenderer::updateLayerNode() after the
      SceneEnvironment settings are synced and the postprocessing effect list
      the renderer is going to use is finalized. The latter allows
      implementing logic where something is done only in the first or the last
      effect in the chain.
      Task-number: QTBUG-104759
      Change-Id: I63eb5ac62907eb5e0c07f417709aed2f683d47b8
      Reviewed-by: default avatarAndy Nichols <andy.nichols@qt.io>
      Reviewed-by: default avatarQt CI Bot <qt_ci_bot@qt-project.org>
    • Hatem ElKharashy's avatar
      Fix HeightFieldGeometry failing to open a file · 193d433e
      Hatem ElKharashy authored
      Depending on the order of properties, It will fail
      to update the geometry data because of an empty
      source file
      Pick-to: 6.4
      Change-Id: I4b51ab1700342fe69107021932d5ab5381b25a71
      Reviewed-by: default avatarAndy Nichols <andy.nichols@qt.io>
  6. 28 Jul, 2022 1 commit
  7. 27 Jul, 2022 1 commit
  8. 25 Jul, 2022 1 commit
  9. 21 Jul, 2022 3 commits
  10. 17 Jul, 2022 1 commit
  11. 15 Jul, 2022 2 commits
  12. 13 Jul, 2022 1 commit
  13. 12 Jul, 2022 3 commits
    • Christian Strømme's avatar
      Improve updatePropertyListener · b5306e18
      Christian Strømme authored
      Conceptually the code is doing the exact same thing as before, but with
      some fundamental differences:
      - The scene manager is not exposed.
      - The watcher is mapped to the setter function of the property that takes
      the external object instead of a string.
      - Connections are automatically broken once the context object is destroyed.
      - The QQuick3DObject now has a detachWatcher() signal, as we shouldn't be
      using the QObject::destroyed signal since that's trigger when the
      QQuick3DObject's dtor is already called.
      Change-Id: I4198ba200249d9c075ba4abede0a14b9c6c728af
      Reviewed-by: default avatarQt CI Bot <qt_ci_bot@qt-project.org>
      Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@qt.io>
    • Paul Olav Tvete's avatar
      Keep camera position when switching to orbit controller · a8751298
      Paul Olav Tvete authored
      Calculate angles and distance so that the orbit camera ends up in
      exactly the same position as the WASD camera, but pointing towards the
      centre of the imported model.
      Pick-to: 6.4
      Change-Id: I52b602b781f266f3f6c5cb0daee00a3012ad4afd
      Reviewed-by: default avatarKristoffer Skau <kristoffer.skau@qt.io>
      Reviewed-by: default avatarJonas Karlsson <jonas.karlsson@qt.io>
    • Paul Olav Tvete's avatar
      Use separate cameras for WASD and orbit · ecb16580
      Paul Olav Tvete authored
      WasdController does not work properly when the parent is rotated. In
      addition, OrbitController changes the clip planes of the camera.
      Use the new freedom to make the WASD camera start out with exactly the
      same view as the orbit camera. Switching back is still a full reset,
      Pick-to: 6.4
      Change-Id: I05b32a7cb10bcb0b83588e8153239a95a6a0f2e8
      Reviewed-by: default avatarJonas Karlsson <jonas.karlsson@qt.io>
  14. 10 Jul, 2022 2 commits
    • Christian Strømme's avatar
      Calculate the distance from the camera when adding renderables · 6e63c58d
      Christian Strømme authored
      In retrospect it was a mistake to make the distance property optional
      when creating the sorting data, as we in practice left that as a
      separate step instead of calculating directly when inserting, which
      meant iterating over the item an extra time and modifying its content
      in the process. This is now avoided. In addition we pass the camera
      data (distance and position) to all the prep function to avoid querying
      for every renderable.
      Change-Id: I72417c886a5914a912b5f6cf29d55b537dcd342c
      Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@qt.io>
    • Christian Strømme's avatar
      Fix type checks introduced in the priority change · 969d7cbd
      Christian Strømme authored
      This amends 55e10112
       which contains the wrong type checks when
      going over the nodes and resources. The logic should be that all nodes
      are identified as a node type (verified when object is created), all
      other objects are assumed to be some for of resource, even if they
      don't have a proper type set (Unknown type), which is why we cannot
      have the assert based on the type being a resource or not.
      Change-Id: I84ca9ecc5233363b2f6103faa60295818bbf5078
      Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@qt.io>
  15. 07 Jul, 2022 5 commits
  16. 06 Jul, 2022 2 commits