There needed to be a check that when a newly created point is
supposed to be on an edge, that it stays within the bounds
of either end of the edge.
This fixes the hole-in-cube example in the bug, but not
the boolean modifier one, which still needs more work.
Actually, was broken for any custom modifier name, since it was explicitly using 'Cloth' one. Changed to mimic other cloth pressets (wonder why this one was different!).
Just remove that rotation special case for now, at least fixes the glitch along Z axis when rotating around Y axis in report.
Anyway, there is no reason for such special handling, we do not have real rotation in editbone...
This case was handled specially in writeffmpeg.c and seems it makes
audio export happy in all cases now.
TODO: libav-10 doesn't work with AC3 codec yet because this bloody
library ONLY supports FLTP format and FFmpeg ONLY supports FLT.
This is not fun guy, it really isn't! Where's your conscience??
CC: nexyon
Issue was caused by the way how audio output works from audaspace.
Now made it much closer to what's happening in ffmpeg.c and writeffmpeg.c.
Also fixed issues with incompatible combinations of codecs and formats
in mixdown settings.
Commit 162d6c73e3 changed the behavior of rendered viewport to use
viewport visibility, but that can cause some problems. For example,
mesh deform cage is drawn as a solid/textured mesh (not a wireframe
mesh) and its unnecessary surfaces and shadows mess up the preview.
The script ##cmake_linux_install.sh## is currently invoking ##make## in single-threaded mode; this patch changes it to take advantage of all available CPU threads.
Reviewers: mont29
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D358
MSVC 2008 ignores alignement attribute when assigning from unaligned
float4 vector, returned from other function. Now Cycles uses unaligned
loads instead of casts for win32 in x86 mode.
This is needed to minimize their reprojection error over the footage.
Without this extra step positions of such tracks were calculated by
algebraic intersection code only, which doesn't give best precision.
This is a resubmission of the original patch from D255. Sorry, I didn’t understand that subsequent patches added to a diff are considered to //override// previous ones, rather than add to them.
Basically the comment for commit rB554eca1c288e has been applied to the wrong patch.
Reviewers: mont29
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D359
