The translate node moves every point in the geometry, and the scale
node multiplies the "scale" attribute of the input geometry by its input.
While these operations are already possible with the "Attribute" nodes,
these new nodes fit nicely with the nodes specifically for changing the
"rotation" attribute that already exist, and they provide a simpler way
to do the same thing.
Differential Revision: https://developer.blender.org/D10100
Partially reverts 2250b5cefe.
Removing the user count and fake user count icons was controversial (which was
expected) and there are a few further changes needed, that won't make it in
time for the release, see D9946.
While there is a design to bring back the user count and fake user indicators,
a new design idea was proposed that the UI team wants to follow. This came too
late for the 2.92 release, the new design is targeted at the 2.93 release now.
Meanwhile, UI team decision was to simply revert the design changes.
The new design is being worked on in https://developer.blender.org/T84669.
Note that this commit does not revert some internal changes done in
2250b5cefe. Namely the introduction of `ed_util_ops.c` and data-block
operators in there. These will still be needed in the new design.
This patch allows connecting wires for object and collection socket
types to the "Group Input" node, which exposes them to be adjusted
in the modifier.
Thanks to @angavrilov's recent work in rB8964c02348f6, it is now
possible to edit pointer IDProperties in the interface when they are
drawn with `uiItemPointerR`.
This patch is composed of a few changes:
- Add code to create pointer properties in the modifier settings for
object and collection sockets, and also to draw them in the UI.
- Also search through the modifier's `IDProperty` settings to find IDs
used by the modifier.
- Change the setting's UI layout to support the change.
Differential Revision: https://developer.blender.org/D10056
This greatly simplifies the Point Distribute node. For a poisson disk
distribution, it now uses a simpler dart throwing variant. This results
in a slightly lower quality poisson disk distribution, but it still
fulfills our requirements: have a max density, minimum distance input
and stability while painting the density attribute.
This new implementation has a number of benefits over the old one:
* Much less and more readable code.
* Easier to extend with other distribution algorithms.
* Easier to transfer more attributes to the generated points later on.
* More predictable output when changing the max density and min distance.
* Works in 3d, so no projection on the xy plane is necessary.
This is related to T84640.
Differential Revision: https://developer.blender.org/D10104
This change removes copy-on-write operations from ID nodes which do not
need copy-on-write.
Should be no functional changes, as before the copy-on-write operation
would do nothing for those nodes anyway.
Building IDs which are not covered by copy-on-write process was not
implemented, which was causing parameters block not present, and, hence
causing crashes in areas which expected parameters to present.
First part of this change is related on making it so Copy-on-Write is
optional for ID nodes in the dependency graph.
Second part is related on using a generic builder for all ID types
which were not covered by Copy-on-Write before.
The final part is related on making it so build_id() is properly
handling ParticleSettings and Grease Pencil Data. Before they were not
covered there at all, and they need special handling because they do
have own build functions.
Not sure it worth trying to split those parts, as they are related to
each other and are not really possible to be tested standalone. Open
for a second opinion though.
Possible nut-tightening is to re-organize build_id() function so
that every branch does return and have an assert at the end, so that
missing ID type in the switch statement is easier to spot even when
using compilers which do not report missing switch cases.
As for question "why not use default" the answer is: to make it more
explicit and clear what is a decision when adding new ID types. We do
not want to quietly fall-back to a non-copy-on-write case for a newly
added ID types.
Differential Revision: https://developer.blender.org/D10075
There should be a conversion to native pixel size as expected by GHOST at the
window manager level, the dimensions at screen level do not need a conversion.
Differential Revision: https://developer.blender.org/D9976
Currently it is not possible to edit bare IDProperty pointer
values which are not explicitly defined through python via
UI fields. This is likely mostly because, unlike numeric values,
pointers aren't marked PROP_EDITABLE by default. However there
are also some bugs in the RNA code that need fixing.
The Geometry Nodes modifier uses bare properties to store
input settings for the node group it wraps, so supporting
Object and Collection sockets requires editable pointers.
This patch marks bare IDProperties editable, and ensures
that changing ID pointers rebuilds the dependency graph.
A type check is needed because an IDPROPERTY PointerPropertyRNA
can actually wrap a group value rather than an ID pointer.
Making pointers editable is not likely to accidentally
affect UI fields that were not intended to be editable,
because a simple `layout.prop` cannot determine which
datablocks to display in the menu and remains read-only.
The PROP_NEVER_UNLINK flag is also removed: it seems it
was added because the edit field that couldn't produce
a menu to set the pointer used to still display the unlink
button, but that seems not to be the case anymore.
Actual support for Object & Collection inputs in the modifier
is added in D10056, which can be used to test this code.
Differential Revision: https://developer.blender.org/D10098
The rna_idproperty_check call should be done before accessing
the prop pointer so that it can detect IDProperty values and
replace them with the actual PointerPropertyRNA object.
Ref D10098
The Asset Browser will be disabled and not available for the 2.92 release. In
alpha/beta builds, there will be an "Asset Browser" option under Preferences >
Experimental, if the developer extras are enabled.
Note that this also disables related UI elements (e.g. "Mark Asset" buttons,
Preferences settings for asset libraries, etc.).
The code is still in master of course, development and testing will continue
there. But there simply needs to be too much polishing and fixing before the
2.92 release, plus there are some design decisions to be reevaluated.
Check the milestone 1 project to follow ongoing work:
https://developer.blender.org/project/view/124/
This commit adds the "Save as Render" feature to the file output node,
that allows to disable the application of the configured view transform
and other color management settings on the image. If disable it uses
the standard view transform instead. This feature was originally
suggested in T83842 and is part of the color management improvements
task in T68926. With this feature it is possible to toggle the
application of the color management settings for each input socket
of the File Output node individually.
Reviewed By: brecht
Maniphest Tasks: T68926, T83842
Differential Revision: https://developer.blender.org/D9921
"F-Curve Visibility" is a bad UI label for a property that only affects
the display of unselected F-Curves. This commit clarifies the property
name by making it more specific with the word "Unselected", and by using
the word "Opacity". "F-Curve" is redundant in the UI label anyway because
it is included in the panel title.
Resolves T82587
Differential Revision: https://developer.blender.org/D10027
This right click select post outlines the reasons to make "Angle" the
default limit method: https://blender.community/c/rightclickselect/BVfbbc/
In short: Beveling every single edge rather than just sharp edges is
rarely the desired behavior, and the placement of the property in the UI
makes it easy to see the property's importance and toggle it.
Differential Revision: https://developer.blender.org/D8961
In order to avoid losing information, it sometimes makes sense for the
output attribute type to depend on the types of the input attributes.
Such a function already exists, `attribute_data_type_highest_complexity`,
it just needs to be used in a few more places. The change for the attribute
compare node is just so the code there uses the same code style as in the
attribute mix node.
Addresses part of T83793
Differential Revision: https://developer.blender.org/D10099
The root of the issue was caused by the dependency graph using ID pointer
to map evaluated state from old depsgraph to new one upon relations update.
This was failing when IDs were re-allocated rapidly: was possible that
Object ID's evaluated state assigned to Mesh and vice versa.
Now depsgraph uses Session UUID to identify which IDs to restore evaluated
state to. The session UUID is stored in the IDNode, so that id_orig is not
dereferenced on depsgraph update since the ID might be freed.
The root of the issue is identified by Campbell, original patch was done
by Bastien, thanks! Also thanks to Oliver and Ray and everyone else for
testing!
This change will try to add meta data when using a multilayered open
exr file output node in the compositor. It adds the current scene meta
data and converts existing cryptomatte keys so it follows the
naming that is configured in the file output node.
This change supports the basic use-case where the compositor is
used to output cryptomatte layers with a different naming scheme to
support external compositors. In this case the Multilayered OpenEXR
files are used and the meta data is read from the render result.
Meta data is found when render layer node is connected with the
file output node without any other nodes in between. Redirects and empty
node groups are allowed.
The patch has been verified to work with external compositors.
See https://devtalk.blender.org/t/making-sense-of-cryptomatte-usage-in-third-party-programs/16576/17
See patch for example files.
Reviewed By: Sergey Sharybin
Differential Revision: https://developer.blender.org/D10016
Fix keyframe properties not being editable when animating a
library-overridden datablock.
The problem was that RNA pointers were created based on the datablock
affected by the animation (for example an Object), instead of the
datablock that contains the FCurve itself (the Action). The latter can
be local to the current blend file and should thus be editable, even
when the former is not.
Reviewed By: mont29
Maniphest Tasks: T81965
Differential Revision: https://developer.blender.org/D10091
Without this, additional items could be added in the future
which wouldn't be included in the check.
Move the check out of the loop since this is such an unlikely
situation that checking every iteration isn't needed.
Also remove redundant casts.
This adds a new Align Rotation to Vector node based on the mockup
in T83669.
Reviewers: HooglyBoogly, simonthommes
Differential Revision: https://developer.blender.org/D10081
Previously, the span returned by `WriteAttribute`s might not contain the
current value of the attribute for performance reasons. To avoid some
bugs, the span now always contains the old values (they might have to
be copied over from the internal storage, dependending on how the
attribute is stored).
The old behavior is still available with the `get_span_for_write_only`
method. The span that it returns might not contain the current
attribute values. Therefore, it should only be used when you want
to overwrite an attribute without looking at the old values.
When painting using Auto-Normalize or Lock Relative with some
groups locked, the locked weights may not add up precisely to
1 because of precision limitations, which results in creating
nonzero weights close to FLT_EPSILON. With Lock Relative display
mode this is very obvious and annoying (random red points amid
black or blue), so add an epsilon check to consider less than
1e-6 unlocked weight to be the same as 0.
In addition, in cases when no weight can be painted due to locks,
don't create vertex group entries at all if they don't exist yet.
Also, don't run Auto Normalize when not painting a deform group.
Differential Revision: https://developer.blender.org/D10000
The function `rna_Particle_uv_on_emitter` did not handle the case where
`particle->num_dmcache` was `DMCACHE_ISCHILD`. This resulted in an
incorrect offset for the `mtface` pointer. The commit checks for the
case and sets the offset accordingly, similar to existing code in
e.g. `particle_calculate_parent_uvs`.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D10072
The Bmesh from_object method applies modifiers twice when the input
deform is enabled and the input depsgraph is a render one.
The evaluated object already have modifiers applied, and
mesh_create_eval_final() applies modifiers again. To fix this, the
BKE_mesh_new_from_object() function is used instead.
Reviewed By: Brecht
Differential Revision: https://developer.blender.org/D10053
* Simplify and clarify logic in `BKE_undosys_step_undo/redo_with_data_ex`,
by adding early return on invalid situations, renaming some variables,
and adding comments.
* Add more sanity checks in those functions.
No behavioral change are expected here, besides in potential edge-case,
invalid situations.
This is a preliminary change, before some deeper modifications of
`BKE_undosys` undo/redo API.
Differential Revision: https://developer.blender.org/D10033
The Surface -> Nurbs Curve behaves now like the Curve -> Nurbs Curve,
if you initially select less than all points. So, multiple points can
be selected and extruded which just moves the selected points similar
to Curve -> Nurbs Curve object.
Differential Revision: https://developer.blender.org/D9934
linked obdata) fail
Caused by rB1a650fdcb286.
Above commit made polling more restricitive in that it did not allow for
actions on material slots (linked to object, not object data) on objects
with liked object data. This should be allowed though.
Maniphest Tasks: T84593
https://developer.blender.org/D10078
