Age | Commit message (Collapse) | Author |
|
This just makes the minimum changes to make the files compile.
|
|
|
|
Regression in [0] which didn't account for the bounds of empty objects.
Add support support calculating bounds from empty draw-type to use in
pose-bone culling.
[0]: 3267c91b4d5caab7da8aef071a446dd2e86f86a9
|
|
In the current code we do not render any curves if they have not been
converted to meshes. This change makes the custom bone drawing try to
render mesh objects first and then falls back to curve objects if there
is no mesh data available.
Reviewed By: Clement
Differential Revision: http://developer.blender.org/D14804
|
|
|
|
This avoid conflicting defines in GLSL
Fix T96998 Blender 3.2.0 Alpha crashes on startup
|
|
Regression in 3267c91b4d5caab7da8aef071a446dd2e86f86a9.
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
|
|
Viewport cull bones during selection to avoid depth-picking
reading the depth buffer for bones that aren't in the viewport.
Files with thousands of bones could hang blender for seconds while
selecting. The issue could still happen with overlapping bones or when
zoomed out so all bones are under the cursor, however in practice this
rarely happens.
Now files with many bones select quickly.
Related changes include:
- Split `BKE_pchan_minmax` out of `BKE_pose_minmax`.
- Add `mat3_to_size_max_axis` to return the length of the largest
axis (used for scaling the radius).
Reviewed By: sybren
Maniphest Tasks: T91253
Ref D13990
|
|
|
|
Part of T91671.
Not much else to say, this is mainly a massive deletion of code.
Note that a few cleanups possible after this proxy removal were kept out
of this commit to try to reduce a bit its size.
Reviewed By: sergey, brecht
Maniphest Tasks: T91671
Differential Revision: https://developer.blender.org/D13995
|
|
These aren't used for picking bones so there is no need to draw them.
|
|
The evaluated mesh is a result of evaluated modifiers, and referencing
other evaluated IDs such as materials.
It can not be stored in the EditMesh structure which is intended to be
re-used by many areas. Such sharing was causing ownership errors causing
bugs like
T93855: Cycles crash with edit mode and simultaneous viewport and final render
The proposed solution is to store the evaluated edit mesh and its cage in
the object's runtime field. The motivation goes as following:
- It allows to avoid ownership problems like the ones in the linked report.
- Object level is chosen over mesh level is because the evaluated mesh
is affected by modifiers, which are on the object level.
This patch allows to have modifier stack of an object which shares mesh with
an object which is in edit mode to be properly taken into account (before
the change the modifier stack from the active object will be used for all
objects which share the mesh).
There is a change in the way how copy-on-write is handled in the edit mode to
allow proper state update when changing active scene (or having two windows
with different scenes). Previously, the copt-on-write would have been ignored
by skipping tagging CoW component. Now it is ignored from within the CoW
operation callback. This allows to update edit pointers for objects which are
not from the current depsgraph and where the edit_mesh was never assigned in
the case when the depsgraph was evaluated prior the active depsgraph.
There is no user level changes changes expected with the CoW handling changes:
should not affect on neither performance, nor memory consumption.
Tested scenarios:
- Various modifiers configurations of objects sharing mesh and be part of the
same scene.
- Steps from the reports: T93855, T82952, T77359
This also fixes T76609, T72733 and perhaps other reports.
Differential Revision: https://developer.blender.org/D13824
|
|
Custom bones are drawn by instancing the GPUBatch of the base object. To
access the mesh and its GPUBatch, `BKE_object_get_evaluated_mesh` was
used. However, since GPU subdivision support, this will return a
subdivision wrapper which will never be drawn, and thus will have an
invalid batch, which caused the crash.
`BKE_object_get_evaluated_mesh_no_subsurf` should be used instead, to
return the mesh that will be drawn, and have the subdivision evaluated
on the GPU. Note that the rest of the draw code is already using this
function.
|
|
When weight painting the bone overlay is extremely intrusive,
effectively requiring either extensive use of hiding individual
bones, or disabling the whole bone overlay between selections.
This addresses the issue by adding a bone opacity slider that
is used for the 'wireframe' armature drawing mode. It directly
controls the uniform opacity as a straightforward option.
Differential Revision: https://developer.blender.org/D11804
|
|
This evaluator is used in order to evaluate subdivision at render time, allowing for
faster renders of meshes with a subdivision surface modifier placed at the last
position in the modifier list.
When evaluating the subsurf modifier, we detect whether we can delegate evaluation
to the draw code. If so, the subdivision is first evaluated on the GPU using our own
custom evaluator (only the coarse data needs to be initially sent to the GPU), then,
buffers for the final `MeshBufferCache` are filled on the GPU using a set of
compute shaders. However, some buffers are still filled on the CPU side, if doing so
on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose
logic is hardly GPU compatible).
This is done at the mesh buffer extraction level so that the result can be readily used
in the various OpenGL engines, without having to write custom geometry or tesselation
shaders.
We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in
order to control the data layout, and interpolation. For example, we store vertex colors
as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float
types.
In order to still access the modified geometry on the CPU side, for use in modifiers
or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`.
Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will
create such a wrapper if possible. If the final subdivision surface is not needed on
the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used.
Enabling or disabling GPU subdivision can be done through the user preferences (under
Viewport -> Subdivision).
See patch description for benchmarks.
Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport
Differential Revision: https://developer.blender.org/D12406
|
|
Also add groups in some files.
|
|
Ref T92709
|
|
The problem is that drw_batch_cache_generate_requested_delayed
is called on the object, which uses the original object data type to
choose which data type to get info for. So for curves and text it uses
the incorrect type (not the evaluated mesh like we hardcoded in the
armature overlay code).
To fix this I hardcoded the "delayed" generation to only use the
evaluated mesh. Luckily it wasn't use elsewhere besides this
armature overlay system. That seems like the simplest fix for
3.0. A proper solution should rewrite this whole area anyway.
Differential Revision: https://developer.blender.org/D13439
|
|
This part of the drawing code assumes that the bone custom object
has only one evaluated geometry component, and it also uses the
object type to check which data to draw, with the functions like
`DRW_cache_object_surface_get` that just take an object input.
Those functions usually work on evaluated objects, which use the
instancing system to access a temporary object with `object.data`
replaced for data types that don't match the original object.
That assumption used to work, but now curve, point cloud, or volume
objects can have an evaluated mesh which is not accessed with the
same object for render engine drawing.
The "correct" solution for the way this code is structured would be to
loop through all of the geometry components and try to get GPU batches
from every one of them. However, that significantly increases complexity
in an area that should probably be refactored anyway. This patch treats
the mesh as a special case, and only draws the evaluated mesh.
The **best** solution in my opinion might be refactoring this area to
use the instancing system with some sort of viewport-only flag so
the custom shape instances aren't added in the render.
The solution is "partial" because the "Wireframe" option only works
for meshes from mesh objects, even after this fix, and because other
data besides meshes is not displayed at all.
Differential Revision: https://developer.blender.org/D13038
|
|
|
|
|
|
This commit moves the storage of `bDeformGroup` and the active index
to `Mesh`, `Lattice`, and `bGPdata` instead of `Object`. Utility
functions are added to allow easy access to the vertex groups given
an object or an ID.
As explained in T88951, the list of vertex group names is currently
stored separately per object, even though vertex group data is stored
on the geometry. This tends to complicate code and cause bugs,
especially as geometry is created procedurally and tied less closely
to an object.
The "Copy Vertex Groups to Linked" operator is removed, since they
are stored on the geometry anyway.
This patch leaves the object-level python API for vertex groups in
place. Creating a geometry-level RNA API can be a separate step;
the changes in this commit are invasive enough as it is.
Note that opening a file saved in 3.0 in an earlier version means
the vertex groups will not be available.
Differential Revision: https://developer.blender.org/D11689
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
|
|
Currently B-Bone scaling can only be controlled via their
properties, thus requiring up to 8 drivers per joint between
B-Bones to transfer scaling factors from the handle bone.
A Scale Easing option is added to multiply the easing value
by the Y scale channels to synchronize them - this produces a
natural scaling effect where both the shape of the curve and
the scale is affected.
In addition, four toggles are added for each handle, which
multiply each of the X, Y, Z and Ease values by the matching
Local Scale channel of the handle bone, thus replacing trivial
drivers. The Scale Easing option has no effect on this process
since it's easy to just enable both Length and Ease buttons.
Differential Revision: https://developer.blender.org/D9870
|
|
In addition to the base bone transformation itself, B-Bones have
controls that affect transformation of its segments. For rotation
the features are quite complete, allowing to both reorient the
Bezier handles via properties, and to control them using custom
handle bones. However for scaling there are two deficiencies.
First, there are only X and Y scale factors (actually X and Z),
while lengthwise all segments have the same scaling. The ease
option merely affects the shape of the curve, and does not cause
actual scaling.
Second, scaling can only be controlled via properties, thus
requiring up to 6 drivers per joint between B-Bones to transfer
scaling factors from the handle bone. This is very inefficient.
Finally, the Z channels are confusingly called Y.
This commit adds a B-Bone Y Scale channel and extra B-Bone flag
fields to DNA with appropriate versioning (including for F-Curves
and drivers) in preparation to addressing these limitations.
Functionality is not changed, so the new fields are not used
until the following commits.
Differential Revision: https://developer.blender.org/D9870
|
|
These were limited to obvious cases. Some less obvious cases
were kept as refactoring might make them necessary in future.
|
|
|
|
Also some clang-format changes.
|
|
Add translation/rotation/scale parameters for custom bones shapes. The
new scale is a 3D vector `custom_shape_scale_xyz`, and replaces the
`custom_shape_scale` float.
Reviewed By: #animation_rigging, sybren, zeddb
Differential Revision: https://developer.blender.org/D10974
|
|
Display the bone axes at the head (root) of the bone by default, instead
of the tail (tip), and add a slider so that it's possible to adjust this
position.
Versioning code is in place to ensure existing files behave the same
(axes shown at tail), whereas new Armatures will be using the new
default (axes shown at head).
Reviewed By: #animation_rigging, #user_interface, Severin, Sybren
Differential Revision: https://developer.blender.org/D7685
|
|
|
|
This partially reverts rBe922dd7d8a307c54d49bc01649a12610b022192b.
The issues fixed by that commit is still fixed.
Reviewers: fclem
|
|
Selecting an object by clicking on its instances only worked,
when the object itself is visible. However, it is possible to hide
the object and still keep the instances visible.
The solution is to give every object the correct `select_id` in the
depsgraph object iterator right before rendering.
Reviewers: fclem, brecht
Differential Revision: https://developer.blender.org/D9640
|
|
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
|
|
Following the most widely used convention for including todo's in
the code, that is: `TODO(name):`, `FIXME(name)` ... etc.
|
|
Some underlying functionality was not ready for greasepencil:
- BKE_modifiers_get_virtual_modifierlist (now introduce dedicated BKE_gpencil_modifiers_get_virtual_modifierlist)
- BKE_modifiers_is_deformed_by_armature
- checks in drawing code
- checks in (pose) selection code
A couple of changes to make this work:
- `eGpencilModifierType_Armature` has to be respected (not only `eModifierType_Armature`)
- `OB_MODE_WEIGHT_GPENCIL` has to be respected (not only `OB_MODE_WEIGHT_PAINT`) -- (now use new `OB_MODE_ALL_WEIGHT_PAINT`)
- `gpencil_weightmode_toggle_exec` now shares functionality from `wpaint_mode_toggle_exec` -- moved to new `ED_object_posemode_set_for_weight_paint`
This patch will also set the context member "weight_paint_object" for greasepencil (otherwise some appropriate pose operators wont work when in weightpaint mode)
Reviewed By: campbellbarton
Maniphest Tasks: T63125
Differential Revision: https://developer.blender.org/D8483
|
|
|
|
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/draw` module. Not all warnings are addressed
in this commit.
No functional changes.
|
|
This is to match the option name and to avoid confusion with
workbench xray mode.
|
|
This matches similar functionality for drawing lines.
|
|
Clang Tidy reported a couple of false positives. I disabled
those `NOLINTNEXTLINE`.
Differential Revision: https://developer.blender.org/D8199
|
|
This is a really small fix. Could be included in 2.83 LTS branch.
|
|
IK degrees of freedom is rendered using wires and a solid sphere. The
solid used the wireframe drawing what resulted into drawing glitches.
This patch adds a new shader to draw the solid shape.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8044
|
|
The memory leak is noticeable when using custom bone shapes. When using custom
bone shapes objects could be extracted twice. Where the second extraction can
overwrite data created by the first extraction what causes the memory leak.
Options that have been checked:
1. Use two task graphs phases. One for normal extraction (DST.task_graph) and
the other one will handle extractions that require blocking threads.
2. Keep a list of all objects that needs extraction and only start extraction
when all objects have been populated.
The second would slow performance as the extraction only happens when all
objects have been populated. In the future we might want to go for the second
option when we have the capability to render multiple viewports with a single
populate. As this design isn't clear this patch will implement the first
option.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D7969
|
|
|