When showing UV edges after modifiers [draw_uvs_shadow], these were never
drawn anti-aliased [in contrast to the 'main' UVs].
Also: they did not respect the new 'UV Opacity' setting.
Differential Revision: https://developer.blender.org/D7764
The issue was that we used GL_ALWAYS for depth checking here which would
lead to the depth information from objects being messed up.
It would not represent which object was closest to the camera.
Reviewed By: Clément Foucault, Jeroen Bakker, Campbell Barton
Differential Revision: http://developer.blender.org/D7710
Previously the playback mode "Frame Dropping" would not drop the correct
number of frames which would lead to slow playback.
For example, the playback target is 60fps. However we can only muster
around 32 fps.
The delta frames from the last step is in this case ~1.98 or so.
With the previous code, we would floor this. That would lead us to step
forward one frame each time, effectively playing back the animation at
half the speed as we will try to render every frame.
To fix this we simply save the remaining fraction from the previous
frame and use it to compute the current frame step.
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D7694
A follow up to T67212. I missed that the rotation interpolation had its
own code path.
The previous rotation push code was actually wrong (but smooth).
Now all of the actions behave correctly and is smoothly interpolated.
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
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`.
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
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
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
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
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
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.
When the number of triangles in a node became zero, the wireframe batch was
not freed along with the triangles batch and could still reference a freed
vertex buffer.
Ref T76858
Bug was actually in outliner code, paste operator would not generate any
undo step...
This was not correct ever, but with new undo code this has become a
critical issue, it cannot survive a situation where current main data
has been changed without a proper undo push.
This illustrates again how much of a catastrophic mess the 'tools'
callbacks of the outliner are currently, it has already caused us quiet
some pain in the past, and will keep doing so until this is fully
sanitized am afraid.
Would strongly suggest getting rid of thosw nasty mix of custom
callbacks requiring manual undo pushes, I do not see the added value of
this compared to regular menus calling regular operators. It only adds
confusion and extra code for nothing...
Issue is that update functions defined in
`rna_def_fmodifier_envelope_ctrl` (namely `rna_FModifier_update`) are
actually never called.
This is because UI code for FCurve modifiers often does not use RNA
buttons but uses custom update functions (or non at all). For example,
rB9a88bd55903a did this for the generators, envelope control points did
not have this at all.
This is now changed to use RNA buttons for the envelope control points,
this could done for other non-RNA buttons as well to get rid of
'validate_fmodifier_cb()'.
Maniphest Tasks: T76734
Differential Revision: https://developer.blender.org/D7732
settings
Stabilized ImBuf just needs to use the same colorspace and alpha
settings as the original one.
Maniphest Tasks: T76698
Differential Revision: https://developer.blender.org/D7713
This patch fixes T76277 by removing the incorrect cast from
`ptr->data` to `bNode`. The address of `ptr->owner_id` and
`ptr->data` both point to the node tree. Passing the node tree
incorrectly as a node into the `ED_node_tag_update_nodetree`
corrupts the data, because it attempts to set flags on the
node.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7747
Among other things, they were missing library pointer, session uuid
initialization, etc.
Fix T74546: Corrupted nodegroups crash blender when copy pasting or
appending them.
Fix (unreported) asserts when undoing some production scenes (from
coffee run e.g.).
Initialy caused by rB0aac74f18f2d.
This error was introduced wit the change in commit https://developer.blender.org/rB6a850f3cc840
As the brushes were not created, all modes except Edit were broken.
Now, the brushes and palette are not created when load the file in versioning code, but when the mode is enabled.
Also, if the brush already exist, the parameters are not reset as it was done in the versioning code in order to keep user settings.
The same logic is used for the default palette.
Caused by rB5593efec01c2.
Use first texture if we dont have an ImageUser (instead of multiview
one). Same fix as in rB9ace7e243978 / T74925.
Maniphest Tasks: T76755
Differential Revision: https://developer.blender.org/D7743
