Blender Git Commit Log

cleanup

typo

Fix T72729: Mask Modifier Loose Edges Not Shown

When using the mask modifier loose edges could be added to the mesh.
These edges weren't marked as loose edges and wasn't picked up by other
areas of blender.

This fix recalculates the loose edges so they have the correct flag
`ME_LOOSE_EDGE`.

Reviewed By: Sybren St�vel

Differential Revision: https://developer.blender.org/D7766

Fix T76865: Vertex paint draws hidden but cannot be painted onto

CMake: Enable WITH_USD by default

Having USD disabled by default was an oversight, and could have been
corrected earlier. It's already enabled by default in the
`blender_release.cmake` and `blender_full.cmake`.

Fix T76689: Armature layers not indicating the existence of bones

From what I can see, there are two issues at play in {T76689} and its merged-in report {T76590}:

- In Blender ? 2.79 the bone layer dots were updated in the draw code. This ensured the info was up to date before drawing. This is no longer possible, as the drawing code uses evaluated objects, and those should not be written to. This has been addressed in rB709f126e8143 by calling the update function explicitly in various places in the code. The problem is that this wasn't added to all necessary spots.
- When in edit mode, changes are made to the edit bones but not to the 'actual' bones (this is synced when exiting edit mode). This causes undo to mess up the layer indicators.

I think both issues can be addressed by having the dependency graph update the used layer info as part of the armature evaluation. This will make the undo system work properly, and allows the removal of some `BKE_armature_refresh_layer_used()` from various places.

There is still the issue that there are two functions (`BKE_armature_refresh_layer_used()` and `ED_armature_edit_refresh_layer_used()`) that are both responsible for updating `bArmature::layer_used`. This is a trickier thing to solve, though, as the definition of the `EditBone` struct resides in the armature editor module. This means that blenkernel can't iterate over edit bones, but on the other hand the dependency graph shouldn't call any editor functions either. This is why I left the `ED_armature_edit_refresh_layer_used()` calls untouched.

The downside of recalculating `layer_used` from the dependency graph (at least in the way that I did it now) is that it is called every time a user moves a bone in pose mode. This frequency of updates is not necessary.

Differential Revision: https://developer.blender.org/D7709

Fix T76780: Freestyle pass for one scene not accessible in compositor in other scenes

Current implementation would update the nodetree of the freestyle scene not the composite scene.

Reviewed By: Dalai Felinto

Differential Revision: https://developer.blender.org/D7770

Fix T73169: Side by Side Stereo Rendering Glitches

Side by side and top down views were rendered using an unset matrix.
This fix will reset the matrix just before copying the views to the
screen.

Reviewed By: Cl�ment Foucault, Dalai Felinto

Differential Revision: https://developer.blender.org/D7777

Cleanup: Creator Args Spelling

Differential Revision: https://developer.blender.org/D7735

Fix T76821: Generalize Use Flow Tooltip

Merge branch 'blender-v2.83-release'

Merge branch 'blender-v2.83-release'

Fix switching to particle edit-mode from editmode

Similar to T76859

Fix T76859: Cannot switch from editmode to texturepaint mode

Caused by 5159b8e1eadb.

Merge branch 'blender-v2.83-release'

Fix sculpt mask interpolation in subdivisions

The interpolation function of the datalayer was misssing so the sculpt
mask data was corrupted every time a subdivision surface modifier was
applied.

Reviewed By: jbakker

Differential Revision: https://developer.blender.org/D7640

Merge branch 'blender-v2.83-release'

Fix T76397: Missing value property on Clear Mask pie menu

Without this value defined it was reusing the same 1.0 value after using
fill mask, so it was not working.

Reviewed By: jbakker

Maniphest Tasks: T76397

Differential Revision: https://developer.blender.org/D7699

Merge remote-tracking branch 'origin/blender-v2.83-release'

Fix: T71040 / T58983 Ocean Modifier crashes at high resolutions

This is not as much a fix as a work around, but given the real
involves replacing how we build fftw, it is not eligible for 2.83
which is in BCON3 already.

The root of the issue lies with (how we build) fftw3

The first issue is: fftw does not build with MSVC, there are other
dependencies that are not compatible with MSVC and for those we
build the libraries required with mingw64, same for fftw

The second issue is: for reasons unknown we really really really
liked all deps to link statically so wherever possible we did so.

Now during the building of the fftw it linked a few symbols from
libgcc (which we do not ship) like __chkstk_ms, for which we passed
some flags to stop generating calls to it. Problem solved! There
is no way this could possibly turn around and bite us in the rear.

fast forward to today mystery crashes that look like a race condition.

What is happening is, we tell the linker that each thread will require
a 2-megabyte stack, now if every thread immediately allocated 2 megs,
that be 'rough' on the memory usage. So, what happens is (for all apps
not just blender), 2 megs are reserved but not backed by any real memory
and the first page is allocated for use by the stack, now as the stack
grows, it will eventually grow out of that first page, and end up in
an area that has not been allocated yet, to deal with that the allocated
page is followed by a guard page, someone touches the guard page it's
time to grow the stack!

Meanwhile in FFTW is it's doing substantial allocation using alloca
(up to 64 kb) on the stack, jumping over the guard page, and ending
up in reserved but not yet committed memory, causing an access violation.

Now if you think, that doesn't sound right! something should have
protected us from that! You are correct! That thing was __chkstk_ms
which we disabled.

Given we do not want a dependency on libgcc while building with MSVC
the proper solution is to build fftw as a shared library which will
statically link any bits and pieces it needs, however that change
is a little bit too big to be doing in BCON3.

So as a work around, we change the size the stack grows from 8k to
68k which gives fftw a little bit more wiggle room to keep it out
of trouble most of the time.

Note this only sidesteps the issue, this may come up again if the
conditions are just right, and a proper solution will need to be
implemented for 2.90.