In fact, Graph View wasn't been supposed to be opened in Clip show editor mode.
Made curves view unavailable from Clip view mode and store it's alignment in
a runtime flag in SpaceClip structure.
bmesh.utils.face_join(faces)
added a utility function for converting a list of python BMesh elements into a C array.
use for this face_join as well as BMesh.faces.new()
Seems that after converting tessfaces into faces normals should be re-calculated.
At least that's what happening in some other modifiers and what makes boolean
work fine with smooth normals.
Two issues are fixed here:
- On windows rename() doesn't actually renames file if destination file is already exist.
Solved by ulinking previously built proxy/timecode.
- IMB_TC_MAX_SLOT was set to incorrect value leading to record run timecode calculating
several times.
Compilation error was mostly caused by trying to use namespace std before it was
actually defined (e.g. before any include of stl header).
It's not actually good idea to use namespaces in header files -- it's really easy to
run into namespace conflicts and so. Resolved by not using "using namespace" in header
files and using full quality accessing to stl collections (e.g. std::vector).
* BM_vert_in_face now loops over a vert's faces rather then every vert in the face.
* rename bmesh_radial_find_first_facevert --> bmesh_radial_find_first_faceloop
* rename bmesh_radial_find_next_facevert --> bmesh_radial_find_next_faceloop
* rename BM_vert_collapse_edges --> BM_vert_collapse_edge (only collapses one)
* bmesh.types, just allows access to BMVert, BMEdge etc.
* bmesh.utils, so far only added edge_split() function, this module will give access to mesh editing functions.
The implementation was also changed in a couple ways: use unsigned
integers as its base type rather than unsigned chars, and uses macros
rather than functions. (These could be changed to inline functions.)
Currently it is still only used during PBVH building, but now it's
accessible elsewhere.
At the point where GPU_build_mesh_buffers is called, the
face_vert_indices map has already been built; it contains the same
data in an easier-to-access format.
Now constraints' space conversion code also uses generic armature_mat_(pose_to_bone/bone_to_pose). Previous own function (constraint_pchan_diff_mat) was somewhat inconsistent too with Hinge/NoScale/LocalLocation options...
As with previous similar changes, this might break some old rigs, in very specific cases (when constraint-evaluating an hinge/noscale/local_location bone in local space).
In the same part of code, removed unnecessary matrices copying, mult_m4_m4m4 can take the same matrix as input and output, nowadays...
Also found a bug-generator weakness in those armature_mat_ functions (if both input and output mat where the same, result was wrong, now systematically copying input mat, as done in LIB's matrix funcs).
Finally, factorized offset bone matrix generation into its own small function too, as it is used in two different places in armature.c (pchan_to_pose_mat itself, and restpose's where_is_armature_bone).
Note: I think all parts of blender's code related to that topic have now been tackled, but yet have to check BGE, it’s probably using that stuff too, one way or the other...
* Only have 1 python object per bmesh, vertex, edge, loop, face.
* Store pointers back to the python data in a custom data layer so as not to use more memory for normal editing operations (when pythons not running).
* Currently this data is created and freed along with the BMesh PyObject.
* Incidentally - this fixes comparisons for bmesh elements which wasnt working before.
* Ctrl+Click extrude wasnt normalizing the quaternion (was printing warnings)
* bmesh bevel was supposed to add a float layer and remove, but removing passed the mask define of the customdata layer.
