| Age | Commit message (Collapse) | Author |
|---|
|
Should have been done before ahoy, sorry about that. Means 2.79 tag will
be one (no functionnal changes) commit ahead from our 2.79 builds, think
we can live with that.
|
|
|
|
Was caused by divide-by-zero in paint_stroke_integrate_overlap()
in paint_stroke.c, as identified by Bob Smith (uvwxyz).
Thanks for the report!
|
|
|
|
|
|
Threading conflict, should be safe for 2.79.
|
|
Previous fix wasn't working correct for certain compiler and CPU intrinsics
mode, causing quite some crashes.
This should be a safer fix, which is closer in behavior to previous release
but which should still fix issues with robust curve intersection.
|
|
|
|
|
|
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.
|
|
Need this in 2.79 branch as well, since build rules are based on this files.
|
|
|
|
Increased the maxx and maxy area of interest when scaling in this case.
|
|
scripts being "Artwork" which is your sole property and free to license.
I've removed the reference to scripts in this text.
This was from 2002! With our Python scripts becoming part of how Blender runs,
such scripts now are officially required to be compliant with GNU GPL.
For more information; check the FAQ or consult foundation@blender.org
https://www.blender.org/support/faq/
|
|
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
|
