The module patching for _3d was not working at all, because
the same logic which works for other modules with a private _module
copy clashed with the approach of exposing the public 3d module
as qgis._3d
Work around this by renaming the private internal module as _3d_p,
so that the monkey patching logic from sip is correctly run
when the module is loaded.
Fixes broken API in 3d module for renamed enums, and fixes the
broken PyQGIS doc for the 3d module
Create a small, cheap to copy (non-qobject) class
Qgs3DMapSettingsSnapshot which is designed to store
just cheap properties of Qgs3DMapSettings. Then use this
object wherever possible to avoid accessing the (non-thread
safe) Qgs3DMapSettings object for retrieval of simple
map properties (eg crs, extent, ...)
Refs https://github.com/qgis/QGIS-Enhancement-Proposals/issues/301
* terrain: Use PhongMaterialSettings material for the non texture case
There is no functional change. With this change, the terrain uses a
material defined by QGIS instead of a default Qt3D. This will make it
easier to customize the shader in the future.
* qgsphongmaterialsettings: Fix setShininess signature
`mShininess` is a double.
* qgsphongtexturedmaterialsettings: Use a double to store shininess
This is already waht QgsPhongTexturedMaterialSettings does. The reason
for this change is to avoid the user-set values changing for them when
saving/restoring projects.
* qgsphongtexturedmaterialsettings: Use a double to store opacity
This is already waht QgsPhongTexturedMaterialSettings does. The reason
for this change is to avoid the user-set values changing for them when
saving/restoring projects.
* qgsphongtexturedmaterialsettings: Do proper opacity cast in toMaterial
* qgsphongtexturedmaterialsettings: Factor out material creation
This introduces a new class `QgsPhongTexturedMaterial` which is
similar to Qt3D `QDiffuseSpecularMaterial`.
`QgsPhongTexturedMaterial::toMaterial()` now calls
`QgsPhongTexturedMaterial` to create the material. This has no
functional change.
This will make it possible to directly use `QgsPhongTexturedMaterial`
for the terrain in the next commit. Indeed, the texture case needs to
use a `QTexture2D` which cannot be stored in a settings class. This
issue is avoided by directly creating the material instead of using
`QgsPhongTexturedMaterial::toMaterial()`.
* qgsterraintileloader: Fix typo
* terrain: Use QgsPhongTexturedMaterial for shading texture
There is no functional change. With this change, the terrain uses a
material defined by QGIS instead of a default Qt3D. This will make it
easier to customize the shader in the future.
* 3d/material: Introduce QgsTextureMaterial
This is the same material as the qt3d one:
`Qt3DExtras::QTextureMaterial`. It will also be used in the following
commit by the terrain.
* terrain: Use QgsTextureMaterial for non shading texture
There is no functional change. With this change, the terrain uses a
material defined by QGIS instead of a default Qt3D. This will make it
easier to customize the shader in the future.
sip doesn't use the standard Python staticmethod type for defining
static methods, which means that standard means of testing
for a static method (like `isinstance(..., staticmethod)`) fail
with any PyQGIS static methods.
This causes issues with lint tools, which incorrectly flag
calls to QGIS static methods as missing self arguments. It also
breaks detection of static methods in the sphinx PyQGIS docs,
so all static methods are shown as non-static.
Work around this in sipify, by wrapping unambiguously static
methods in staticmethod wrappers.
* create map file for class / header files for PyQGIS API docs
* create map files
* install file
* add line numbers
* also add methods
* wait to sort
* more methods
* fix CMakeLists install
* fix sorting
* fix spell check
* remove map files for Qt6
* Revert "remove map files for Qt6"
This reverts commit 972f483410f556d1735a2070943b8ad9e2522c5e.
* do not test class_map files + auto sipify_all on branches
* fix warning
The 3D scene's CRS is not necessarily the same as the project's
CRS. For example, it can be "EPSG:3857" if the project's CRS is
geographic.
The stored extent in the settings is always the 3D scene's extent.
See:
b0d1a4f8b1
Adds a new material choice for a physically based metal/roughness
material. Options are available for setting the material base color,
metalness and roughness.
Internally this uses a clone of Qt's QMetalRoughMaterial class. We
use a copy of the Qt class instead of relying on Qt's implementation
as longer-term improvements (such as data defined base color) will
require a re-implementation anyway. By using our own material we
will avoid having two different code paths for the data-defined/
non-data defined scenarios.
stored in a single place, and that we always use the default
value when its not overwise set
This has two benefits:
1. The user doesn't see confusing "0" values for radius/length etc,
which are silently treated as some other fixed value when rendering
2. The default values are correctly accounted for when calculating
the layer's AABB, otherwise we end up with a flat AABB by
default
The `height` property is in fact a vertical offset applied to the
line. Also, the `offset` phrase is already used by the terrain for
similar purposes.
height() are setHeight() are kept for API compatibility reasons.
