- don't clamp if no empty groups are created
- no need to call ED_vgroup_data_create, this was very old code for weight paint r1596 - weight paint works without adding 'dvert'array.
Currently used special checks in DM draw code, perhaps better would be
simply to flush changes from PBVH to DM.
Anyway, now things seems to be working OK, will check on better solution
from code point of view later.
Own fault from grease pencil to curve enhacement. Fixed the bug itself, and made poll of convert operator more strict (no only active when there is something to convert, i.e. at least one stroke!).
This should not be needed, I really see no reason for this linking error, but I'd rather use this hack than wasting more time over this issue. When will we get rid of this "two build systems to maintain" time-wasting situation?
Full log is here:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability#Matcap_in_3D_viewport
Implementation notes:
- Matcaps are an extension of Solid draw mode, and don't show in other drawmodes.
(It's mostly intended to aid modeling/sculpt)
- By design, Matcaps are a UI feature, and only stored locally for the UI itself, and
won't affect rendering or materials.
- Currently a set of 16 (GPL licensed) Matcaps have been compiled into Blender.
It doesn't take memory or cpu time, until you use it.
- Brush Icons and Matcaps use same code now, and only get generated/allocated on
actually using it (instead of on startup).
- The current set might get new or different images still, based on user feedback.
- Matcap images are 512x512 pixels, so each image takes 1 Mb memory. Unused matcaps get
freed immediately. The Matcap icon previews (128x128 pixels) stay in memory.
- Loading own matcap image files will be added later. That needs design and code work
to get it stable and memory-friendly.
- The GLSL code uses the ID PreviewImage for matcaps. I tested it using the existing
Material previews, which has its limits... especially for textured previews the
normal-mapped matcap won't look good.
It was caused by own mistake by not noticing externtex is used not
only by render engine. Now this function uses pool passed as argument
rather than using R.pool.
StrokeVertex.point2d() instead of .getPoint(). It is noted that .point2d()
returns a 3-dimensional vector representing a 2D-projected point, with the z
component indicating a normalized depth of the original 3D point, whereas
.getPoint() returns a plain 2-dimensional vector. This fix should have been
done in revision 48510...
Also made fix for callers of Stroke.Resample() not calling stroke.UpdateLength().
Previously normalization will happen per image buffer individually, which
was wrong in cases different faces of the sane mesh uses different images.
Also solved possible threading issues when calculating min.max displacement.
This bug did not appear earlier because the "" default context was actually never used, always NULL context was passed instead. But bpy.app.translations uses "" as default context in its keys (simplifies the hash/comp functions of internal py messages cache)...
So now, Blender prefers NULL (None in python) as default context value, but understands also "" as such.
This will calculate maximal distance automatically and normalize displacement
to it. Before this change normalization will not happen at all in cases max
distance is not set manually.
This affects on "regular" baker only, there are still some fixes to come for
multiresolution baker, but that could be solved separately.
