| Age | Commit message (Collapse) | Author |
|---|
|
Currently this is mainly useful for picking camera DOF depth.
- EKey over a distance field prompts you to pick a depth from the camera.
- WKey (Specials menu) to pick from the 3D view (when the active camera's selected).
|
|
|
|
extrude_discrete_faces doesn't duplicate faces on extrude, see: T43237
|
|
|
|
|
|
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
|
|
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.
|
|
same file names with ED_object's one.
|
|
|
|
|
|
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.
|
|
XKEY does
|
|
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
|
|
Much more lenient if you are a human.
|
|
This is the (big!) core of mesh transfer data, it defines a set of structures
to represent a mapping of mesh elements (verts, edges, polys of loops) between
two arbitrary meshes, and code to compute such mappings.
No similarity is required between source and destination meshes (though results
when using complete different meshes are rather unlikely to be useful!).
This code is not bound to data transfer, it is defined to be as generic as possible,
and easy to reuse or extend as needs arise.
Several methods of mapping generation are defined for each element type,
we probably will have to adjust that in future (remove useless ones, add
new ones...).
For loops, you can also define islands (for UVs e.g.) so that loops of a same
destination polygon do not 'spread' across several source islands.
Heavily reviewed and enhanced by Campbell, thanks a lot!
|
|
returns indices in mesh face range
|
|
`INSERT_FAST` implies you call `calchandles_fcurve()` at the end...
For now, since we do not store edited FCurves nor can we get them easily
(requires RNA...), just update handles of all fcurves, it's much more
performant than removing usage of `INSERT_FAST` anyway.
|
|
Loosely following Python str convention.
|
|
texpaint
|
