The edited mesh is not occluded even with Xray alpha 1.0, but it still
occludes other meshes that are not in edit mode.
Therefore, to resolve, alpha is still considered in general occlusion,
but is ignored in occlusion of edited meshes.
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
Navigation operations, like those of the trackpad, are not modal and
therefore are confirmed on each call.
To prevent the transform operations from being updated in this case,
add a fake navigation flag.
The removal of this flag is postponed to the next call.
This reverts commit d53862351d.
After conducting tests with artists at the studio, it was observed that
altering the Transform Modal Maps caused significant disruption due to
the heavy reliance on the "Proportional Editing" and "Automatic
Constraint" features.
Considering this, it is now deemed more beneficial to provide users
with the choice of adapting their muscle memory to the new changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/109660
`Project Individual Elements` was never supported for `Vert Slide` and
`Edge Slide`, however, albeit erroneously, this option still affected
those operations.
In Blender 3.6 this situation of `Project Individual Elements`
affecting the result, has been "fixed". But users still preferred the
old behavior.
Therefore, instead of falling back to `Snap To Face`, support
`Project Individual Elements` for `Vert Slide` and `Edge Slide`.
This is more like how it worked previously.
Renames `OB_MODE_EDIT_GPENCIL`, `OB_MODE_PAINT_GPENCIL`, `OB_MODE_SCULPT_GPENCIL`, `OB_MODE_WEIGHT_GPENCIL`, `OB_MODE_VERTEX_GPENCIL, and the context modes` to `*_LEGACY`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109648
There is no need to pass `BVHTreeFromEditMesh` userdata if only
`BMEditMesh` is used in the callbacks.
And this code is only used in the snap system, with this change the
snap code is more simplified and organized.
There is no need to create callback members for the snap system when
only one type of object is using them.
So remove the callbacks and inline the code.
This usually promotes optimization, but in this case, no change in
performance was observed.
Caused by 968ecf6f8b.
The value of the last pivot of the view should not be changed if there
is no selection.
The variable is static precisely because of this.
`Mouse Input::in val_unproj` was disregarded when resetting the initial
mouse position.
This caused the mouse to return to the previous position before the
`Set Snap Base` after navigating the 3D view.
The internal `use_occlusion_test` option was only being removed if it
was in conjunction with the `Snap to Face` option.
Both test occlusion and Snap to Face are conflicting. In wireframe mode
the objects are not occluded, but Snap to Face can prevent them from
being snapped.
The solution is to prioritize snapping to other non-Face elements but
still allow "Snap to Face" in X-Ray mode.
As suggested in #108669, the "Navigate during Transform" option has
been removed and this feature works by default.
Now if you press `G`, `R` or `S` to move, rotate or scale an object you
can also navigate in the viewport.
Note that this update modifies the default keymap.
Now pressing `Alt` is required for the following modals:
- `PROPORTIONAL_SIZE_UP`,
- `PROPORTIONAL_SIZE_DOWN`,
- `PROPORTIONAL_SIZE`,
- `AUTOIK_CHAIN_LEN_UP`,
- `AUTOIK_CHAIN_LEN_DOWN`,
- `AUTOCONSTRAIN`,
- `AUTOCONSTRAINPLANE`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109388
- Use C++ types for matrices and vectors;
- Deduplicate code with `SnapData::register_result`;
This commit also improves the way of detecting supported snap types.
Since snapping to endpoints is already done when you snap to edges
together, there is no need to create a bvhtree with all the vertices.
Also use the appropriate endpoint definition for snap to armatures.
This is part of what was implemented in #109062
When adding multiple snap points (`A` key), the 'Snap Base' location no longer corresponds to the snap target point, so it becomes invisible.
Therefore, show the resulting `Snap Base` during this operation.
Pull Request: https://projects.blender.org/blender/blender/pulls/109379
The problem was caused because the `Nearest2dUserData::obmat_` member
was deallocated in derived classes even before the main class
destructor was called.
This is strange behavior and only seen in Mac or Linux Release builds.
The solution is to not rely on the destructor to register snap values.
So create a separate function.
