The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136126
The PR allows specifying the method of line breaking. Current functions
gain an optional argument that defaults to "Minimal" which breaks as it
does now, only on space and line feed. "Typographical" breaks on
different types of spaces, backslashes, underscore, forward slash if
not following a number, dashes if not following a space, Chinese,
Japanese, and Korean Ideograms, and Tibetan intersyllabic marks. "Path"
breaks on space, underscore, and per-platform path separators. There is
also a "HardLimit" flag that forces breaking at character boundary at
the wrapping limit.
Pull Request: https://projects.blender.org/blender/blender/pulls/135203
Regular "Save As" does not set "incremental" property, either true or
false, which results in a warning message. This PR just handles the
reading of this optional property properly by checking existence first.
Pull Request: https://projects.blender.org/blender/blender/pulls/136127
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136121
Use a default case for blur type switch case, that's because adding all
types is not necessary, and I am trying to differentiate between switch
cases that need full type enumeration and those that do not.
Currently there is no python api function to assign/remove vertices to specific
vertex group. Traditional `object.vertex_groups[0].add/rna_VertexGroup_vertex_add`
didn't work, because Grease Pencil stores deform verts and vertex group
on individual drawings. Now intorduced a new function
`vertex_group_assign` and `vertex_group_remove` on `Drawing`.
Resolves#135281.
Resolves#134678.
Example (just add GP Suzanne):
```
import bpy
C = bpy.context
drawing = C.active_object.data.layers['Lines'].current_frame().drawing
drawing.vertex_group_assign(vgroup_name="Group", indices_ptr=[2, 6, 10, 18, 19, 20], weight = 0.9)
drawing.vertex_group_remove(vgroup_name="Group", indices_ptr=[2, 6, 10])
```
Pull Request: https://projects.blender.org/blender/blender/pulls/135283
This patch formalizes the process of data updates of single values.
Previously, this was done internally in the set_single_value method, but
there was a hack in multi-function procedure code to do the same. This
patch adds a new method for single value data updates and uses it
internally in set_single_value.
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136118
Since 40eadc75be, `ED_workspace_status_text` is now called at the
beginning of the modal function.
This clears any custom keymap and redraws the status bar.
The `Edge Slide` and `Shear` operations only update the status bar if a
modal key is pressed (not on mouse move).
The solution to avoid losing custom modal keys, and not having to
update the status bar more often is: call `ED_workspace_status_text`
only when an operation that requires redraw is performed.
Pull Request: https://projects.blender.org/blender/blender/pulls/136101
This reverts commit b02c83386b.
The problem has not been fully resolved (there is a glitch in the
status bar when changing operations).
A newer, even more efficient solution is on the way.
Using the knife tool with Vulkan failed because using
GPU_PRIM_POINTS isn't supported with the GPU_SHADER_3D_UNIFORM_COLOR
shader.
Resolve using a shader intended for drawing points.
Ref !136109
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136116
When swap chain is updated the logic could select an incorrect
framebuffer. This isn't actually the case during normal usage, but has
been detected during the development of OpenXR support. Here it did
matter.
Pull Request: https://projects.blender.org/blender/blender/pulls/136115
Commit e9a21cf14c seems to have removed a bit too many includes, this
reverts one change, which seems to be enough to get it working again.
Will let @deadpin decide whether we keep this 'include all' header
include here, or go more refined in our includes.
This patch refactors how values of unlinked sockets are provided to
nodes. Previously, the GPU node stack values were initialized at
construction time and linked by the node's compile methods. This meant
that we needed to handle implicit conversion if the socket is linked to
an unlinked node group input.
Alternatively, we now insert a GPU setter node for each unlinked socket
that carries the value and type of the origin socket, and let the GPU
code generator do implicit conversion at the shader level. This has
three advantages:
- It makes it easier to add new types since we no longer have to handle
those types in shader node code and it reduces code duplication.
- It makes the code more inline with how we implement multi-function
procedures. So refactoring is easier.
- It opens the door to implement things like implicit inputs, which will
be needed later for things like texture nodes.
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136095
Previous code would consider two different face groups sharing no common
edges as fully isolated from each other, and could assign them the same
bitflag facegroup value.
Following FBX recent option to export these bitflags smoothgroups (!135646),
also consider that two different face groups are connected if they only share
common vertices, and assign them different bitflags values.
NOTE: This seems to be the expected behavior in major DCCs actually
using smoothgroups, only considering boundary edges create groups that
generate broken shading when imported by these tools.
NOTE: The 'unique integer identifers' option is kept for OBJ exporter,
as such OBJ files are also found on internet, depending on which app
generated them.
Pull Request: https://projects.blender.org/blender/blender/pulls/135998
- Use const in more places
- Use more appropriate headers and forward decls elsewhere
- Remove one instance of variable shadowing
- Rename an internal rna enum list and the USD operator property object
to follow surrounding code and naming guidelines
Pull Request: https://projects.blender.org/blender/blender/pulls/136112
This seems to be remains of code from time when sound offsets were
clamped to non negative values and start/endstill offsets were used to
offset strip handles from sound content.
Since start/endstill offsets were merged with start/endofs, this limit
should have been removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/136015
Using clang-tidy "cppcoreguidelines-pro-type-cstyle-cast" to find them.
This PR touches `bf_animrig` & `bf_editor_animation` & `bf_editor_armature`
NOTE: Also some case where untouched (not straightforward) same as
expanded macros (e.g. `LISTBASE` or `GS`)
NOTE: a couple of cases of "inconsistent-declaration-parameter" as well
Pull Request: https://projects.blender.org/blender/blender/pulls/136044
The `pxr::VtArray<T>` type is based on a copy-on-write scheme that is
very easy to trigger unnecessarily because of how the C++ type system
works[1].
Here we bypass unneeded copies by ensuring we always call the `const`
version of various accessor functions. The offending call-sites were
found by using the `VT_LOG_STACK_ON_ARRAY_DETACH_COPY` env variable.
This yields a very small 2-3% performance benefit when loading in a
typical, mixed-use, asset like e.g. the "4004 Moore Lane" scene.
[1] https://github.com/PixarAnimationStudios/OpenUSD/blob/dev/pxr/base/vt/array.h#L139
Pull Request: https://projects.blender.org/blender/blender/pulls/136014
To fix this in the most non-intrusive way, we essentially do what
the modifiers do which is to convert everything to poly curves.
This is also what GPv2 used to do.
Ideally, we would export non-poly curves as bézier curves in the
supported SVG format.
Pull Request: https://projects.blender.org/blender/blender/pulls/136088
This reduces the API and make it more clear where there
is the global access.
This also removes some of these global access by merging
the `DRW_context_get()` calls.
When a input event is handled but `status.opmodal` is not explicitly
requested, `WM_window_modal_keymap_status_draw` will override the status
bar message, then the tool hint would be incorrect. This applies to
shear and edge slide operators. Seemingly introduced by 6d5d3ce. The
fix is to not ignore mouse move event when updating status bar as they
also causes viewport redraw.
Pull Request: https://projects.blender.org/blender/blender/pulls/136063
The import nodes are considered complete enough to expose without
the experimental option. This commit removes the option so they will
be exposed in 4.5. There are still some possible future improvements,
including automatic caching, possibly exposing more input sockets,
and possibly including imported paths in the "Internal Dependencies"
panel. Those are considered non blocking though.
Pull Request: https://projects.blender.org/blender/blender/pulls/135957
This is just the shader change.
It allows more freedom for the UI team to tweak the appearance.
The is not functional changes in this patch.
Rel #126334
Blender crashes when canceling a compositor job if a transform node is
used. This is because freeing shared data didn't reset data members, so
it still thinks it has allocated data, which will be double freed
causing crashes. To fix this, we simply clear data members if data is
still shared.
Fix the `ANIMDATA_FILTER_CASES` macro, so that layered/slotted Actions
no longer take precedence over NLA control curves. Now they're handled
with the same priority as legacy Actions were.
Pull Request: https://projects.blender.org/blender/blender/pulls/136072
Fix the `ANIMDATA_FILTER_CASES` macro, so that layered/slotted Actions
no longer take precedence over NLA control curves. Now they're handled
with the same priority as legacy Actions were.
Pull Request: https://projects.blender.org/blender/blender/pulls/136072
Don't attempt to add region draw callbacks in background mode.
This caused by the regions runtime being null.
Even if the runtime was initialized, drawing callbacks aren't needed
in background mode.
Ref !136078
