The transformation snapping code contains a bunch of `#define`s, some ambiguously or incorrectly named attributes. This patch contains refactored code to improve this. This patch does (should) not change functionality of snapping.
Clarified ambiguously / incorrectly named attributes.
- "Target" is used to refer to the part of the source that is to be snapped (Active, Median, Center, Closest), but several other areas of Blender use the term "target" to refer to the thing being snapped to and "source" to refer to the thing getting snapped. Moreover, the implications of the previous terms do not match the descriptions. For example: `SCE_SNAP_TARGET_CENTER` does not snap the grabbed geometry to the center of the target, but instead "Snap transforamtion center onto target".
- "Select" refers to the condition for an object to be a possible target for snapping.
- `SCE_SNAP_MODE_FACE` is renamed to `SCE_SNAP_MODE_FACE_RAYCAST` to better describe its affect and to make way for other face snapping methods (ex: nearest).
Refactored related `#define` into `enum`s. In particular, constants relating to...
- `ToolSettings.snap_flag` are now in `enum eSnapFlag`
- `ToolSettings.snap_mode` are now in `enum eSnapMode`
- `ToolSettings.snap_source` (was `snap_target`) are now in `enum eSnapSourceSelect`
- `ToolSettings.snap_flag` (`SCE_SNAP_NO_SELF`) and `TransSnap.target_select` are now in `enum eSnapTargetSelect`
As the terms became more consistent and the constants were packed together into meaningful enumerations, some of the attribute names seemed ambiguous. For example, it is unclear whether `SnapObjectParams.snap_select` referred to the target or the source. This patch also adds a small amount of clarity.
This patch also swaps out generic types (ex: `char`, `short`, `ushort`) and unclear hard coded numbers (ex: `0`) used with snap-related enumerations with the actual `enum`s and values.
Note: I did leave myself some comments to follow-up with further refactoring. Specifically, using "target" and "source" consistently will mean the Python API will need to change (ex: `ToolSettings.snap_target` is not `ToolSettings.snap_source`). If the API is going to change, it would be good to make sure that the used terms are descriptive enough. For example, `bpy.ops.transform.translate` uses a `snap` argument to determine if snapping should be enabled while transforming. Perhaps `use_snap` might be an improvement that's more consistent with other conventions.
This patch is (mostly) a subset of D14591, as suggested by @mano-wii.
Task T69342 proposes to separate the `Absolute Grid Snap` option out from `Increment` snapping method into its own method. Also, there might be reason to create additional snapping methods or options. (Indeed, D14591 heads in this direction). This patch can work along with these suggestions, as this patch is trying to clarify the snapping code and to prompt more work in this area.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D15037
After this commit, all mesh data extraction and drawing code is in C++,
including headers, making it possible to use improved types for future
performance improvements and simplifications.
The only non-trivial changes are in `draw_cache_impl_mesh.cc`,
where use of certain features and macros in C necessitated larger
changes.
Differential Revision: https://developer.blender.org/D15088
This implements transform modes for the transform tool and Elastic
Transform. This mode uses the Kelvinlets from elastic deform to apply
the transformation to the mesh, using the cursor radius to control the
elasticity falloff.
{F9269771}
In order for this to work, the transform tool uses incremental mode when
elastic transform is enabled. This allows to integrate the displacement of
the Kelvinet in multiple steps.
Review By: Sergey Sharbin & Daniel Bystedt & Julian Kaspar & Campbell
Barton
Differential Revision: https://developer.blender.org/D9653
Ref D15041
This was leading to some crashes and warnings such as:
"Code marked as unreachable has been executed. Please report this as a bug."
Differential Revision: https://developer.blender.org/D15116
In the latest discussions about curves/hair mesh attachement
information (T95776), it was decided to use UV coordinates to
store where on the mesh each root is. For that, we have to specify
which of the UV map attributes to use for UV lookups.
This property isn't used yet, but it will be shortly when refactoring
the attachement information in the add brush and the to particle
system conversion.
Differential Revision: https://developer.blender.org/D15115
This patch makes it possible to manipulate strips without need to use
update functions to recalculate effect and meta strips.
Prior to this change function `SEQ_time_update_sequence` had to be used
to update mainly effects and meta strips. This was implemented in a way
that relied on sorted list of strips, which can't always be done and in
rare cases this approach failed.
In case of meta strips, `seqbase` had to be passed and compared with
"active" one to determine whether meta strip should be updated or not.
This is especially weak system that is prone to bugs when functions are
used by python API functions.
Finally, other strip types had startdisp` and `enddisp` fields updated
by this function and a lot of code relied on these fields even if strip
start, length and offsets are available. This is completely
unnecessary.
Implemented changes:
All effects and meta strips are updated when strip handles are moved or
strip is translated, without need to call any update function.
Function `SEQ_time_update_sequence` has been split to
`SEQ_time_update_meta_strip_range` and
`seq_time_update_effects_strip_range`. These functions should be only
used within sequencer module code. Meta update is used for versioning,
which is only reason for it not being declared internally.
Sequence fields `startdisp` and `enddisp` are now only used for
effects to store strip start and end points. These fields should be
used only internally within sequencer module code.
Use function `SEQ_time_*_handle_frame_get` to get strip start and end
points.
To update effects and meta strips with reasonable performance, cache
for "parent" meta strip and attached effects is added to
`SequenceLookup` cache, so it shares invalidation mechanisms.
All caches are populated during single iteration.
There should be no functional changes.
Differential Revision: https://developer.blender.org/D14990
This commit adds a float selection to curve control points or curves,
a sculpt tool to paint the selection, and uses the selection influence
in the existing sculpt brushes.
The selection is the inverse of the "mask" from mesh sculpt mode
currently. That change is described in more detail here: T97903
Since some sculpt tools are really "per curve" tools, they use the
average point selection of all of their points. The delete brush
considers a curve selected if any of its points have a non-zero
selection.
There is a new option to choose the selection domain, which affects how
painting the selection works. You can also turn the selection off by
clicking on the active domain.
Sculpt brushes can be faster when the selection is small, because
finding selected curves or points is generally faster than the
existing brush intersection and distance checks.
The main limitation currently is that we can't see the selection in the
viewport by default. For now, to see the selection one has to add a
simple material to the curves object as shown in the differential
revision. And one has to switch to Material Preview in the 3d view.
Differential Revision: https://developer.blender.org/D14934
Add support for adding (inserting) new background images into an
override of a linked Camera ID.
Request from the Blender studio.
This ended up being more involved than expected as it uncovered some
latent issues with existing background images code. Noticiably, a new
`BKE_camera_background_image_copy` had to be added to handle copying
of background images in a proper, generic ID-management way.
This is a follow up to rBbb0fc675822f313c5546a2498a162472c2571ecb.
Now the same kind of run-time data is added to nodes and sockets.
Differential Revision: https://developer.blender.org/D15060
`bNodeTree` has a lot of run-time embedded in it currently. Having a separately
allocated run-time struct has some benefits:
* Run-time data is not stored in files.
* Makes it easy to use c++ types as run-time data.
* More clear distinction between what data only exists at run-time and which doesn't.
This commit doesn't move all run-time data to the new struct yet, only the data where
I know for sure how it is used. The remaining data can be moved separately.
Differential Revision: https://developer.blender.org/D15033
Previously the function had a fair amount of ugly boilerplate to avoid
allocating the temporary layers array, and then free it if necessary.
`blender::Vector` solves that problem more elegantly. Passing a span,
using references in a few cases, and using a switch statement also make
the functions simpler.
This refactoring is in preparation for D14583 and D14685.
Differential Revision: https://developer.blender.org/D15011
full scaled image isn't used anymore. It was added to use a different scale when
displaying an image in the image editor. This was replaced by the image engine
redesign.
This change will reduce complexity of {T98375}.
This patch makes it possible to change the precision with which to
store volume data in the NanoVDB data structure (as float, half, or
using variable bit quantization) via the previously unused precision
field in the volume data block.
It makes it possible to further reduce memory usage during
rendering, at a slight cost to the visual detail of a volume.
Differential Revision: https://developer.blender.org/D10023
This patch adds 4th option to Time offset modifier Modes.
It loops from start frame to end frame and then back to start in reverse direction.
In other words it is a combination of Normal and Reverse mode.
Especially with offset control it adds the ability to create easy looping animations such as cheering crowds, flowers opening and closing at different offsets.
Reviewed By: #grease_pencil, antoniov, pepeland, mendio
Differential Revision: https://developer.blender.org/D14965
Display information about sound media in "Source" category in side panel
similar to movie resolution and framerate.
The specs are stored in the `Sequence` struct, and are extracted at
the moment of struct creation. If the "source file" is changed,
the specs change also.
Reviewed By: ISS
Differential Revision: https://developer.blender.org/D14565
There's currently 4 places that need to be edited when adding
a DNA header, and as you can imagine, this has gotten out of
sync quite a bit.
source/blender/CMakeLists.txt - 84 headers
source/blender/makesdna/intern/CMakeLists.txt - 33 headers
source/blender/makesdna/intern/makesdna.c@includefiles - 77 headers
source/blender/makesdna/intern/makesdna.c@Disabletypes - 76 headers
This diff makes source/blender/CMakeLists.txt the only place
where we need to keep track of dna headers, less maintenance
less mistakes. For all old places there is now a comment reminding
people of the new location.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D13048
To clarify term still frame: This is portion of strip that displays
static image. This area can exist before or after strip movie content.
Still frames were implemented as strip property, but this was never
displayed in panel. Only way to set still frames was to drag strip
handle with mouse or using python API. This would set either
`seq->*still` or `seq->*ofs` where * stands for `start` or `end`.
When strip had offset, it can't have still frames and vice versa, but
this had to be enforced in RNA functions and everywhere in code where
these fields are set directly. Strip can not have negative offset or
negative number of still frames.
This is not very practical approach and still frames can be simply
implemented as applying negative offset. Merging these offsets would
simplify offset calculations for example in D14962 and could make it
easier to also deprecate usage `seq->*disp` and necessity to call
update functions to recalculate strip boundaries.
For users only functional change is ability to set negative strip offset
using property in side panel.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D14976
Previously, the depsgraph assumed that every node tree might contain
a reference to a video. This resulted noticeable overhead when there
was no video.
Checking whether a node tree contained a video was relatively expensive
to do in the depsgraph. It is cheaper now due to the structure of the new
node tree updater.
This also adds an additional run-time field to `bNodeTree` (there are
quite a few already). We should move those to a separate run-time
struct, but not as part of a bug fix.
Differential Revision: https://developer.blender.org/D14957
The old method doesn't check e for array boundary.
The new method ensures it only access valid elements.
Reviewed By: Sebastian Parborg (zeddb)
Differential Revision: https://developer.blender.org/D14903
This change allows the chaining function to select edges
from the same contour loop first, thus reduced rouge chain
connections (connected different objects instead of chaining
inside the same object first) and improved chaining quality.
This patch also included the default value change for chain
split threshold (Now don't split by default to make initial
result as smooth as possible)
Reviewed By: Sebastian Parborg (zeddb)
Differential Revision: https://developer.blender.org/D14950
We really need to fix how unprojected radius (scene unit) works.
What happened is the paint code updates the brush's normal radius
with the current unprojected pixel radius, which was then
used by texture brush tiled mode.
To fix this I just cached the pixel radius at stroke start in
UnifiedPaintSettings->start_pixel_radius.
This completes support for tiled texture packing on the Blender / Cycles
side of things.
Most of these changes fall into one of three categories:
- Updating Image handling code to pack/unpack tiled and multi-view images
- Updating Cycles to handle tiled textures through BlenderImageLoader
- Updating OSL to properly handle textures with multiple slots
Differential Revision: https://developer.blender.org/D14395
This commit adds an option to interpolate the number of control points
in new curves based on the count in neighboring existing curves. The
idea is to provide a more automatic default than manually controlling
the number of points in a curve, so users don't have to think about
the resolution quite as much.
Internally, some utilities for creating new curves are extracted to a
new header file. These can be used for the various nodes and operators
that create new curves.
The top-bar UI will be adjusted in a separate patch, probably moving
all of the settings that affect the size and shape of the new curves
into a popover.
Differential Revision: https://developer.blender.org/D14877
The acquire locking of the draw manager introduced other issues.
The current implementation was a hacky solution as we know that the
final solution is something totally different {T98016}.
Related issues:
* {T97988}
* {T97600}
The acquire locking of the draw manager introduced other issues.
The current implementation was a hacky solution as we know that the
final solution is something totally different {T98016}.
Related issues:
* {T97988}
* {T97600}
This patch adds the show_gizmo and show_gizmo_navigate properties to the Image and UV editors.
Image Editor:
{F13026317}
UV Editor:
{F13026319}
VIDEO:
{F13026324}
Reviewed By: #user_interface, campbellbarton
Differential Revision: https://developer.blender.org/D14755
Inspired by D12936 and D12929, this patch adds general purpose
"Combine Color" and "Separate Color" nodes to Geometry, Compositor,
Shader and Texture nodes.
- Within Geometry Nodes, it replaces the existing "Combine RGB" and
"Separate RGB" nodes.
- Within Compositor Nodes, it replaces the existing
"Combine RGBA/HSVA/YCbCrA/YUVA" and "Separate RGBA/HSVA/YCbCrA/YUVA"
nodes.
- Within Texture Nodes, it replaces the existing "Combine RGBA" and
"Separate RGBA" nodes.
- Within Shader Nodes, it replaces the existing "Combine RGB/HSV" and
"Separate RGB/HSV" nodes.
Python addons have not been updated to the new nodes yet.
**New shader code**
In node_color.h, color.h and gpu_shader_material_color_util.glsl,
missing methods hsl_to_rgb and rgb_to_hsl are added by directly
converting existing C code. They always produce the same result.
**Old code**
As requested by T96219, old nodes still exist but are not displayed in
the add menu. This means Python scripts can still create them as usual.
Otherwise, versioning replaces the old nodes with the new nodes when
opening .blend files.
Differential Revision: https://developer.blender.org/D14034
