From the qt docs:
"The Gooch lighting model uses both color and brightness to help show the
curvature of 3D surfaces. This is often better than models such as Phong
that rely purely upon changes in brightness. In situations such as in CAD
and CAM applications where photorealism is not a goal, the Gooch shading
model in conjunction with some kind of silhouette edge inking is a popular
solution.
The Gooch lighting model is explained fully in the original Gooch paper.
The Gooch model mixes a diffuse object color with a user-provided cool
color and warm color to produce the end points of a color ramp that is
used to shade the object based upon the cosine of the angle between the
vector from the fragment to the light source and the fragment's normal
vector. Optionally, a specular highlight can be added on top. The
relative contributions to the cool and warm colors by the diffuse color
are controlled by the alpha and beta properties respecitvely."""
The TLDR: the shader works well for revealing 3d details of objects
which may otherwise be hidden due to the scene's lighting. Ultimately,
it's an easier material to work with as you don't need to worry
about setting up appropriate scene lighting in order to visualise features.
Restrict choice of material in widgets based on the symbol's required technique,
and hide material settings in phong widget which don't apply to certain
rendering techniques (e.g. hiding all but the ambient color for simple 3d line
symbols)
for specifying terrain layers to render
Previously the one method was used for both, which made it very
difficult to have a different set of layers used for terrain
generation vs 3d entity generation (you had to manually create a map
theme, which is very messy)
Even if the projection is assign, the QgsRasterLayer and the QgsRasterDataProvider was not updated.
The fix reloads the QgsRasterDataProvider's data and updates the QgsRasterLayer's crs.
Fixed#37920
not be available from the standalone qgis_process tool (e.g. "select by "
algorithms, which have no meaning outside of a GUI application)
These algorithms are hidden from the algorithm list for qgis_process
and cannot be run by the tool
(e.g. parameters) when they are run in the "edit in-place" mode
This allows algorithms to dynamically adapt their behavior to make them compatible
with in-place mode. Previously, some useful algorithms could not be
run in-place because they alter a layer's structure (e.g. adding new
fields).
Now, these algorithms have a means to detect that they are being
run in-place and change their input parameters accordingly. E.g.
an algorithm which usually adds new fields to store calculated
values (such as "add xy fields to layer") could instead expose
field parameter choices to ask the user to pick from existing
fields in which to store the calculated values, thereby avoiding
the need to change the table structure and making them eligable
for running in-place mode.
Note that this needs to be handled algorithm-by-algorithm, it's
not automatic! It's just the raw api to allow this...
update any open configuration panel to reflect the new format
(or dismiss it automatically if the new format is invalid)
Avoids UI going out of sync with text formats when a panel is already
open
This algorithm calculates the rotation required to align point features
with their nearest feature from another reference layer. A new field is
added to the output layer which is filled with the angle (in degrees,
clockwise) to the nearest reference feature.
Optionally, the output layer's symbology can be set to automatically
use the calculated rotation field to rotate marker symbols.
If desired, a maximum distance to use when aligning points can be set,
to avoid aligning isolated points to distant features.
Designed for use cases like aligning building point symbols to follow
the nearest road direction!
