| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
You can now use lower-level '_ex' versions of bvh creators to only use part of
the mesh's elements in the BVH, and/or create bvh from non-DM sources.
Needed for transfer data.
Note edges extend version of bvh creator is not added here, not needed so far.
|
|
instead of two vectors.
|
|
Needed by transfer data.
|
|
Needed for transfer data.
|
|
and graph editor.
This was a tricky commit that was not so straightforward to make work.
The information for bones is not easy to come by in the animation curves,
however we do have some string manipulation tricks to make it happen.
Testing in gooseberry worked for the rigs there, commiting to master now
|
|
paths in new copies.
Propper fix reverting most of rB60e70c0c6014e5, which was only partial specific fix.
This code uses generic `BKE_id_lib_local_paths()` func to handle all possible paths.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D977
|
|
Also cleanup extrude code.
- remove normal calculation.
- remove return values for transform type.
- use enums.
Thanks to Psy-fi for finding the initial fix.
|
|
|
|
paths in new copies.
Simply have to rebase onto main filepath when copying, if source datablock is lib and path is relative.
Afaict, only affected Image and Text datablocks. MovieClip would also be a candidate, but has
no copy implemented currently.
|
|
textures slots
|
|
This fixes obvious overflows when checking bitflags, who knows how much
undiscovered issues exists in the code still..
|
|
|
|
|
|
|
|
Instead of getting fancy this time, we'll just use Mahalin's simpler
fix. This may have slight performance impacts, but it is a lot simpler
than the previous fix and shouldn't cause as many bugs.
|
|
This reverts commit 315609ec0c1e28eb12bde3e8bbd2a5b03672b1a9.
This fix still causes more issues than it solves.
|
|
MacOS.
This looks like an oldie and should not influence release, but if we do
make an 'a' build it's safe to include.
Report by Craig Jones, thanks!
|
|
(not my day...)
|
|
Sorry about that, should have checked this stuff more, with Internal material
renders are very fast (unoticable), but with Cycles it can take (a lot of) time,
like several minutes or more.
Will probably fall back to a dedicated operator users will have to fire themselves
when they want previews in their files.
|
|
trying to be smart.
This breaks child interpolation otherwise because sometimes parent
paths are not calculated and give bad clumping results.
|
|
This allows scripts to request the screen location of any (line, column) pair.
|
|
Thanks to Campbell for the headup.
|
|
|
|
enabled in userprefs.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D970
|
|
This is to be backported to the release branch.
|
|
|
|
|
|
|
