| Age | Commit message (Collapse) | Author |
|---|
|
Own error in 7398b3b7
|
|
Making those arrays static remove them from exported symbols, which
breaks API doc generation script.
To be backported to 2.79 branch.
|
|
|
|
Missed this in previous commit.
|
|
Was quite stupid reason for this: static size of array.
Now we allocate needed amount of points in heap if requested path length is
getting too big.
|
|
|
|
|
|
Was Cygwin workaround, no longer needed.
|
|
|
|
This is still far from prefect, but yet much better than what we had so
far (more consistent with inheritent precision available in floats).
Note that this fixes some (currently commented out) units unittests, and
requires adjusting some others, will be done in next commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
node properties in outliner.
Bug was in RNA nodes code actually, itemf functions shall never, ever
return NULL!
Note that there were other itemf functions there that were potentially
buggy. Also harmonized a bit their code.
|
|
* Numbers with units (especially, angles) where not handled correctly
regarding number of significant digits (spotted by @brecht in T52222
comment, thanks).
* Zero value has no valid log, need to take that into account!
|
|
|
|
|
|
|
|
The names aren't meaningful but means it wont
accidentally use valid names.
Also remove textured-font setting
|
|
When calling sculpt from Python,
setting 3D 'location' but not 2D 'mouse' stopped working in 2.78.
Now check if the operator is running non-interactively and
skip the mouse-over check.
|
|
Calling an operator with EXEC_* context would still set the invoke flag.
|
|
Regression in D1812: PyDriver variables as Objects
Taking the Python representation is nice in general
but for enums it would convert them into strings,
breaking some existing drivers.
|
|
Some users really liked previous behavior,
so making it an option.
Cursor Lock Adjustment can be disabled to give something close to
2.4x behavior of cursor locking.
When lock-adjustment is disabled placing the cursor the view.
This avoids the issue reported in T40353
where the cursor could get *lost*.
|
|
Also adds cursor-lock flag, to be used in next commit.
|
|
Even strands that were excluded by the density texture were being added
to the DM passed to cloth, but these ended up having some invalid data,
because they were not fully constructed.
This simply excludes `UNEXISTED` particles from the DM generation, as
would be expected.
|
|
Object field.
Note that fix is not perfect, systematically make refcounting of all IDs
assigned to node's id pointer, which breaks the 'do not refcount
scene/object/text datablocks' principle...
But besides that principle being far from ideal in general, it becomes
pretty much impossible to apply when using //generic// ID pointer,
unless we add some kind of type data to that pointer somehow.
So for now, better to live with that, than having broken usercount.
|
|
|
|
Reported by coverity, better fix even if highly unlikely to happen...
|
|
crashes Blender.
but pointer was not assigned in that case...
|
|
|
|
|
|
The purpose of the keymap strings is probably for un-embossed menu items
like seen in most pulldowns. I can't see a reason for also adding that
string for regularly drawn buttons within popups, we don't add it
anywhere else in the UI either. So this commit makes sure shortcut
strings are only added to buttons that are drawn like pulldown-menu
items.
|
|
|
|
|
|
|
|
|
|
`defvert_array_find_weight_safe()` was confusing 'invalid vgroup' and
'valid but totally empty vgroup' cases.
Note that this also affected at least ShrinkWrap and SimpleDeform
modifiers.
|
|
Adds bpy.app.factory_startup,
used to check if user scripts should be loaded.
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2747
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D1867
|
|
(alt + b) is not bypassed in snap to faces"
This reverts commit 7f09b55d01c248a741e967af597b7519f095983b.
|
|
is not bypassed in snap to faces
The geometry behind the farther clip_plane is not bypassed
|
|
|
|
|
|
|
|
Moving the ray_start_local to the new position does not lose as much precision as moving the ray_org_local to the corresponding position.
The problem of inaccuracy is within the functions: `bvhtree_ray_cast_data_precalc` and` fast_ray_nearest_hit`. And not directly in the values of the rays.
|
|
|
