The main goal of these changes are to improve static (i.e. build-time)
checks on whether a given data can be allocated and freed with `malloc`
and `free` (C-style), or requires proper C++-style construction and
destruction (`new` and `delete`).
* Add new `MEM_malloc_arrayN_aligned` API.
* Make `MEM_freeN` a template function in C++, which does static assert on
type triviality.
* Add `MEM_SAFE_DELETE`, similar to `MEM_SAFE_FREE` but calling
`MEM_delete`.
The changes to `MEM_freeN` was painful and useful, as it allowed to fix a bunch
of invalid calls in existing codebase already.
It also highlighted a fair amount of places where it is called to free incomplete
type pointers, which is likely a sign of badly designed code (there should
rather be an API to destroy and free these data then, if the data type is not fully
publicly exposed). For now, these are 'worked around' by explicitly casting the
freed pointers to `void *` in these cases - which also makes them easy to search for.
Some of these will be addressed separately (see blender/blender!134765).
Finally, MSVC seems to consider structs defining new/delete operators (e.g. by
using the `MEM_CXX_CLASS_ALLOC_FUNCS` macro) as non-trivial. This does not
seem to follow the definition of type triviality, so for now static type checking in
`MEM_freeN` has been disabled for Windows. We'll likely have to do the same
with type-safe `MEM_[cm]allocN` API being worked on in blender/blender!134771
Based on ideas from Brecht in blender/blender!134452
Pull Request: https://projects.blender.org/blender/blender/pulls/134463
The dolly operators poll function was set to `view3d_rotation_poll`
instead of `view3d_zoom_or_dolly_poll` which reads like a mistake.
As it happens this didn't cause any user visible problems because
RV3D_LOCK_ZOOM_AND_DOLLY is only set when all other locks are set.
Nevertheless, logically the dolly operator should check that dolly
is not locked. Updated the poll function for dolly to check neither
rotation or zoom/dolly is locked with comments noting why both are
needed.
Also expand on code-comments for why dolly enforces perspective view.
How the new navigation pivot is determined depends a bit on the kind of brush:
* Brushes that deform or remove curves use the 3d-brush position at the start of
the brush.
* Brushes that add new curves set the pivot to the bounding box center of the
new curves.
Finding a good pivot point is not super trivial for curves, but the existing 3d
brush functionality seems to work well. This also has the benefit that almost no
additional computation is needed when the user is using the spherical brush
mode. However, if the projected mode is used, and orbit-around-selection is on,
then we have to compute the spherical brush center now anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/131907
Restore overlay depth drawing which was removed in [0].
For viewport navigation this is useful. Disable overlays
for other operations such as painting & object placement.
Also disable color drawing in the overlay_next engine drawing
when drawing depth, since it caused the viewport to show a
checkered backdrop.
Details:
A boolean argument has been added to ED_view3d_depth_override instead
of new enums in eV3DDepthOverrideMode since mixing object-filtering
and draw-type in the one enum gets verbose & awkward, where most
existing enums would have needed to include NO_OVERLAY in their name.
V3D_DEPTH_NO_OVERLAYS has been renamed to V3D_DEPTH_ALL,
the caller must pass in use_overlay as false.
[0]: 5fea1eda36
This implements the proposal from #124512. For that it contains the following
changes:
* Remove the global override of `new`/`delete` when `WITH_CXX_GUARDEDALLOC` was
enabled.
* Always use `MEM_CXX_CLASS_ALLOC_FUNCS` where it is currently used. This used
to be guarded by `WITH_CXX_GUARDEDALLOC` in some but not all cases. This means
that a few classes which didn't use our guarded allocator by default before,
are now using it.
Pull Request: https://projects.blender.org/blender/blender/pulls/130181
When the viewport orientation matched the view axis,
setting an axis view didn't redraw the region.
This caused the viewport text & grid not to update.
When starting a navigation operation that uses `Auto Depth` or
`Orbit Around Selection` the value of `#RegionView3D::dist` is modified
to match the distance from the new pivot.
This value was incorrect when the pivot was behind the viewer.
In these cases `dist` is negative.
This commit, in addition to fixing `dist`, also limits the execution of
this code to only when `Auto Depth` is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/122795
The code tried to retrieve the bounds from the data
synced back to the original object at the end of depsgraph
evaluation. That data is only set on original objects.
Instead just retrieve the bounds directly from the evaluated
object. Also make two variables const now that it's possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/119674
Caused by dd0e60fb51
That commit was an optimization attempt to reuse the depth buffer
updated by the engines.
But it fails when `GPU_clear_depth` is called for gizmos.
So, due to error proneness, revert that solution for now.
This is a solution to avoid redrawing the depth buffer for each Zoom
with `Auto Depth`.
The solution is to move the `ED_view3d_depth_override` function out of
`ED_view3d_autodist` and only call `ED_view3d_depth_override` if the
depth buffer is not used by any current engine.
Pull Request: https://projects.blender.org/blender/blender/pulls/113026
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
Recent refactor to viewport navigation caused a regression where
"Orbit Around Selected" logic to impacted "Free" NDOF navigation logic.
Resolve by disabling orbit around selection with "Free" navigation.
Implement the next phases of bounds improvement design #96968.
Mainly the following changes:
Don't use `Object.runtime.bb` for performance caching volume bounds.
This is redundant with the cache in most geometry data-block types.
Instead, this becomes `Object.runtime.bounds_eval`, and is only used
where it's actually needed: syncing the bounds from the evaluated
geometry in the active depsgraph to the original object.
Remove all redundant functions to access geometry bounds with an
Object argument. These make the whole design confusing, since they
access geometry bounds at an object level.
Use `std::optional<Bounds<float3>>` to pass and store bounds instead
of an allocated `BoundBox` struct. This uses less space, avoids
small heap allocations, and generally simplifies code, since we
usually only want the min and max anyway.
After this, to avoid performance regressions, we should also cache
bounds in volumes, and maybe the legacy curve and GP data types
(though it might not be worth the effort for those legacy types).
Pull Request: https://projects.blender.org/blender/blender/pulls/114933
Move object runtime data to a separate header and allocate it separately
as `blender::bke::ObjectRuntime`. This is how node, mesh, curves, and
point cloud runtime data is stored.
Benefits:
- Allow using C++ types in object runtime data
- Reduce space required for Object struct in files
- Increase conceptual separation between DNA and runtime data
- Remove the need to add manual padding in runtime data
- Include runtime struct definition only in files that require it
Pull Request: https://projects.blender.org/blender/blender/pulls/113957
Caused by 6faa39edb7
In that commit it was assumed that the view offset does not need to be
updated if the operator is `V3D_OP_MODE_ROTATE` instead of simply
checking `this->use_dyn_ofs`.
Since `use_dyn_ofs` is always `True` when using Auto Depth or Orbit
Arround Select, the offset should always be updated in these cases.
Discussed in #114646.
This commit transforms the "alt_navigation" option of the transform
operators into a new modal key item. "PASSTHROUGH_NAVIGATE"
In addition to cleaning up a lot of the code, it allows you to
customize the key chosen to navigate while transforming.
Since [0] modal transform in the 3D viewport caused key-maps to be
rebuilt by the event system. Creating a temporary copy for
ViewOpsData_Utility flagged the key-map as outdated.
This could crash (resolved by [1] - for the most-part), but would still
rebuild the whole key-map, adding unnecessary overhead.
This would also reset the KMI_EXPANDED flag, causing transform
to hide key-map items when using Blender with the key-map editor open.
Add a function to temporarily suppress key-map updates.
While not ideal, full support for temporary key-maps that behave
differently to user key-maps is a bigger project for something
that's only needed in one place.
[0]: 017d4912b2
[1]: 9a0eaa2062
In 384c2e1f36 it was assumed that `VIEWOPS_FLAG_PERSP_ENSURE` only
takes effect if Auto Perspective is enabled in preferences.
But that option is still required in camera view mode.
Therefore always set `VIEWOPS_FLAG_PERSP_ENSURE` if a navigation mode
requires it.
And add a comment explaining the reason.
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
