This PR removes a bunch of dead code following #123551 (removal of AMD and Intel GPU support). It is safe to assume that UMA will be available, so a lot of codepaths that dealt with copying between CPU and GPU are now just clutter.
Pull Request: https://projects.blender.org/blender/blender/pulls/136117
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
Part of #134755 / #134766.
Replaces the current import method menu in the middle of the Asset
Browser header with a "Import Settings" popover. The import method is
located there now, because it doesn't need to be as prominent as it used
to be, especially with #104686.
Plan is to add further settings to this popover, e.g. see #135996 or
#134943.
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
There is code that properly handles panoramic cameras in
`camera_world_to_ndc`, the transform matrices (e.g.
`OSLRenderServices::get_inverse_matrix`) in the `transform("NDC", P)`
call dont do the "full work" here (maybe they should though?).
But we can get to `camera_world_to_ndc` by just getting the "NDC"
attribute, so use that for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/136097
Before this patch, Video Output using FFmpeg video
display lot of parameters.
But some of theses have a meaning only for some codec
(mainly lossy gop codecs : H264, H265, AV1...)
Hide not useful parameters for codec :
'DNXHD', 'FFV1', 'HUFFYUV', 'PNG', 'QTRLE'
- DNXHD : intra frame codec, encoding setting depends of a profile
- FFV1/QTRLE : Intra or P frames only. Lossless codec
- HUFFYUV/PNG : Intra lossless codec
Co-authored-by: mvji <33432858+mvji@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/135827
- 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
With the HIPRT backend for Cycles, rays can end up hitting the same
triangle multiple times due to a issue in the spatial splitting
algorithm.
Most of the time this issue isn't visible, but it is quite obvious in
semi-transparent shadows of meshes.
So this commit adds a file that contains a object made up of many
semi-transparent rectangular prisms casting a shadow onto the a plane.
Ref: blender/blender#117527
Ref: blender/blender-test-data!76
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.
The platform tag came from virtualized CPU on which Python 3.9 is
running on the buildbot.
Use the same trick to detect the host CPU as for the message on the
splash screen.
Pull Request: https://projects.blender.org/blender/blender/pulls/136085
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
