Solves the issue of the script potentially sitting for a long time
without having any progress reported. Confusingly, such behavior
depends on Git version.
In older versions (< 2.33) there will be progress reported, but it
then got changed by the commit in Git:
7a132c628e
The delayed checkout is exactly how Git LFS integrates into the Git
process. Another affecting factor for the behavior is that submodule
configured to use "checkout" update policy is forced to have quite
flag passed to the "git checkout":
https://github.com/git/git/blob/v2.43.2/builtin/submodule--helper.c#L2258
This is done to avoid the long message at the end of checkout about
the detached state of HEAD, with instructions how to resolve that.
There are two possible solutions: either use "rebase" update policy
for submodules, or skip Git LFS download during the submodule update.
Changing the update policy is possible, but it needs to be done with
a bit of care, and possible revised process for updating/merging
tests data.
This change follows the second idea of delaying LFS download for a
later step, so the process is the following:
- Run `git submodule update`, but tell Git LFS to not resolve the links
by using GIT_LFS_SKIP_SMUDGE=1 environment variable.
- Run `git lfs pull` for the submodule, to resolve the links.
Doing so bypasses hardcoded silencing in the Git. It also potentially
allows to recover from an aborted download process.
The `git lfs pull` seems to be a nominal step to resolve the LFS links
after the smudging has been skipped. It is also how in earlier Git
versions some Windows limitations were bypassed:
https://www.mankier.com/7/git-lfs-faq
The submodule update now also receives the "--progress" flag, which
logs the initial Git repository checkout process, which further
improves the feedback.
The byproduct of this change is that an error during precompiled
libraries and tests data update is not considered to be fatal.
It seems to be more fitting with other update steps, and allows
more easily reuse some code.
There is also a cosmetic change: the messages at the end of the
update process now have their own header, allowing more easily
see them in the wall-of-text.
Pull Request: https://projects.blender.org/blender/blender/pulls/118673
Oversight in e3d31b8dfbdc
While most situations would have other vertexgroups set anyways (so this
probably wasnt noticed, it was only ignored if it is the only
vertexgroup used), at least theoretically it could happen that
`cloth_uses_vgroup` would return false even then `vgroup_shear` is set
(thus skipping actually setting these weights later).
area light with zero spread was introduced in bf18032977. Such paths can
only be sampled with NEE, so MIS should not be used.
This fixes the discrepancy when Direct Light Sampling is set to MIS or NEE.
Pull Request: #118584
Likewise, skip tests update when --use-tests is not provided.
It was a bit of ambiguous situation because libraries and tests
are technically submodules. After some feedback it seems that it
is better to ignore submodule for libraries and tests unless
requested explicitly.
Pull Request: https://projects.blender.org/blender/blender/pulls/118631
Caused by 0a633a4e07
NLA and driver tree-elements were not added to the outliner when
"action" is unlinked from the object. This is due to the wrong `if`
condition preventing the excution of `expand_drivers/expand_NLA_tracks`.
Pull Request: https://projects.blender.org/blender/blender/pulls/118597
Originally caused by 90c4e2e6ec [which did not translate the tooltip
descriptions for enum items at all]
That was fixed in cbc5d861db [which was working fine for the default
translation context -- which is most of the time]
Now 7d7318f6c59c added the `BLT_I18NCONTEXT_ID_ID` translation context
to `buttons_context_items` (rightfully so) but using this context on the
enum item **description** translation does not really make sense. So as
a result, the description was not translated in this case.
To resolve, now dont use a special translation context for the
**description** of enum items at all, this is also what
`property_enum_translate` does.
Pull Request: https://projects.blender.org/blender/blender/pulls/118653
Since `IDOverrideLibraryProperty` apparently stores its rna_path with
string-based collection keys, we have to make sure we also use string-
based keys elsewhere in `OverrideRNAPathTreeBuilder::build_path` and
down the line, otherwise:
- we get duplicate collection entries ("pose.bones[1].constraints" vs.
"pose.bones["Bone.001"].constraints")
- crashes may occur (we are reading on an already freed `TreeElement`
see #118307 for ASAN output)
So now make sure we are using string-based collection keys when we can
so the TreeElements match /and dont get duplicated).
NOTE: the duplication of entries came with 67b92418ee
Pull Request: https://projects.blender.org/blender/blender/pulls/118573
git on windows is giving no status updates while git lfs
is downloading the libs, causing people to assume its
stuck and interrupt the download. This change adds a
rather large visual message telling people not to do
that.
also it was not respecting people selecting n on the lib
download so some extra messaging has been added there
as well.
So far, when deleting a library (either explicitely, or through e.g.
relocation), its dependencies would get a `nullptr` parent, and
therefore become 'directly used' libraries.
This commit adds a new util to rebuild the libraries hieararchy, and
calls it when a Library ID is deleted.
NOTE: While logic is somewhat similar to what liboverride resync does to
sort the libraries by indirect levels
(`lib_override_libraries_index_define`), there are some key differences
here, notably the fact that if a library has a valid `parent` pointer,
it is not replaced, even if a 'better' parent (less indirect library)
could be found.
Git escaped a quote and used all of the cli arguments as the
folder name.
Also fixes:
- Progress on the initial clone so it doesn't appear stuck
- re-detect python after updating libs, so you don't have to run
make update twice on a fresh clone.
- Hide python not found warning unless the lib folder exists (this
seemingly got lost in one of the merges)
If LFS hooks are installed manually the automatic installation would
fail.
This change makes it so `lfs` is a valid command of `git`, ensuring
that the package is installed. If the installation fails assume it
is due to tricky local setup, and do not fail.
Pull Request: https://projects.blender.org/blender/blender/pulls/118618
The issue described was that the motion path didn't display the last frame
of a scene.
This PR makes the user facing motion path range inclusive on both ends.
E.g. when the user specifies a motion path from 1-24 the will now get all 24
frames, whereas previously the motion path would end at frame 23.
This also makes the `Scene Frame Range` option work properly since that
had the same issue. Now it displays the actual full scene range.
Internally, the `bMotionPath` is still exclusive on the upper bound.
It is just the `bAnimVizSettings` range that has been modified.
Pull Request: https://projects.blender.org/blender/blender/pulls/118611
- git lfs install was called a bit too late, after the libraries
has been checked out, leaving the checkout in a non-resolved
state.
- Update blender code first, allowing proper submodule hash to
be pulled.
Pull Request: https://projects.blender.org/blender/blender/pulls/118615
Rewrite the code so that users get an error message when trying to
rename something to an existing file in the file browser. Before this
change Blender would not print any notifications on why the rename
failed if a file with the same name already existed.
Pull Request: https://projects.blender.org/blender/blender/pulls/118571
Not all filesystems on linux supports the RENAME_NOREPLACE flag.
If we get a EINVAL return value, retry with a non atomic operation.
RENAME_NOREPLACE was introduced in 050d48edfc, so this is a regression
fix as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/118571
This change makes it so build system and update utilities for Blender builds
are using pre-compiled libraries and other resources attached as Git modules
instead of using checkout of SVN repositories in the parent folder.
The directory layout:
```
* release/datafiles/
* assets/ -> blender-assets.git
* publish/
* ...
* README.txt
* lib/
* darwin_x64/ -> lib-darwin_x64.git
* darwin_arm64/ -> lib-darwin_arm64.git
* linux_x64/ -> lib-linux_x64.git
* windows_x64/ -> lib-windows_x64.git
* tests/
* data/ -> blender-test-data.git
```
The changes about configuring the actual Git sub-modules are not included
into this patch, as those require repository to actually exist before it
can be used.
The assets submodule is enabled by default, and the rest of them are
disabled. This means that if someone runs `git submodule update --init`
they will not get heavy libraries. The platform-specific and tests
related submodules are enabled when using `make update` or `make test`.
All the submodules are tracked: this means that when new commits are
done to the submodule, the blender.git repository is to be updated to
point them to the new hash. This causes some extra manual work, but it
allows to more easily update Blender and its dependencies to known good
state when performing operations like bisect.
Ref #108978
Pull Request: https://projects.blender.org/blender/blender/pulls/117946
if emission sampling is not set, we do not use MIS weight when sampling
from the BSDF, but we were still drawing samples from the light,
resulting in double contribution.
Pull Request: https://projects.blender.org/blender/blender/pulls/118534
The issue here is that the `parent` pointer of indirectly linked
libraries would not be propoerly cleared when their current parent was
deleted.
Note that this fix will leave effectively indirectly linked libraries
shown as directly used ones in the UI, until the blendfile is saved and
reloaded. This is not a new issue though, deleting a parent library in
the Outliner has the same effect.
This `operator new` added in ecc3e78d787cce8a3f202e7de26575e2d47baea2
are only called if the alignment is greater than `__STDCPP_DEFAULT_NEW_ALIGNMENT__`.
This is generally 8 or 16 depending on the platform. `MEM_mallocN` does
guarantee 16 byte alignment currently (in fact it's usually not 16 byte aligned
because of `MemHead`). Now `MEM_mallocN_aligned` is used with the default
alignment, even if we don't know that the type does not require it.
An alternative would be to pass the alignment to `MEM_CXX_CLASS_ALLOC_FUNCS`,
but that would be more intrusive.
Pull Request: https://projects.blender.org/blender/blender/pulls/118568
This addresses issue #93052.
Now converting the USD "varying" interpolation type to
the "point" domain type when importing USD attributes.
There have been some inconsistent opinions in the USD
developer community about whether "varying" interpolation
is equivalent to "corner" or "point" domains for meshes.
However, DCCs such as Unity and Houdini assume that the
number of entries for attributes with "varying" interpolation
is the same as the number of points, and this change allows
Blender to import such assets without error.
Pull Request: https://projects.blender.org/blender/blender/pulls/118539
