This adds a "Snap to" option that allows using all the scenes snap
settings which includes incremental & absolute grid snapping options.
This is optional because always following scene snapping would not
snap to geometry by default (which seems to be the most useful default).
Those (aka root node trees and master collections) share same 'traits'
as the shapekeys: RNA cannot assign them, so we need to handle them as
sub-data of their owner IDs.
Not sure how much this will help in improving support of overrides for
scenes and nodetrees, but this is a mandatory step towards that goal for
sure.
We should now have the tools to ensure consistency of ID pointers
diffing in `rna_property_override_diff_propptr`.
As a reminder, for most ID pointers we just check the actual pointer value,
but this is not possible for embedded IDs like root node trees or master
collections, and for fake embedded ones like shapekeys, so those should be
handled as mere sub-data of their owner IDs in override context.
Code generating override operations would not deal properly with Pointer
RNA properties, trying by default to use and check pointers' names
properties like it does with items of a collection.
However, using name property in pointer RNA property case makes no
sense, so specialize the `no_prop_name` flag for each case (pointer or
collection).
here, since second override would generate local data-blocks with
different names than the linked data ones, name matching would fail and
breck handling of override diffing in shapekeys.
Note that shape keys are the only one concerned by that problem, since
other embedded IDs (root node trees and master collections) are fully
real ones, so they always get the same names.
Our beloved shapekeys are 'virtual' overrides, they need special
snowflake treatment here as well.
They do not have any override data, from override perspective they are
considered as mere sub-data from their owning ID (mesh, lattice, etc.).
Therefore, we should not copy override data from them, but instead
properly flag those new IDs as `LIB_EMBEDDED_DATA_LIB_OVERRIDE`.
Found while investigating T84373.
Code generating override operations would not deal properly with Pointer
RNA properties, trying by default to use and check pointers' names
properties like it does with items of a collection.
However, using name property in pointer RNA property case makes no
sense, so specialize the `no_prop_name` flag for each case (pointer or
collection).
here, since second override would generate local data-blocks with
different names than the linked data ones, name matching would fail and
breck handling of override diffing in shapekeys.
Note that shape keys are the only one concerned by that problem, since
other embedded IDs (root node trees and master collections) are fully
real ones, so they always get the same names.
Our beloved shapekeys are 'virtual' overrides, they need special
snowflake treatment here as well.
They do not have any override data, from override perspective they are
considered as mere sub-data from their owning ID (mesh, lattice, etc.).
Therefore, we should not copy override data from them, but instead
properly flag those new IDs as `LIB_EMBEDDED_DATA_LIB_OVERRIDE`.
Found while investigating T84373.
This commit adds the ability to provide a default value to
`attribute_try_get_for_output` and uses it for the `Point Scale` node,
which is important because the node uses multiplication.
The idea is to keep "name-specific" functionality in nodes rather than in
the attribute API, otherwise the complexity will be hard to keep track of.
So this fix doesn't apply to the Attribute Vector Math node, but hopfully
that is okay since that's now a lower level node for this purpose anyway.
Differential Revision: https://developer.blender.org/D10115
Use exact marker accessor. Harmless due to the current way the
transform system is used by tracking. But for the future development
proper accessor needs to be used.
Cycles has a lot of code like this:
```lang=c++
BL::Object::modifiers_iterator b_mod;
for (b_ob->modifiers.begin(b_mod); b_mod != b_ob->modifiers.end(); ++b_mod) {
```
Range-based for loops allow us to simplify this to:
```lang=c++
for (BL::Modifier &b_mod : b_ob->modifiers) {
```
In order to support this, a collection (such as `b_ob->modifiers`) must have
a `begin()` and `end()` method, that take no parameters and return an iterator.
The `end` method already exists, but the `begin` method takes the iterator as
argument currently.
This patch adds a new `begin` method that returns the iterator. The old `begin`
method is still available to avoid breaking existing code.
My assumption is that the old `begin` method took the iterator as parameter so
that the iterator is not copied or moved, i.e. its memory address is stable and
the destructor is only called once. I'm not sure if both of these requirements
are really necessary to ensure that the iterators work correctly. To be on the
safe side, I deleted the copy/move constructors/assignment operators.
Since C++17 there is "guaranteed copy elision" which basically allows us to
return a non-copyable and non-movable type from a function. To make that work,
I had to add a new constructor to `CollectionIterator` that calls `begin` on itself.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D10120
This commit changes the check at the beginning of the
"Make Instances Real" operator to account for the instances
created by nodes modifiers in the modifier stack.
Differential Revision: https://developer.blender.org/D10059
If the mesh has any corner or point attributes (e.g. vertex weights or
uv maps), those attributes will now be available on the generated points
as well.
Other domains can be supported as well. I just did not implement those yet,
because we don't have a use case for them.
Differential Revision: https://developer.blender.org/D10114
For term consistency with usage.
The clarity is more for consistency with the nla domain() processing
function names and the core struct member name it stores the results
in, "valid". The name "domain", which implies a function can operate
on it, seems more natural than "valid", which implies something is
wrong if false.
No functional changes.
Reviewed by: sybren
Differential Revision: http://developer.blender.org/D9692
The field will already be properly written to in (anim_sys.c)
nla_eval_domain_action(). It's easier to understand the property's
usage after removing the redundancy.
No functional changes.
Reviewed by: ChrisLend, sybren
Differential Revision: http://developer.blender.org/D9689
No functional changes.
Future patches {D8867} {D8296} make use of it.
Reviewed by: sybren, ChrisLend
Differential Revision: http://developer.blender.org/D9691
No intended functional changes.
Refactors animsys_evaluate_nla() into 2 versions:
animsys_evaluate_nla_for_keyframing(), animsys_evaluate_nla_for_flush()
to make it clear what data is being calculated and why.
Dummy strip creation has been refactored to two separate functions,
animsys_create_tweak_strip() and animsys_create_action_track_strip().
Both are evaluated differently from other strips and eachother. There's
no need to interweave them. A future patch D8296, generally requires
both strips.
___
XXX anim_sys.c) nlatrack_find_tweaked() is a temporary work around.
If anyone has any insight into this problem, help is appreciated.
Reviewed by: sybren
Differential Revision: http://developer.blender.org/D9696
When NLA strips weren't time-aligned with the underlying action, then
fcurve modifiers would not be drawn anchored to the strip. Fmodifiers
were evaluating properly, they just weren't drawn with the proper
offset and scale.
To fix it in this specific case, I've chosen to undo the keyframe
remapping then remap the draw-evaluation-time from scene time to
fcurve time. Afterward, I redo the keyframe remapping so the controls
are properly drawn.
The Envelope fmodifier has special drawing code which was fixed too. In
this case, no mapping at all was happening. The solution was similar,
to remap the envelope control points from fcurve time to scene time.
This patch adds a noise offset option to the grease pencil noise modifier.
It allows the user to animate the noise along the length of the stroke to create movement that is currently not possible.
It works by adding an offset to the noise table and adding the remaining floating point value to the noise table sampling.
Reviewed By: #grease_pencil
Differential Revision: https://developer.blender.org/D10021
Instead of submitting tons of tiny IO syscalls, we can speed things up
significantly by `mmap`ing the .blend file into virtual memory and directly
accessing it.
In my local testing, this speeds up loading the Dweebs file with all its
linked files from 19sec to 10sec (on Linux).
As far as I can see, this should be supported on Linux, OSX and BSD.
For Windows, a second code path uses `CreateFileMapping` and
`MapViewOfFile` to achieve the same result.
Reviewed By: mont29, brecht
Differential Revision: https://developer.blender.org/D8246
When NLA strips weren't time-aligned with the underlying action, then
fcurve modifiers would not be drawn anchored to the strip. Fmodifiers
were evaluating properly, they just weren't drawn with the proper
offset and scale.
To fix it in this specific case, I've chosen to undo the keyframe
remapping then remap the draw-evaluation-time from scene time to
fcurve time. Afterward, I redo the keyframe remapping so the controls
are properly drawn.
The Envelope fmodifier has special drawing code which was fixed too. In
this case, no mapping at all was happening. The solution was similar,
to remap the envelope control points from fcurve time to scene time.
Note that uv layers still can't be accessed with nodes, because those
only access attributes on the point domain currently, while uv data
is stored per corner. Implicit domain conversion hasn't been
implemented yet.
Some of these conversions are arbitrary to some degree.
However, the user experience is better when at least something
happens when converting between types, instead of just getting
zeros. I left out a few conversions that I wasn't sure about yet.
I also added conversions for float2.
This fixes the behavior of some nodes when the same attribute
name is used for input and output. If both attributes have a
different type, they can't exist at the same time. Therefore,
the input attribute has to be removed in order to create the
output attribute.
Previously, the input attribute was remove before it was used
in any computations. Now, the output is written to a temporary
buffer and only later saved in the geometry component. This
allows both attributes to coexist within the node.
The temporary attribute is only create when necessary. The
normal case without name collisions still works the same
as before.
Differential Revision: https://developer.blender.org/D10109
Ref T83793.
Clamp value to the -HALF_MAX .. HALF_MAX.
The non-clamped values were causing NaN and inf values saved to
the file, which was the root cause of glare node giving unexpected
result.
The nan/inf on overflow is something mentioned in the half data
type in OpenEXR header.
Differential Revision: https://developer.blender.org/D10105
Fixes a number of glitches, e.g. the sidebar disappearing when selecting an
asset or wrong AZones (the little chevrons to indicate a hidden region).
There were a couple of issues:
* Execution region was created, but not used.
* If an execution region already existed when refreshing the area, it was
tagged as hidden, not removed.
* The sidebar was always set to be hidden on refreshes.
* When toggling from Asset Browser to File Browser as regular editor (i.e. not
opened temporary via Ctrl+O or such), the sidebar region wasn't removed.
Adresses T83644.
Now the resolution can be reduced to get less details. This is very useful for doing storyboards to get a quick fill of any character.
Following UI review, the name "Resolution" has been changed to "Precision" because is more clear.
Differential Revision: https://developer.blender.org/D10076
