- Add IDP_EnsureProperties,
- Remove create_if_needed argument from IDP_GetProperties.
Split access & creation so intention reads more clearly without
looking up function arguments.
Calling an API function after the node panels patch does not internally
tag the node tree with `NTREE_CHANGED_INTERFACE` any more, because the
node tree is not directly accessible from `bNodeTreeInterface`. Before
node panels the API functions for interfaces could tag the tree directly
for later update consideration, which now requires explicit tagging
calls.
The fix is to add a flag and mutex directly to `bNodeTreeInterface`, so
API methods can tag after updates. This mostly copies runtime data
concepts from `bNodeTree`. The `ensure_interface_cache` method is
equivalent to `ensure_topology_cache` and should be called before
accessing `interface_inputs` and similar cache data.
Pull Request: https://projects.blender.org/blender/blender/pulls/111741
- Changes defaults from Emission Color 0.0, Emission Strength 1.0 to be the
other way around (Color 1.0, Strength 0.0), suggested by @brecht
- Makes emission component occluded by sheen and coat
(to simulate e.g. dust-covered light sources)
- Moves transparency into the Principled SVM/OSL node, to allow for future
support for e.g. transparent shadows in thin sheet mode.
Note that there are optimization opportunities here (mostly skipping the
non-transparent components for transparent shadow evaluation, and skipping
the parts that don't affect emission for light evaluation), but I have a
separate point for those in the Principled V2 planning since there's some
other optimization topics as well.
Co-authored-by: Weizhen Huang <weizhen@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/111155
Previously, the Principled BSDF used the Subsurface input to scale the radius.
When it was zero, it used a diffuse closure, otherwise a subsurface closure.
This sort of scaling input makes sense, but it should be specified in distance
units, rather than a 0..1 factor, so this commit changes the unit and renames
the input to Subsurface Scale.
Additionally, it adds support for mixing diffuse and subsurface components.
This is part of e.g. the OpenPBR spec, and the logic behind it is to support
modeling e.g. dirt or paint on top of skin. Before, materials would be either
fully diffuse (radius=0) or fully subsurface.
For typical materials, this mixing factor will be either zero or one
(just like metallic or transmission), but supporting fractional inputs makes
sense for e.g. smooth transitions at boundaries.
Another change is that there is no separate Subsurface Color anymore - before,
this was mixed with the Base Color using the Subsurface input as the factor,
but this was not really useful since that input was generally very small.
And finally, the handling of how the path enters the material for random walk
subsurface scattering is changed. Before, this always used lambertian (diffuse)
transmission, but this caused some problems, like overly white edges.
Instead, two different methods are now used, depending on the selected mode.
In Fixed Radius mode, the code assumes a simple medium boundary, and performs
refraction into the material using the main Roughness and IOR inputs.
Meanwhile, when not using Fixed Radius, the code assumes a more complex
boundary (as typically found on organic materials, e.g. skin), so the entry
bounce has a 50/50 chance of being either diffuse transmission or refraction
using the separate Subsurface IOR input and a fixed roughness of 1.
Credit for this method goes to Christophe Hery.
Pull Request: https://projects.blender.org/blender/blender/pulls/110989
- Adds tint control, which simulates volumetric absorption inside the coating.
This results in angle-dependent saturation and affects all underlying layers
(diffuse, subsurface, metallic, transmission). It provides a physically-based
alternative to ad-hoc effects such as tinted specular highlights.
- Renames the component from "Clearcoat" to "Coat", since it's no longer
necessarily clear now. This matches naming in e.g. other renderers or OpenPBR.
- Adds an explicit Coat IOR input, in preparation for future smarter IOR logic
around the interaction between Coat and main IOR. This used to be hardcoded
to 1.5.
- Removes hardcoded 0.25 weight multiplier, and adds versioning code to update
existing files accordingly. OBJ import/export still applies the factor.
- Replaces the GTR1 microfacet component with regular GGX. This removes a corner
case in the Microfacet code, solves #53038, and makes us more consistent with
other standard surface shaders. The original Disney BSDF used GTR1, but it
doesn't appear that it caught on in the industry.
Co-authored-by: Weizhen Huang <weizhen@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/110993
Fix#100718: NLA Hold Forward Inconsistency
Action Track with 'extrapolation=Hold Forward' behaves the same as 'Hold'.
For the Action Track, we now properly treat extrapolation Hold_Forward just like the rest of the NLA system.
Co-author Wayde Moss @wbmoss_dev
Pull Request: https://projects.blender.org/blender/blender/pulls/109182
Code would access invalid (null) `pchan->bone` pointers, presumably due
to the (linked) armature data being heavily modified compared to the
local Object's poses? At least that's the idea of what caused this
invalid state of pose data.
Unfortunately the issue was detected in a very complex case.
Essentially, opening an older snapshot (r3034) of a Pets production anim
file with assets from current repository r3055), which have been heavily
cleaned-up.
This triggers massive amount of missing linked data from the older anim
file, and extremely heavy resyncing process of liboverrides.
In any case, calling `BKE_pose_ensure` before accessing object's pose
data should never be a bad thing. ;)
When data-block/asset previews were not stored in the thumbnail cache
yet (or were outdated), we'd read them from .blend files. This could
lead to random crashes (but quite reliable with a small number of
previews to be read).
Wasn't clearing runtime memory which could lead to the
`PRV_TAG_DEFFERED` bit being set. This meant we would try to free
deferred preview data since eefee47a8a, which was just garbage memory.
Change the existing "Is Shade Smooth" node to be named "Is Face Smooth"
and add a new "Is Edge Smooth" node. Also give the "Set Shade Smooth"
node the ability to set face or edge smoothness.
The fact that the nodes process "smooth" data reversed from the builtin
"sharp" attributes can be reversed with versioning in a separate commit.
While it's tempting to abstract the sharpness status into a single node,
face and edge smoothness are accessed separately in edit mode, and the
subtlety of interacting with data on different domains would make that
confusing. Instead, a separate "Is Shade Smooth" node group asset will
give all the sharp elements taking into account both builtin attributes.
The fact that sharpness is stored separately on two domains makes the
best design for simple operations non-obvious. For example, you should be
able to remove all sharpness or make everything flat with a single node.
The behavior depends on whether the two attributes exist and the
combination of values between the domains.
---
Pull Request: https://projects.blender.org/blender/blender/pulls/112029
Node group interfaces for 4.0 are written to blend files as legacy data
to enable forward compatibility. This data is meaningless in 4.0, so if
a blend file contains it, the data should be freed right away. The
code for freeing legacy data was incomplete.
Pull Request: https://projects.blender.org/blender/blender/pulls/111989
Change the versioning code so that all bone groups are converted to bone
collections, so also the ones that did not have any bones assigned.
As Demeter[1] put it: While bone groups with 0 bones assigned are
usually unintended, versioning should still preserve them I feel like,
just to be on the safe side. If there was an update to the vertex group
system, I would also expect empty vertex groups to survive, even though
they are strictly speaking pretty much pointless.
[1]: https://projects.blender.org/blender/blender/issues/111711#issuecomment-1013159
In 2.6 the old method of using bNodeSocket lists in bNodeTree directly
as group sockets was replaced with new group input/output nodes. This
required versioning to create those input/output nodes and then redirect
links to the new node sockets. Because creating nodes relies heavily on
node typeinfo this versioning was done in the `_after_linking` section
of the 2.6 versioning code, running after _all other versioning_
(including for much newer versions!) has already happended.
While typinfo is available at that point, doing such late versioning
causes severe problems when the data structure changes, as is the case
with the recent node panels patch (#111348). The new node group
interface also has versioning code for 4.0, but this runs _before_ the
`_after_linking` code for 2.6! Versioning for node panels expects
sockets in bNodeTree to not have any links pointing at them, but this is
not true for old 2.6 files which have not yet been fully versioned at
that point, because of the late versioning stage. Subsequently 2.6
`_after_linking` code crashes when trying to modify node links with
dangling pointers.
The solution here is to move the old versioning code out of the
`after_linking` stage to restore the expected versioning chain. This
requires creating nodes and node sockets without any typeinfo, but
luckily we only need to create simple known group input/output nodes
which don't have much complicated behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/111704
Part of #91973
Moving the snapping code for the
* Graph Editor
* Action Editor
* and NLA editor
into the common system that lives on the scene.
This includes the Magnet icon for turning
snapping on and off.
The old settings translate to the new in the following way:
* `Frame Step` -> `Frame`
* `Second Step` -> `Second`
* `Nearest Frame` -> `Frame` + `Absolute Time Snap`
* `Nearest Second` -> `Second` + `Absolute Time Snap`
* `Nearest Marker` -> `Nearest Marker`
Since this moves the location of the snapping settings
from the editor to the scene, it changes the behavior.
Previously each editor could have different snapping
settings, where now they are all synced.
Pull Request: https://projects.blender.org/blender/blender/pulls/109015
Previously, BKE level preview image code was in `BKE_icons.h` and `icons.hh`.
While these types are related, I always found this quite hard to navigate since
preview image stuff was just in the middle of icon functions. Plus, people
don't expect preview image functions in icon files, the relationship is not
obvious.
Instead, use focused files that make it easy to quickly navigate them
and see what they are dealing with.
Pull Request: https://projects.blender.org/blender/blender/pulls/111709
This is more of a temp hack than a proper fix, proper solution would be
to make shapekeys actual embedded IDs (which they are, in all aspects
but actual implementation), and to address long-standing design tasks
about handling of unused data on file save (see #61209 and #87490).
But for now, simply do not write ShapeKeys IDs if they have no owner, or
their owner has no user (and is therefore also not written to disk).
Linking the armature ID directly, instead of the object containing the
armature, did not run the versioning code to create bone collections
from armature layers and bone groups.
Bone groups cannot be versioned into bone collections in this case, as
they only exist on the Object.
Bone layers are now properly versioned.
The main goal here is to rename things in a way that makes sense for
simulation baking, but also for the upcoming bake node.
This also removes some versioning code from 3.6 which initialized the
default bake path. Baked data from back then can't be loaded anymore
anyway, and the way the default path is generated is different now as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/111845
The file in question does not have the default (internal) root panel
flag for allowing child panels. This was probably saved before the flag
was added. A simple versioning snippet takes care of this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/111828
The hash tables and vector blenlib headers were pulling many more
headers than they actually need, including the C base math header,
our C string API header, and the StringRef header. All of this
potentially slows down compilation and polutes autocomplete
with unrelated information.
Also remove the `ListBase` constructor for `Vector`. It wasn't used
much, and making it easy to use `ListBase` isn't worth it for the
same reasons mentioned above.
It turns out a lot of files depended on indirect includes of
`BLI_string.h` and `BLI_listbase.h`, so those are fixed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111801
Commit e071288ab2 do_version code was copying an allocated string from
old to new socket data, but not freeing it in the old data properly.
String can actually be moved directly from old to new data, instead of
duplicating it.
Code would not keep filedata for read libraries long enough to be able
to pass along to the 'after_liblink' versioning code. Instead, it was
passing the main file data, leading to all kind of potential breakage in
versioning code, e.g. in case of checks on available DNA data.
Fix#111776.
Also bump the recorded minimum 3.6 subversion for opening files, to
correspond to a fix in the 3.6 branch that prevents bones from seemingly
disappearing when opening files with 4.x bone collections.
`BKE_simulation_state_serialize.hh` is not necessary anymore,
because the serialization is done at a lower level.
The functionality that lived there in the past is now part of
`BKE_bake_items_serialize.hh`.
The sound equalizer is using the Audaspace FFT Convolver.
The blender part creates an array of descriptions of power per "band"
and orders the creation of Equalizer (ISound) in the Audaspace.
Modifier can be created on sound strips. It lets you define
amplification or attenuation over frequency range from 30Hz to 20 kHz.
The power is limited to -30 db - 30 db. This is done using curve
mapping widget.
Co-authored-by: menda <alguien@aqui.es>
Co-authored-by: Richard Antalik <richardantalik@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/105613
Part 3/3 of #109135, #110272
Switch to new node group interfaces and deprecate old DNA and API.
This completes support for panels in node drawing and in node group
interface declarations in particular.
The new node group interface DNA and RNA code has been added in parts
1 and 2 (#110885, #110952) but has not be enabled yet. This commit
completes the integration by
* enabling the new RNA API
* using the new API in UI
* read/write new interfaces from blend files
* add versioning for backward compatibility
* add forward-compatible writing code to reconstruct old interfaces
All places accessing node group interface declarations should now be
using the new API. A runtime cache has been added that allows simple
linear access to socket inputs and outputs even when a panel hierarchy
is used.
Old DNA has been deprecated and should only be accessed for versioning
(inputs/outputs renamed to inputs_legacy/outputs_legacy to catch
errors). Versioning code ensures both backward and forward
compatibility of existing files.
The API for old interfaces is removed. The new API is very similar but
is defined on the `ntree.interface` instead of the `ntree` directly.
Breaking change notifications and detailed instructions for migrating
will be added.
A python test has been added for the node group API functions. This
includes new functionality such as creating panels and moving items
between different levels.
This patch does not yet contain panel representations in the modifier
UI. This has been tested in a separate branch and will be added with a
later PR (#108565).
Pull Request: https://projects.blender.org/blender/blender/pulls/111348
Armature layers (the 32 little dots) and bone groups are replaced with
Bone Collections:
- Bone collections are stored on the armature, and have a name that is
unique within that armature.
- An armature can have an arbitrary number of bone collections (instead
of the fixed 32 layers).
- Bones can be assigned to zero or more bone collections.
- Bone collections have a visibility setting, just like objects in scene
collections.
- When a bone is in at least one collection, and all its collections in
are hidden, the bone is hidden. In other cases (in any visible
collection, or in no collection at all), the bone visibility is
determined by its own 'hidden' flag.
- For now, bone collections cannot be nested; they are a flat list just
like bone groups were. Nestability of bone collections is intended to
be implemented in a later 4.x release.
- Since bone collections are defined on the armature, they can be used
from both pose mode and edit mode.
Versioning converts bone groups and armature layers to new bone
collections. Layers that do not contain any bones are skipped. The old
data structures remain in DNA and are unaltered, for limited forward
compatibility. That way at least a save with Blender 4.0 will not
immediately erase the bone group and armature layers and their bone
assignments.
Shortcuts:
- M/Shift+M in pose/edit mode: move to collection (M) and add to
collection (shift+M). This works similar to the M/Shift+M menus for
objects & scene collections.
- Ctrl+G in pose mode shows a port of the old 'bone groups' menu. This
is likely to be removed in the near future, as the functionality
overlaps with the M/Shift+M menus.
This is the first commit of a series; the bone collections feature will
be improved before the Blender 4.0 release. See #108941 for more info.
Pull request: https://projects.blender.org/blender/blender/pulls/109976
Move control over the color of bones from bone groups to the bones
themselves. Instead of using bone groups (which are defined on the pose,
and thus owned by the object), the color is stored on:
- the bone (`struct Bone`, or RNA `armature.bones['bone_name'].color`)
- a possible override on the pose bone (`struct bPoseChannel`, or RNA
`ob.pose.bones['bone_name'].color`).
When the pose bone is set to its default color, the color is determined
by the armature bone. In armature edit mode, the armature bone colors
are always used, as then the pose data is unavailable.
Versioning code converts bone group colors to bone colors. If the
Armature has a single user, the group color is stored on the bones
directly. If it has multiple users, the group colors will be stored on
the pose bones instead.
The bone group color is not removed from DNA for forward compatibility,
that is, to avoid immediate dataloss when saving a 3.6 file with 4.0.
This is part of the replacement of bone groups & armature layers with
bone collections. See the design task at #108941.
Pull request: https://projects.blender.org/blender/blender/pulls/109976
Move Auto-Offset toggle from Node Editor View menu
into the Editing > Node Editor section of User Preferences,
to reflect its use as a workflow option not configured
per editor or per file.
Pull Request: https://projects.blender.org/blender/blender/pulls/111589
These checks (shape keys and ID names) cost less than 1ms in Pets
production files, so think they are OK to run systematically.
The library consistency one is way more expensive (~200ms), so keeping
it behind the G_DEBUG_IO debug option for now.
NOTE: This code remains only executed in 'unlikely' case `G_DEBUG_IO` is
enabled. Think this should be systematically done, even though it can
have a non-neglectable cost... Will submit design task first though.
