When the object info node was originally created, the transform of an
object with a negative scale would also have negative scale. At some
point that behavior changed though, and the matrix always had positive
scale.
The negative scale is the more expected behavior (see #104926), and
66dc0ebf2e restored that behavior. But node setups started to
rely on the non-negative behavior in the meantime. So this commit adds
an absolute value node with versioning.
The versioning is added to the 401.10 file subversion bump, since
that's when the behavior changed back to the current state.
Pull Request: https://projects.blender.org/blender/blender/pulls/117425
There are still node versioning bits running after linking, for example
`version_geometry_nodes_replace_transfer_attribute_node`. This code
relies on node types being untouched at that point.
Move the unknown node type replacement from `ntreeSetTypes` into the
`ntreeUpdateAllNew` function. This is called _after_ late versioning.
Pull Request: https://projects.blender.org/blender/blender/pulls/117441
When a shader performs a geometry shader injectoin to work around
features that are not supported natively on the GPU (viewport,
barycentric coordinates, layered rendering), linking would fail.
The reason was that the geometry shader was stored in a slot that was
patched by the specialization constants, resulting in an empty geometry
shader. An empty shader can be compiled, but doesn't match the interface
with other stages, so the linking would fail.
This fixes the issue that EEVEE crashed on Intel iGPUs. These GPUs
don't support viewports.
Pull Request: https://projects.blender.org/blender/blender/pulls/117440
The compositor Texture node differ between CPU and GPU. That's because
CPU falls back to the texture intensity as the alpha channel if no alpha
channel exists. And it also broadcast the texture intensity to all color
channels if no RGB evaluation exist. So adjust the GPU implementation to
follow that.
Rename: anim -> ImBufAnim
Rename: anim_index -> ImBufAnimIndex
There were cases where removing redundant "struct" qualifier caused
a warning since the name of the struct member was also anim.
Use uppercase type name to conform with other types names.
Ref !117394
This PR renames the UI names of EEVEE render engines, due to the decision to
postpone EEVEE-Next to Blender 4.2.
* `EEVEE` is now named `EEVEE-Next`.
* `EEVEE (Legacy)` is now named `EEVEE`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117437
This has been broken since 2.8.
The highlevel reason for this is that the "info file" (saved as frame
zero) was not written anymore.
Reason for that in turn is that when calling BKE_ptcache_write outside
the bake job, the PTCacheID calldata (a psys in our case) is not the
evaluated particle system, causing a check for totpoint to fail (these
were always zero).
Deeper reasoning is unclear, no further investigations were done as to
why/when this happened.
The solution proposed here is using the evaluated psys when writing the
info frame (and this is isolated to just this spot and only to particle
systems). File then gets
written and can/will be read when using this as an external disk cache
in another file.
Pull Request: https://projects.blender.org/blender/blender/pulls/117401
Caused by 089c389b5c. Previously the draw string was created
by appending text inside the buffer multiple times. Now it's formatted
in one step. Part of that change was missing for factor display.
The Tonemap node has a wrong luminance scale. This is because the
parallel reduction shader for logarithmic sum had a wrong identity
value. In particular, its identity was set to 0.0, but since its
initialization macro computed the log, the zero becomes a rather large
negative value.
To fix this, the general structure of the parallel reduction shader was
changed such that the identity is used as is, and not passed to the
INITIALIZE or LOAD macros. This simplifies the implementation and even
avoid the extra texel fetches at the boundary.
GreasePencil v3 requires some additional processing on its data before
writing to blendfile, and after reading from it.
Extract this from generic `read/write` code, and put it into dedicated
callbacks in Cpp classes that need it (layer groups and leaves
currently).
NOTE: Work done while exploring possibility to use 'memfile' read/write
code for GP editmode undo (!117072), but ended up taking a different
approach for it, so this PR is purely a 'no expected changes in behavior'
refactor at this point.
Pull Request: https://projects.blender.org/blender/blender/pulls/117413
This enables raw access to the property, which enables raw array access
to the property through ByteIntAttribute.data, speeding up Python API
access through foreach_get/foreach_set (bpy_rna.cc#foreach_getset).
Pull Request: https://projects.blender.org/blender/blender/pulls/117409
This PR improves the place when shader stages are attached to glPrograms.
Previously it was done when shaders stages where created, in the function
create_shader_stage.
This PR will attach the shader stages inside link program.
Ensuring that create_shader_stage doesn't alter the program, which isn't
clear in its name.
Pull Request: https://projects.blender.org/blender/blender/pulls/117407
`UUID` generally stands for "universally unique identifier". The session identifier that
we use is neither universally unique, nor does it follow the standard. Therefor, the term
"session uuid" is confusing and should be replaced.
In #116888 we briefly talked about a better name and ended up with "session uid".
The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender
already.
This patch changes all uses of "uuid" to "uid" where it's used in the context of a
"session uid". It's not always trivial to see whether a specific mention of "uuid" refers
to an actual uuid or something else. Therefore, I might have missed some renames.
I can't think of an automated way to differentiate the case.
BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`)
but there it also does not mean "session uid", so it's *not* changed by this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117350
Armature Edit mode has its own undo handling, which didn't store the
number of root bone collections in the armature. Now it does.
An alternative would be to not store this in the undo step, but rather
loop over all bone collections to find the minimum `child_index`. This
would be linear in the number of bone collections, though, so I chose to
use a few more bytes of memory to make the undo system a little faster.
The relations update code does tagging needed to ensure that the
array of bases is updated when relations are updated. It was done
by tagging the Scene ID node, and potentially recursing into all
dependent depsgraph nodes. If there is a driver on a scene property
it was unnecessarily re-evaluated.
This solves the slow behavior of adding objects in the test file
from #117335.
Pull Request: https://projects.blender.org/blender/blender/pulls/117403
Change parameters tagging from implicit based on the copy-on-write to
more explicit, allowing to ignore tagging of parameters component for
changes which do not affect drivers.
There is still implicit parameters tagging based on tags for geometry
or transform components to avoid making changes in too many places of
Blender.
Should be no functional changes, only expecting better performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/117336
The update callback of this property does proper tagging.
Should be no functional changes, but allows the depsgraph to make
more optimal decision on avoiding unneeded recalculations.
In practice this should avoid unnecessary re-evaluation when
toggling this option on objects on outliner.
Ref #117335
This node is needed to ensure evaluation order of scene and modifiers
which might access scene for custom data masks, or for the current
frame.
Move it to own component, so that evaluation of scene does not lead
to changes in the parameters component, hence does not trigger
driver evaluation.
Should be no functional changes.
Ref #117335
In the Bone Collection tree, mark bone collections that contain any
selected bones with a hollow dot.
As before, collections containing the active bone are still hown with a
filled dot.
Bone collections created via the `bpy.ops.armature.collection_new`
operator now always become the next sibling of the active bone
collection. If there is no active one, the new one is added at the end
of the list as root.
This removes the `.parent_index` property of the operator, as it is now
always created relative to the active bone collection.
- Group Extensions with Add-ons in preferences.
- No more official/community/testing, install and refresh.
- No more showing category on the headers
(there are no categories for extensions).
Changes proposed in #117285.
