- Paste flipped created invalid paths when the size of the name changed
left -> right: lost the 't' in right.
right -> left: lost the entire end of the RNA path.
- Correct the fixed buffer size as it may include escaped characters.
Some modifiers used `MOD_deform_mesh_eval_get` to make sure they had
a mesh to retrieve vertex groups from. But since curves don't support
vertex groups anyway, and since the curve to mesh conversion is handled
by the (legacy) curve object modifier stack anyway, this is confusing
and unnecessary. This shouldn't give any behavior changes, but some
deform modifiers on legacy curve objects might be faster if they used
to do the conversion.
This commit simplifies the "Extrude" menu layout code.
This should make future modifications and maintenance easier.
Refs:
33b1cbf06d46b0e90cf6db4a205fa0
This limitation was added to avoid conflicts with tools.
But since we now have the "allow_navigation" option on transform
operators, there is no real benefit to having this limitation.
No functional changes from user's point of view.
"Shrink/Fatten" is used in macros for some extrude operations.
These operations may rely on the type of mesh selection.
While some of these operations are combined with the "Move" function,
which already permits navigation, others are combined with
"Shrink/Fatten", which currently lacks navigation capabilities.
To ensure consistency and enable navigation in all extrude operations,
this commit introduces the option to enable navigation for the
"Shrink/Fatten" operator.
Fix a mistake in commit 2ce5fc4a3e that caused a crash when detaching
node links from input sockets.
When a link is detached from an input socket, `nodeRemLink` nulls the
`link` pointer of the socket.
So before the next update inputs are linked but don't have a valid `link`
pointer causing the crash, when trying to access the link in
`std_node_socket_draw`.
The introduced check avoids the crash and is more correct since it
doesn't just check one link for multi-input sockets.
Pull Request: https://projects.blender.org/blender/blender/pulls/108623
- "Invalid" in transformation messages.
- For three messages, translation occured after a string
- concatenation, so the full message was not found.
Instead, translate a format pattern and format it afterwards.
- Alembic errors when there is an import type mismatch.
Pull Request: https://projects.blender.org/blender/blender/pulls/108212
Code was plainfully buggy, early-out check in
`BKE_undosys_stack_limit_steps_and_memory` was plainfully wrong.
Also added some more logging for memory limiting code.
This commit affects:
* Reading undo steps from memfile (aka 'Global Undo');
* Handling of UI IDs (WindowManager, Workspaces and Screens) when
opening a .blend file.
While no major changes are expected from a user PoV, there may be some
unexpected changes in rare edge-cases. None has been identified so far.
Undo step loading should be marginally faster (`setup_app_data` itself
is 2-3 times faster, as it does not do remapping anymore, which makes the
whole 'read undo step' process about 20% faster - but the most
time-consuming step on undo is the depsgraph processing, which remains
unchanged here).
This commit also solves some bugs (crashes) in some relatively uncommon
cases, like e.g. if the WM had an IDProperty pointing at an object and
UI is not loaded when opening a new .blend file with the 'Load UI' option
enabled (as in previous code on file opening WM ID would never be
remapped).
From a more technical side, this commit aims mainly at cleaning things
up, in preparation for the introduction of new 'no undo, no readfile'
type of handling (as part of the Brush Assets project):
- Prevent WM code from doing (too much) horrible ID 'management' on
its WM when opening a new file. It used to remove current WM from
the Main database, store it in a temporary own list, and then free
it itself...
- Trying to make the complex logic behind WM handling on file reading a
bit more easy to follow, at least way more documented in code.
- Keep the handling of 'IDs being re-used from old Main' in a single
place, as much as possible:
-- Readfile code itself in undo case (because it's more efficient,
and undo case is in a way simpler than actual .blend file
reading case). The whole `blo_lib_link_restore` block of code
is also removed.
-- (Mostly) setup_app_data code in actual file reading case.
- Sanitize the usage of the 'libmap' in readfile code in undo case
(waaaaay too many pointers were added there, which was hiding some
other issues in the related code, and potentially causing (in
rare cases) memory addresses collisions.
Pull Request: https://projects.blender.org/blender/blender/pulls/108016
C-style callbacks often rely on `void` pointer arguments that are unsafe
because of the removed type. C++ functors allow passing arbitrary data
along the callback, plus convenient features like defining the callback
using a lambda.
Didn't port the `typedef` because it doesn't add much in this case, just
hides the type from the reader who has to look it up first.
Note that this function isn't used in the main branch currently.
This PR silences console output during statup phase of blender. During
startup logging isn't yet initialized and print statements where used.
Logging is initialized during the first construction of a Metal Context.
The console prints are now hidden by behind the '--debug-gpu' command
line option.
Pull Request: https://projects.blender.org/blender/blender/pulls/108593
- DRW_draw_region_engine_info:
- Remove duplicate line drawing for the last line.
- Remove string copying, pass the length to BLF_draw_default instead.
- Resolve a potential buffer overflow as the source string length was
used to define the destinations maximum size.
- CONSOLE_OT_paste:
- Remove the need to null-terminate each line.
- Buffer stepping uses const values
- console_line_insert no longer strips the string it inserts.
- CONSOLE_OT_insert:
- New lines in the middle of text now reports an error,
new lines at the end of text is stripped (as before).
Returning the pointer to the null byte when the character isn't found
is useful when handling null terminated strings that contain newlines.
This means the return value is never null and the line span always ends
at the resulting value.
While the multiscattering GGX code is cool and solves the darkening problem at higher roughnesses, it's also currently buggy, hard to maintain and often impractical to use due to the higher noise and render time.
In practice, though, having the exact correct directional distribution is not that important as long as the overall albedo is correct and we a) don't get the darkening effect and b) do get the saturation effect at higher roughnesses.
This can simply be achieved by adding a second lobe (https://blog.selfshadow.com/publications/s2017-shading-course/imageworks/s2017_pbs_imageworks_slides_v2.pdf) or scaling the single-scattering GGX lobe (https://blog.selfshadow.com/publications/turquin/ms_comp_final.pdf). Both approaches require the same precomputation and produce outputs of comparable quality, so I went for the simple albedo scaling since it's easier to implement and more efficient.
Overall, the results are pretty good: All scenarios that I tested (Glossy BSDF, Glass BSDF, Principled BSDF with metallic or transmissive = 1) pass the white furnace test (a material with pure-white color in front of a pure-white background should be indistinguishable from the background if it preserves energy), and the overall albedo for non-white materials matches that produced by the real multi-scattering code (with the expected saturation increase as the roughness increases).
In order to produce the precomputed tables, the PR also includes a utility that computes them. This is not built by default, since there's no reason for a user to run it (it only makes sense for documentation/reproducibility purposes and when making changes to the microfacet models).
Pull Request: https://projects.blender.org/blender/blender/pulls/107958
Produce optimal layouts for `n` squares, where n == 11, 18, 19 and 26.
With thanks:
* Walter Trump
* Pertti Hamalainen
* Robert Wainwright
* Erich Friedman
The additional SocktType::VECTOR argument was being interpreted as flags,
which caused the OSL compiler to skip the input (since the Vector type enum
happens to align with the INTERNAL flag), which caused the OSL shader to
always use the hardcoded default absorption regardless of what was entered.
