This changes the drawing of the zone nodes to align corresponding input
and output sockets. The resulting nodes are smaller and it's easier to see
how data is passed through them.
Drawing aligned sockets is already technically supported for quite a while
already, but we haven't used it so far. Using them for zone nodes seems to
provide benefits only. How we use aligned sockets in other nodes still has
to be discussed more.
This patch only changes run-time data. It doesn't affect what is written to
.blend files.
In the node declaration, aligned sockets are created by tagging a socket
so that it is aligned with the previous socket. This is a bit different from
what we had before where a single socket declaration would be used for
an input and output socket. I think the approach used here works better,
especially in a potential future scenario where the input and output socket
has a different type.
Pull Request: https://projects.blender.org/blender/blender/pulls/118335
The check for owner ID here was preventing the online manual access to work for user preference properties.
This is also true for Python API Documentation access.
Panorama dicing test fails for EEVEE on legacy platforms. EEVEE creates a shader interface
that isn't compatible with the vulkan backend. This PR hides the check.
Check should be enabled again after EEVEE has been replaced by EEVEE-Next.
This PR also changes the behavior when checks are executed. It used to be
executed when blender was build with asserts. Now it is behind the --debug-gpu flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/117992
The check for owner ID here was preventing the online manual access to work for user preference properties.
This is also true for Python API Documentation access.
The difficulty of implementing this iterator is that it requires lots of operator
overloads which are usually very simple to implement, but result in a lot of code.
The goal of this patch is to abstract the common parts so that it becomes easier
to implement random accessor iterators. Many algorithms can work more
efficiently with random access iterators than with other iterator types.
Also see https://en.cppreference.com/w/cpp/iterator/random_access_iterator
Pull Request: https://projects.blender.org/blender/blender/pulls/118113
New name: Extensions
Now that we are gettting closer to a launch I need to refer to this
feature in the documentation. As such it was time to bring it up to
date.
I'm also pointing the experimental feature to the task where the Alpha
launch is being coordinated (#117286). Once that task is all ticked we
will likely be ready to go out of experimental.
The name `use_occlusion_test` was misleading and led to errors.
If this variable is false, objects will be considered to always be
occluders.
Not a serious problem, since the flag is not being used.
This is different from applying effects to regular "source media" strips
like images or movies; an effect "hides" the input strip when it is
below itself in the channel.
Apply the same treatment to Color & Text strips. Fixes#118213.
If someone wants previous behavior for some reason, they can drag
the effect applied on Color/Text to be below the input strip.
Pull Request: https://projects.blender.org/blender/blender/pulls/118269
If there is no mask attribute yet and hidden vertices, the values for those
vertices wouldn't be initialized. Fix by simply initializing the entire array
when it's allocated.
So this happens on curves with only a single point in them.
If these are converted to the old particle system, we would end up with
a particle with only one key (invalid hair), then going to particle
editmode would crash.
The old particle system took care of this (e.g. when deleting keys in
`PARTICLE_OT_delete`)
See the following comment:
`/* We can't have elements with less than two keys. */`
So to resolve, only convert curves with multiple (>1) points in the
process.
Pull Request: https://projects.blender.org/blender/blender/pulls/118392
Dragging any other object type to the Bone Collections List results in
a null dereference. This PR adds check that the drag type is
WM_DRAG_BONE_COLLECTION.
Pull Request: https://projects.blender.org/blender/blender/pulls/118393
fa6384eb39 introduced explicit setting of operator context as argument for
function `ED_region_panels_ex()`. However, this did not work correctly, because
`UiLayout` did not exist when `uiLayoutSetOperatorContext()` was called. This
has to be done in `ed_panel_draw()`.
Another issue is, that panel may be drawn, when mouse is over tool region,
which means, that `sequencer_tools_region_draw()` must look for whether
this is happening in preview or timeline region.
Pull Request: https://projects.blender.org/blender/blender/pulls/118292
This is generally more flexible and less error prone. The struct
implements a proper descructorfor this anyway. That also makes the
separate free function unnecessary-- it's redundant with the destructor.
Crash when dragging tree-item from one window to other instance of tree
view, with drop_target then nullptr. Returning null in this case lets
the process proceed normally and tooltip display correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/116892
This converts the "Layer Adjustments" from GPv2 into modifier setups in GPv3.
They include:
* Layer tint
* Layer thickness offset
* Thickness factor (for the entire object)
Both the "layer tint" and the "thickness factor" are converted using the existing modifiers.
Because the thickness modifier uses a factor instead of an offset, the "layer thickness offset" is converted to a geometry nodes modifier setup for each layer that adds an offset value to the radii instead of multiplying by a factor.
Pull Request: https://projects.blender.org/blender/blender/pulls/118149
It should not be possible to end up with an asset representation that
does not have a valid pointer/reference to the asset library owning it,
it's injected via all constructors. So reflect that by using a reference
instead of a (possibly null) pointer.
In GPv2, strokes could be edited using bézier curve handles. This was implemented by creating an `editcurve` for a stroke that would store the handles and other attributes.
In GPv3, we can directly make use of the `CURVE_TYPE_BEZIER` and store the curve as a bézier curve.
Note: This PR only handles conversion. Not rendering or anything else.
Pull Request: https://projects.blender.org/blender/blender/pulls/118386
