Don't use the cube corner special case when the offsets are different
for the three edges involved. The generic VMesh for this situation isn't
perfect, but it's much better than a failed cube corner VMesh.
Tests pass.
The issue was that the projection would be inverted.
So if you shifted 0.1 along the y axis, world_to_camera_view would act
as if you had shited it -0.1 along the y axis.
There are three different label styles for the three Dopesheet filter
labels:
- "Display Hidden", which uses "Display" rather than "Show" as the other
two options.
- "Show Errors", which does not use the word "only" to indicate it will
hide all the non-error channels.
- "Only Selected", so no "show" or "display" in the label at all.
This commit changes:
- Always use the word "Show", not "Display".
- Always use the word "Only" when enabling the filter hides everything
else.
Reviewed By: billreynish
Differential Revision: https://developer.blender.org/D7742
When packing the image the height of the tile was checked to the width
of the packing area. This resulted that the tile was ignored.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D7784
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...
