Occasionally we get reports of people that build blender and end up
with either build errors or end up with builds that do not run on
other systems. The root cause is when you install vpckg and integrate
it into the build system it puts the search path for its includes and
libraries before anything else.
previously we told people to either uninstall vcpkg or remove the
conflicting packages, which was not great.
this change opts out of the use of vcpkg for blender only, so people
can keep using it for other work without issues.
The value of the step was calculated using a variable that was removed when the render frame change.
Now, the step is calculated using the modulus of the current frame and recalculate noise only if the remainder that results from performing integer division is equal to 0.
To calculate current frame, the first used frame is calculated to adjust real frame range.
This approach is more stable in viewport and render.
There was a fixed limit to the number of points available in a buffer stroke.
Now, the array is expanded as needed using a predefined number of points for each expansion, instead to add one by one. This is done to reduce the number of times the memory allocation is required.
As part of the fix, some variables have been renamed to reflect better their use.
When the mesh is using custom normals, those should always be exported,
regardless of the `ME_SMOOTH` flag on the invidivual polys.
Also replaced the loop normal writing with the same logic as we use for
reading (less pointer arithmetic, more normal counting).
Loop normals are called 'Face-varying normals' in Alembic. Before this
commit, the existence of such normals was used to enable smooth shading.
This is incorrect, as the normals could encode flat faces just as well.
This commit adds the loading of these normals as custom loop normals. It
then also enables Auto-Smoothing on the mesh (which is a bit of a
misnomer and indicates to Blender that the custom normals should be
used).
Fixes the glitching described in T65959.
Differential Revision: https://developer.blender.org/D5191
The only thing that is stored in this pointer is a `Mesh*`, and casting
it from/to `void*` is unnecessary and confusing. Maybe the entire
CDStreamConfig class could/should be removed at some point.
No functional changes.
By having a switch statement that lists all the values of the enum, it is
clear which cases we're not handling, and it also allows for warnings in
the future when the enum expands.
No functional changes.
The w-component of the translation column of the scaled matrix wasn't
set to 1.0, which, apart from being incorrect, caused drawing problems.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5290
When using the clone brush, the first time the brush worked, but the next time no. The reasons were two:
1) The strokes were copied to the active layer, but if there were more than one layer, the stroke must be copied to the original layer.
2) The materials were not assigned properly and the materials were set as the first slot in the list always.
Now, the original layer name is used to try to find the same layer in destination. If the layer is missing, the active layer is used.
For materials, the bug in the hash lookup is fixed and the material is assigned to the right slot.
The issue was that the redo panel area would call with region type HUD (not WINDOW).
Now we make sure that the redo panel always polls the operator in the original area type context.
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D5361
While speedup is hard to detect (highly fluctuent), it seems to be
around 5% on average on my 8 threads machine...
It also remove usage of a 'global' thread lock, which is always good.
Note that I also tried to use proper foreach threaded iterator construct
(see D5372), but that proved to be relatively slower (presumably due to
the very high dissymmetry between tasks, usually during a paint stroke
only a few chunks will require most of the computing effort, overhead of
threaded foreach management is then noticeable).
This concludes (for now) the work on
T51133 Bad performance with texture painting depending on multi-thread settings.
Previously we were setting it to 1 (aka no 'chunking'), to follow
previous behavior. However, this is far from optimal, especially with
CPUs that can have tens of threads nowadays.
Now taking an heuristic approach (inspired from the one already existing
for `BLI_task_parallel_listbase()`, which tries to guesstimate best
chunk sizes based on several factors (amount of threads/parallel tasks,
total number of items, ...).
Think this is a reasonable base ground, more optimization here would of
course be possible.
Note that code that was already explicitely settings some value here
won't be affected at all by that change.
Some ugly very low-level collection code was using the generic
LIB_TAG_DOIT tag... should never happen, that one is for rather
high-level code to use, core process shall use own tags.
This allows to type in numinput 720 and indeed get a rotation of 720°, not 0°...
This patch basically applies 'big rotations' in steps < 180°, such that
compatible rotation works as expected. This implies resetting current
rotation to initial one first, otherwise we'd end up applying much more
turns than expected when that code is called more than once.
It also makes things somewhat slower for big rotations (millions of degrees),
Hence we clamp to 1000 turns max.
And since that's a case that cannot happen with regular tool/widget-driven rotation,
it's only enabled when numinput is used for now.
Review task: https://developer.blender.org/D5289
Curve drawing was attempting to draw reprojection error curve when it was
not visible.
Worst thing is that the imm was not informed about vertices, so the code
was causing an assert in debug mode. Probably, it is also what have caused
random crashes after recent changes.
We didn't include and of the newer interpolation types in the
normalization function.
Besides taking into account these newer types, we now also only evaluate
the curves when needed. If the values between the control points won't
exceed the control point values, we only use the start/end values for
our normalization
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D5365
Mesh can not be requested from original object, and it can not be
copied into evaluated modifier because there is no such a thing yet.
It can not be done this way now, because getting evaluated object
will force it to re-calculate, which kind of defeats idea of this
code to preserve un-baked particles.
This commit moves the API of selecting faces, vertices and edges to a DRW manager engine.
Reviewers: campbellbarton, fclem
Subscribers: jbakker, brecht
Differential Revision: https://developer.blender.org/D5090
This is useful when popovers are launched from operators
instead of as button popover types.
Where the connection between the button and the popover is useful to keep.
We cannot reliably use translations API from non-main threads.
Now storing translated strings in a static cache, with basic mechanism
to update it on language change.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5350
This was caused by 2D stabilization trying to be smart and lower weight
of tracks which are too close to the rotation center. This was causing
algorithm to ignore a single track which was set to constant 1 weight and
used for rotation compensation.
It is quite tricky to quantify this change without having comprehensive
regression suit, so can only hope that initial intention is still working
as expected.
Weight Painting was using mask if "Selection Mask" in Sculpt Mode is turned on.
This can be quite confusing because the option to turn it off is not available in Weight Painting and the selection is also not visible.
Now the mask is not checked in weight paint mode.
The constant variable was passed as reference to constant variable, but it's better use the new function to copy values.
This could be the problem with T67772
Sync back between proxy armature pose and linked one was not properly
clearing the posebone runtime data, ending up with shared memory between
both (direct cause of reported crash), and probably some other nasty
issues.
While this crash is not critical in itself, I would suggest to add this
fix to 2.80 branch, as it is super-safe and simple, and is probably
fixing some other un-reported issues?
