| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Really stupid issue caused by typo in bitfield bit lead to bit conflict,
Not sure how it was done, could be some bad merge conflict resolve in the
original commit or just pure man stupidnes.
This is a nice example when having set of small test render scenes hooked
to the ctest would really help.
It's probably not that stopper issue (even tho still quite bad) since it
was made 2 months ago. But if we ever do 'a' this time it's a nice change
to include.
|
|
|
|
for 'show hidden' param.
|
|
Occluding geometry failed when near overlapping (or cutting small objects).
|
|
This allows us to more easily cast from the surface of a mesh
without normal offsets (Which can give precision issues).
|
|
|
|
This way addons and render engines which needs to do versioning code on files will properly
do it when something is being linked or appended to the scene. Previously that callback was
only called for the local main only, making it impossible to do tweaks on linking.
|
|
Added extra checks for constructive modifiers which might in theory cause deformation
motion blur. it's still not totally perfect but we're getting really close to what we
can do in the best case scenario.
This commit might cause some extra time being spent on scene synchronization because
there might be now some false-positive results, but render time should stay quite the
same as before (apart from cases when there is deformation happening which was not
detected before).
|
|
There have been quite a few issues with knife precision,
tested reports (T43229, T42864, T42459, T41164) and this works with all.
|
|
|
|
- area_quad_v3 now works correctly with concave quads.
- add area_squared_*** functions, to use when comparing to avoid a sqrt().
|
|
* Ensure that when new constraints are created, the new settings have sensible
default values.
TODO: we need to version-patch old files
* Fix problem with variable shadowing (which wasn't causing problems AFAIK)
|
|
bones from shrinking below 1.0 scale
From the looks of things, this was a typo. The result was that if you had a bone
with the minimum volume restriction in place, the bone would not get any thinner
when it was stretched out.
|
|
This commit adds a new type of volume preservation mode to Spline IK
which makes it possible to set limits on the minimum and maximum
scaling of bone "fatness".
* The old volume preseving mode has been kept but renamed, to avoid
breaking old rigs. "Volume Presevation" uses the new method, while
"Inverse Preservation" is the old one.
* The code and settings for this new xz scale mode are directly lifted
from the improved Stretch To constraint
|
|
Seems like a weird issue, but to sort panels "qsort" is used, which works slightly different on Windows. So all I had
to do was cleaning up the logic in find_highest_panel so that headerless panels are sorted, but that it absolutly not
allows headerless panels to be above normal panels.
I made sure it works fine on Linux as well.
|
|
alphabetical sorting (on UI names for enums, on ID codes otherwise).
|
|
|
|
With ortho views the value would be aligned to the 'rv3d->ofs'
Now it works in camera ortho & regular ortho views.
|
|
Stepping over faces gives overall nice results but it stopped wire edges from working.
Now step over wire too.
|
|
|
|
There was a hard-coded check to exit the fileselector when restoring a view.
Now, when space types differ, flag areas as temporary and switch back to the previous type only in this case.
This means you can select a file while having a file-selector space type open, and not loose it every time.
|
|
|
|
This time, it's a dedicated operator user has to run before saving the file.
And it recursively check all IDs linked from each scene, therefore rendering
materials etc. previews using a scene they are used in.
Note the renderengine issue is not completely addressed this way
(existing code for icon previews seems to ignore completely other engines,
and IDs not linked anywhere (fake-user ones) will be rendered with current scene's engine
as fallback, also you can get a material linked to an hidden object in a scene, etc.).
Reviewers: sergey, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D980
|
|
It's apparently not nice to access 0th element of zero-size vector in C++.
|
|
Issue was, in case of using such stack within a structure, the '_' underscore
would be added in front of struct variable
(e.g. `my_struct.my_stack` would lead to (try to) using `_my_struct.my_var_pool` ...).
Now underscore is appended to var names, ugly but working.
Note did not touch to the alloca variants of those macros, since in this case enforcing
a pure local use is best I think.
|
|
Overview this in one of the previous BVH commits.
|
|
same file names with ED_object's one.
|
|
|
|
|
|
This way we'll notice that leaf splitting didn't happen correct pretty easily
in debug builds.
There'll be absolutely no impact on release builds.
|
|
This commit enables BVH leaf nodes split by the primitive type and makes it
so BVH traversal code is now aware and benefits from this.
As was mentioned in original commit, this change is crucial to be able to do
single ray to multiple triangle intersection. But it also appears to give
barely visible speedup in some scene.
In any case there should be no noticeable slowdown, and this change is what
we need to have anyway.
|
|
Use variables allocated in the stack and avoid heap allocation which should make
leaf splitting code a bit faster.
|
|
The idea of this change is make it possible to split leaf nodes by primitive
type, making leaf containing primitives of the same type.
This would become handy when working on a single ray to multiple triangles
intersection code, plus with careful implementation it might give some extra
benefits on BVH traversal code by avoiding primitive type fetch and check for
each primitive in the node. But that's a bit tricky to have benefits on this
change only because depth of BVH increases.
This option is not exposed to the interface at all and not used even secretly,
the commit is only needed to help working further in this direction without
messing around with local patches and worrying of them running out of date.
|
|
|
|
Workaround freetype's use of fopen by swapping FT_New_Face for our own version which uses BLI_fopen.
|
|
These warnings are false positives & confuses intended logic to set dummy values.
|
|
Happens because material setting now occurs in the derived mesh drawing
routine as it should. However that means that it also happens during
selection and that influenced the drawing state somehow.
In 2.72 this did not occur because material setting happened during draw
setting (skip or draw) instead of after the draw setting passed (so
selection would skip it by use another draw setting function). Of course
this violated design but worked.
Made it now so backbuffer selection does not enable materials (it's
redundant in those cases anyway).
This could be ported to a possible 'a' release but as is classic with
display code there may be some other places that it could backfire.
Tested fix with texture/vertex painting and selection which use
backbuffer for both subsurf and regular meshes and it seems to work OK.
|
|
|
|
|
|
We can now use 'generic' data transfer instead.
Note new one is not an exact replacement, it should be able to do
everyting old op could do though, and more.
|
|
selected objects to active).
Needed to replace weight transfer modifier in WeightPaint mode...
Note this is not exposed to users in UI, shall remain technical intern
parameter imho. Esp. since behavior when several sources is a bit 'random'
(merely uses each source in selection order...).
Also, this correct a bug, where 'lib' linked objects/meshes could not be used
as source...
|
|
Own fault in rBb154aa8c060a60d to fix T42447... Reverted that commit, and added
kind of not-so-nice hack instead.
Note root of the issue comes from the special case we are doing here re 'Local'
space of parent-less objects. In that case, local space should be the same as
world one, but instead we apply the object rotation to it... This is inconsistent
with all other cases and could very well lead to other issues as T42447, but afraid
fixing that properly would be rather hairy - not to mention it would likely break
all existing riggings etc. :(
Should be safe for a 2.73a, shall we need it.
|
|
potential crashers.
|
|
length.
Reported on bf-committers.
|
|
|
|
|
|
T42563 fix wasn't right, fortunately this doesn't fail in most cases.
|
|
Not much to add, modifier uses same code as operator basically, only key difference
is that modifier will never create data layers itself, you have to use dedicated operator
for that.
|
