Previously, different Random Float nodes would generate different values
depending on where they are in the node group hierarchy. This can be useful,
but should definitely not be the default behavior, because it is very inconsistent
with other nodes.
Previously, the signature of a `MultiFunction` was always embedded into the function.
There are two issues with that. First, `MFSignature` is relatively large, because it contains
multiple strings and vectors. Secondly, constructing it can add overhead that should not
be necessary, because often the same signature can be reused.
The solution is to only keep a pointer to a signature in `MultiFunction` that is set during
construction. Child classes are responsible for making sure that the signature lives
long enough. In most cases, the signature is either embedded into the child class or
it is allocated statically (and is only created once).
Added a first test case for review. This will be the base for future test cases.
The current API is sufficient for what is expected for such a low level API.
One concern is that you need to trigger a save in order to update the library overrides
structure. Not expected from TD/Dev point of view.
Test cases are very important when implementing restrictive mode as it is a second evaluation mode that
has impact on the (current) permissive mode.
Reviewed By: Sebastián Barschkis, Bastien Montagne
Differential Revision: https://developer.blender.org/D10747
The impact of translations on UI performances is neglectable, and this
gives better handling of some odd cases where original language of an
add-on is not English.
Currently 3 of the printf lines use the format specifier "%lu" for data
of type size_t instead of "%zu". While this works, this creates compiler
warnings.
This diff fixes those warnings by using the correct format specifier.
Tested using MSVC, but should be correct on any compliant compiler.
Reviewed By: Sebastian Parborg
Differential Revision: http://developer.blender.org/D10761
- Use `use_` prefix for boolean properties.
- Use `_all` instead of `_everything`,
following existing conventions and the properties UI text.
- Use `object_instances` instead of old term `dupli` / `duplication`.
- Use `clip_plane` instead of `clipping_boundaries`,
matching the RegionView3D property naming.
When a function is executed for many elements (e.g. per point) it is often the case
that some parameters are different for every element and other parameters are
the same (there are some more less common cases). To simplify writing such
functions one can use a "virtual array". This is a data structure that has a value
for every index, but might not be stored as an actual array internally. Instead, it
might be just a single value or is computed on the fly. There are various tradeoffs
involved when using this data structure which are mentioned in `BLI_virtual_array.hh`.
It is called "virtual", because it uses inheritance and virtual methods.
Furthermore, there is a new virtual vector array data structure, which is an array
of vectors. Both these types have corresponding generic variants, which can be used
when the data type is not known at compile time. This is typically the case when
building a somewhat generic execution system. The function system used these virtual
data structures before, but now they are more versatile.
I've done this refactor in preparation for the attribute processor and other features of
geometry nodes. I moved the typed virtual arrays to blenlib, so that they can be used
independent of the function system.
One open question for me is whether all the generic data structures (and `CPPType`)
should be moved to blenlib as well. They are well isolated and don't really contain
any business logic. That can be done later if necessary.
We cannot use `std::variant` yet, because not all of the compilers
we support have a working version of it yet. For now, I just replaced
it with multiple `std::option` which is good enough, because currently
`CellValue` is only used for the cells that are actually drawn in
the spreadsheet.
When the movie wasn't found, uninitialized values would be used for
the original width/height.
Also use int instead of float as the image size is stored as an int.
SetWindowPos must be called after SetWindowLongPtr in order to see changes to window frame style.
Differential Revision: https://developer.blender.org/D10756
Reviewed by Ray Molenkamp
Some generic algorithms from the standard library like `std::any_of`
did not work with all container and iterator types. To improve the
situation, this patch adds various type members to containers
and iterators.
Custom iterators for Set, Map and IndexRange now have an iterator
category, which soe algorithms require. IndexRange could become
a random access iterator, but adding all the missing methods can
be done when it is necessary.
The description was missing from the Quick Liquid operator.
The fix adds the following description:
"Make selected objects liquid"
Reviewed By: sebbas
Maniphest Tasks: T86746
Differential Revision: https://developer.blender.org/D10777
The offset when creating the keyframes was set to `frame_target + i` but
`i` starts iterating from the current frame number.
The fix uses just `i` as the frame number.
Reviewed By: antoniov
Maniphest Tasks: T86745
Differential Revision: https://developer.blender.org/D10772
When joining curves, the resulting curve will inherit the bevel depth of
the active curve, but the radii would stay the same which leads to
changed appearance when joining.
Now compensate for this taking the different bevel depths into account
(if present).
Was a feature request here (and I also think we had reports about this
-- which were usually turned down as not-a-bug):
https://blender.community/c/rightclickselect/bhhbbc/
Differential Revision: https://developer.blender.org/D10752
