Age | Commit message (Collapse) | Author |
|
|
|
concurrency.
Note: this commit seems to work as expected (also with transform
snapping etc.). However, it is rather unsafe - not enough for 2.79 at
least, unless we get much more testing on it. It also depends on three
previous ones.
Note that using a global lock here is far from ideal, we should rather
have a lock per DM, but that will do for now, whole DM thing is doomed
to oblivion anyway in 2.8.
Also, we may need a `DM_DIRTY_LOOPTRIS` dirty flag at some point. Looks
like we can survive without it for now though... Probably because cached
looptris are never copied accross DM's?
|
|
That one was doing exactly same thing as `dm->getLoopTriArray()`, no
point in having twice the same code here...
|
|
arrays again from DM.
This was... horribly wrong, CDDM will often *not* need to allocate
anything to return arrays of mesh items! Just check whether array
pointer is NULL.
Also, remove `DM_get_looptri_array`, that one is useless currently,
`dm->getLoopTriArray` will always return cached array (computing it if
needed).
|
|
All three functions were doing exactly the same thing, simpler to only
have one in that case!
|
|
|
|
|
|
|
|
Vertices on the axis can be optionally merged,
nice for creating objects which close at the end-points.
|
|
This isn't library data.
|
|
Only the camera from View3D.localvd is used,
other pointers may be invalid.
Longer term we should probably clear these to ensure no accidents.
For now just follow the rest of Blender's code and don't access.
|
|
Need some extra checks and should be probably end up in 2.79 since that's a regression.
|
|
Baking rigid body cache was broken if some cached frames already
existed.
This is just a band aid for release, the logic need to be looked into
further.
|
|
break the simulation
Revert 9cd6b03, 3edc8c1, b87d10d and do a better fix for T50230.
|
|
|
|
Increased the maxx and maxy area of interest when scaling in this case.
|
|
We have a hardcored limit of 1000 images to be baked.
However anything anove 100 would be leading to overflow in the code.
Caught by warning from builder bot (my compiler doesn't even complain
about this, but it should).
|
|
freaks out when the curve has a parent
|
|
This is more a workaround for until we've got proper visibility flush, which
will likely happen in blender2.8 branch.
|
|
Apparently with Maya in a certain configuration, it's possible to have an
Alembic object without schema in the Alembic file. This is now handled
properly, instead of crashing on a null pointer.
|
|
|
|
"datablock" channels even though those weren't visible
This meant that it was easy to accidentally select too many keyframes
|
|
For example, if you have two keyframes:
k1 = 1px, k2 = 10px
it was doing:
1px, 9px, 8px, ..., 3px, 2px, 10px
instead of:
1px, 2px, 3px, ..., 8px, 9px, 10px
|
|
The recalc flag must be enabled for new interpolated strokes.
|
|
Each qsort implementation may give different results when values match.
Now fallback to sorting by index.
|
|
|
|
The # prefix is supported,
the button didn't give enough space to paste it.
D2812 by @candreacchio
|
|
|
|
|
|
- Vertex only meshes never restored their selection history.
- Select history was cleared on the source instead of the target.
Simple Optimizations:
- Avoid O(n^2) linked list looping that checked the entire list before
adding elements (NULL values in the source array to prevent dupes).
- Re-use vert & edge lookup tables instead of allocating new ones.
|
|
switch_from_camera wasn't right since it was used for auto-perspective.
|
|
|
|
Regression in af3f7db caused by own fix for T51324
|
|
|
|
To be backported to 2.79
|
|
For some specific pipelines (e.g., holographic rendering) you can easily
need over a million frames (1k * 1k view angles).
It seems a corner case, but there is no real reason not to allow users
doing that.
That said we do loose subframe precision in the highest frame range. Which can
affect motionblur. The current maximum sub-frame precision we have is 16.
While the previous limit of 500k frames has a precision of 32.
Thanks to Campbell Barton for the help here.
To be backported to 2.79
|
|
to old objects.
Regression since 2.78, to be backported to 2.79.
|
|
Logic in `ED_object_check_force_modifiers` was inconsistent between add
and remove modifier cases.
Should be safe enough for 2.79.
|
|
Shrinkwrap must check it does have valid target data.
Safe for 2.79 release.
|
|
editmode bone not in any groups
There's no guaranty that given ID is found in current outliner tree...
Safe for 2.79, though not a regression.
|
|
after file save and reload.
Issue was nasty hidden one, the dual status (mix of local and linked)
of proxies striking again.
Here, remapping process was considering obdata pointer of proxies as
indirect usage, hence clearing the 'LIB_TAG_EXTERN' of obdata pointer.
That would make savetoblend code not store any 'lib placeholder' for
obdata data-block, which was hence lost on next file read.
Another (probably better) solution here would be to actually consider
obdata of proxies are fully indirect usage, and simply reassign proxies
from their linked object's obdata on file read...
However, that change shall be safer for now, probably good for 2.79 too.
|
|
If node was connected to output, we tag tree for update no matter where
the node was re-plugged to.
Should be safe for 2.79.
|
|
We were showing "search for unknown menutype WM_MT_button_context" messages in terminal which were not helpful for users, so now they are disabled.
To be backported to 2.79
|
|
It is possible to have same image used multiple times at different frames,
which means we can not free it's buffers without any guard. From quick tests
this seems to be doing what it is supposed to.
Need more testing and port this to 2.79.
|
|
Most likely needs in 2.79 final release.
|
|
normal.
Please backport this to 2.79.
|
|
Regression from rBfed853ea78221, calling this inside thread worker was
not really good idea anyway, and we already have all the code we need in
pre-threading init function, was just disabled for vertex particles
before.
To be backported to 2.79.
|
|
Regression in a7b3047
|
|
Also correct tool-tip.
|
|
The new method while improved for solid objects
doesn't work for non-manifold meshes, keep both.
|