These classes are supposed to store the original setting values,
so doubles are more appropriate as they won't slightly change
eg when round-tripping through qgis project XML.
(The actual 3d material classes still use floats, this is just
for the settings classes)
This introduces a new class QgsGeoTransform (derived from QTransform)
that keeps chunk's translation vector as a QgsVector3D (i.e. in double
coordinates) and if there is a shift of the origin, 3D map scene and
chunk entities react to it by adjusting the underlying QTransform.
The number of available clip planes depends on the OpenGL
implementation.
This change Introduces a new function in Qgs3DUtils function called
`Qgs3DUtils::getOpenGLMaxClipPlanes` to compute this
number (`GL_MAX_CLIP_PLANES`) and use it in the 3D scene.
See: https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glClipPlane.xml
This adds two functions to setup clip planes on a 3d scene:
- enableClipping() to enable opengl clipping
- disableClipping() to disable opengl clipping
The `enableClipping()` function achieves 3 things:
- it stores the clipping plane equations
- it adds clip planes to the framegraph
- it enables the clipping on the material of the existing entities
`disableClipping()` does the opposite things.
The clip planes equations need to be stored to handle the dynamic
addition of new entities. Indeed, when a new entity is added, clipping
needs to be enabled on its material if necessary. This is achieved
in `finalizeNewEntity` which is called on all new entities.
However, this is not true for the terrain entity. That's why,
`mTerrain` now listens to the `newEntityCreated` signal to call
`handleClippingOnEntity()`.
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.
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
