| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds some useful debugging & profiling env vars to the Metal backend:
- `CYCLES_METAL_PROFILING`: output a per-kernel timing report at the end of the render
- `CYCLES_METAL_DEBUG`: enable per-dispatch tracing (very verbose)
- `CYCLES_DEBUG_METAL_CAPTURE_KERNEL`: enable programatic .gputrace capture for a specified kernel index
Here's an example of the timing report with `CYCLES_METAL_PROFILING` enabled:
```
---------------------------------------------------------------------------------------------------
Kernel name Total threads Dispatches Avg. T/D Time Time%
---------------------------------------------------------------------------------------------------
integrator_init_from_camera 657,407,232 161 4,083,274 0.24s 0.51%
integrator_intersect_closest 1,629,288,440 681 2,392,494 15.18s 32.12%
integrator_intersect_shadow 751,652,291 470 1,599,260 5.80s 12.28%
integrator_shade_background 304,612,074 263 1,158,220 1.16s 2.45%
integrator_shade_surface 1,159,764,041 676 1,715,627 20.57s 43.52%
integrator_shade_shadow 598,885,847 418 1,432,741 1.27s 2.69%
integrator_queued_paths_array 2,969,650,130 805 3,689,006 0.35s 0.74%
integrator_queued_shadow_paths_array 593,936,619 379 1,567,115 0.14s 0.29%
integrator_terminated_paths_array 22,205,417 155 143,260 0.05s 0.10%
integrator_sorted_paths_array 2,517,140,043 676 3,723,579 1.65s 3.50%
integrator_compact_paths_array 648,912,748 155 4,186,533 0.03s 0.07%
integrator_compact_states 20,872,687 155 134,662 0.14s 0.29%
integrator_terminated_shadow_paths_array 374,100,675 438 854,111 0.16s 0.33%
integrator_compact_shadow_paths_array 503,768,657 438 1,150,156 0.05s 0.10%
integrator_compact_shadow_states 37,664,941 202 186,460 0.23s 0.50%
integrator_reset 25,165,824 6 4,194,304 0.06s 0.12%
film_convert_combined_half_rgba 3,110,400 6 518,400 0.00s 0.01%
prefix_sum 676 676 1 0.19s 0.40%
---------------------------------------------------------------------------------------------------
6,760 47.27s 100.00%
---------------------------------------------------------------------------------------------------
```
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D15044
|
|
|
|
|
|
This avoid leaving a `GPUMaterial` in a `GPU_MAT_QUEUED` state which would
block rendering.
Fix T98603: Hang when saving project in material preview mode
Maniphest Tasks: T98603
Differential Revision: https://developer.blender.org/D15135
|
|
Good side effect of the change is that it makes it so that the
size of an array is more likely to be calculated at a compile time.
More ideally we'll be using bli::Array instead of the bare array,
but that is outside of the scope of this change.
|
|
NOTE: this patch originated in T98015 which was split into multiple
reports. While it could be split into multiple patches these are very
much related so keeping as one for now
This patch fixes the following issues:
[1] autokeying transforms in preview only creates keyframes if there is
an FCurve already
[2] autokeying transforms in preview only creates keyframes for
rotation/scale if rotating/scaling around cursor (should keyframe
position as well)
[3] autokeying transforms in preview does not work during animation
playback
For [1], a param was added to `ED_autokeyframe_property` which can tweak
its default behavior of only creating keyframes on already keyed
properties (which was fine because this is mostly called from buttons
where this behavior is desired). Callers such as gizmos (or the VSE in
our case) can use this additional param so that keyframes are also
created on "not-yet-keyframed" properties.
For [2], the pivot is checked and position properties also keyed if
necessary (which is also consistent with the way objects are keyed in
the 3DView)
For [3], `animrecord_check_state` was changed to be able to work on
scenes as well and the transform system in the VSE preview was made
aware of the screen's `animtimer`.
NOTE: there are still things to be improved for keyframing in the VSE,
the most obvious is probably a `keyframe_insert` operator (with
keyingsets)
Fixes T98429, T98430, T98431
Maniphest Tasks: T98015, T98431, T98430, T98429
Differential Revision: https://developer.blender.org/D15047
|
|
|
|
Patch changes label from '한국 언어' to '한국어'
Reviewed By: persun, PratikPB2123, mont29
Maniphest Tasks: T98527
Differential Revision: https://developer.blender.org/D15120
|
|
The previous fix [0] only resolved the issue for RMB select,
this works for the tweak tool with LMB select.
[0]: 0f73a27b76d789df04158905cba65dec0881bf12
|
|
To match the existing Python .obj importer, and to make it easier for
the user to determine which object is which, use the filename for the
default object name instead of "New object".
Differential Revision: https://developer.blender.org/D15133
|
|
|
|
|
|
|
|
|
|
Since [0], transform gizmos are no longer hidden during transform.
The same can be observed for rotation gizmos.
However, as a workaround for these rotation gizmos, there was already a
drawing utility running.
With the gizmo and the utility this drawing is now being done twice.
So remove the utility/workaround and update the gizmo accordingly.
[0] {648350e456490f8d6258e7de9bf94d3a6a34dbb2}
Differential Revision: https://developer.blender.org/D9542
|
|
- Use a context manager to handle file handlers (closing both in the
case of compressed files).
- Seek past BHead data instead of continually reading
(checking for 'REND').
- Write errors to the stderr (so callers can differentiate it from the
stdout).
- Use `surrogateescape` in the unlikely event of encoding errors
so the result is always a string (possible with files pre 2.4x).
- Remove '.blend' extension check as it excludes `.blend1` files
(we can assume the caller is passing in blend files).
- Define `__all__` to make it clear only one function is intended
to be used.
|
|
|
|
A new experimentatl STL importer, written in C++. Roughly 7-9x faster than the
Python based one.
Reviewed By: Aras Pranckevicius, Hans Goudey.
Differential Revision: https://developer.blender.org/D14941
|
|
A field input node for the scale of each top-level instance transform.
The scale can be set with the "Scale Instances" node, but previously
could not be retrieved.
Differential Revision: https://developer.blender.org/D15132
|
|
A field input node for the rotation of each top-level instance transform.
The rotation can be set with the "Rotate Instances" node, but previously
could not be retrieved.
Differential Revision: https://developer.blender.org/D15131
|
|
The original assert did not take into account the offset size in the loop being -1. The tests were then run in non-debug mode, so while the mesh regressions still passed, the false positive asserts that happened were not caught.
Differential Revision: https://developer.blender.org/D15136
|
|
The original assert did not take into account the offset size in the loop being -1. The tests were then run in non-debug mode, so while the mesh regressions still passed, the false positive asserts that happened were not caught.
Differential Revision: https://developer.blender.org/D15136
|
|
into enums
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
|
|
The issue was that the new span still referenced data that was potentially
stored in the old VArray_Span.
|
|
This error was introduced in 176d7bcc2eb47b9820861037f90a7fb26de8c9a0
Fix provided by @deadpin
|
|
Cop paste mistake from rB3cd283a424ec92ef85e1856d66f0baa4d2253fc5
|
|
- Adds python 3.10 support
- Slightly improves performance
|
|
Scaling handles while dragging could be distracting, especially at
extreme values where handles could become large on-screen.
Now all gizmos are shown while scaling.
GIZMO_GT_arrow_3d now now support changing their length while being
dragged as well as negative lengths.
|
|
|
|
Avoid the conversion to and from the old type, which could
be a substantial improvement in somce cases.
|
|
|
|
Curve attributes were allocated to the size of the point domain, which
wouldn't cause bad behavior, just potentially worse performance.
|
|
|
|
This allows the use of C++ data structures to simplify code and
improve performance.
|
|
The separate geometry and delete geometry nodes often invert the
selection so that deleting elements from a geometry can be implemented
as copying the opposite selection of elements. This should make the two
nodes faster in some cases, since the generic versions of selection
creation functions (i.e. from d3a1e9cbb92cca04e) are used instead
of the single threaded code that was used for this node.
The change also makes the deletion/separation code easier to
understand because it doesn't have to pass around the inversion.
|
|
This resolves a minor inconsistency displaying the scale gizmo handles
since they're cubes it's noticeable when they're not axes aligned.
|
|
When interacting with translate/rotate/scale gizmo, show the gizmo while
it's in use. There are some exceptions to this, as showing all scale
gizmos while scaling causes the gizmos to become large & distracting so
in this case only the gizmo being dragged is shown.
Resolves T63743.
|
|
Some operators OR'ed the existing flags in a way that made it seem
the value might already have some values set.
Replace this with assignment as no flags are set and the convention
with almost all operators is to write the value directly.
|
|
|
|
Also remove accidentally committed WIP commented code.
|
|
This implements the new way to attach curves to a mesh surface using
a uv map (based on the recent discussion in T95776).
The curves data block now not only stores a reference to the surface object
but also a name of a uv map on that object. Having a uv map is optional
for most operations, but it will be required later for animation (when the
curves are supposed to be deformed based on deformation of the surface).
The "Empty Hair" operator in the Add menu sets the uv map name automatically
if possible. It's possible to start working without a uv map and to attach the
curves to a uv map later on. It's also possible to reattach the curves to a new
uv map using the "Curves > Snap to Nearest Surface" operator in curves sculpt
mode.
Note, the implementation to do the reverse lookup from uv to a position on the
surface is trivial and inefficient now. A more efficient data structure will be
implemented separately soon.
Differential Revision: https://developer.blender.org/D15125
|
|
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
|
|
Shifted flag for buttons changed was incorrectly compared with
unshifted packet flag to determine button press state.
Also fix button tracking storage; button flags are 32 bits whereas the
member variable was 8.
Differential Revision: https://developer.blender.org/D14915
|
|
|
|
|
|
The code that checked whether vertex normals needed to be recalculated
was checking the dirty tag for face normals and vertex normals, in an
attempt at increased safety. However, those tags are always set
together anyway. Only checking the vertex dirty tag allows potentially
allocating or updating the normals on the two domains independently,
which could allow further skipping of calculations in some cases.
|
|
|
|
|
