- in the case of deform modifiers this is very safe (assuming the mods themselves dont need tessface data), since the DM is freed right after, so this is an easy speedup.
- in the case of bevel and split edge modifiers this should still work out fine since mods that need tessface data will generate it.
Quick shows over 2x speedup in my tests, will give bigger speedup with more vertex groups.
If you happen to have vertices with no faces using them - vertex colors will be calculated unnecessarily, but this isnt a common use case for weight paint mode.
Warning! Tesselation uvs or vcol data got out of sync, "had to reset!
This would happen on every editmode edit with UV's and wasn't too reassuring that blender was handling uvs/vcols correctly.
From looking into the problem I found that creating the undo mesh would act as if it was tessellating the existing mesh each time and complain that the data was out of sync, when infact the mesh was just created and being filled in.
Also, allocating uv and vcol customdata arrats for tessfaces isn't needed for undo mesh, so save some memory and dont allocate these in the first place.
when no modifiers are applied, dont re-tessellate,
for future referece - this bug was caused because can_pbvh_draw() checks if (cddm->mvert == me->mvert)
re-tesselating the faces copies the vertex array so it was returning false.
- some merges added lines in multiple times
- removed some NULL checks that were only in bmesh
- enable cycles by default (was disabled because it used not to work)
- make formatting match
Added compareDrawSettings callback to driver mesh's callbacks which are
drawing textured faces (mapped and not mapped). This new callback checks
if two faces are drawing with the same settings (testures, shading etc)
and if they not, flush of faces happens into ogl using glDrawArrays and
next face would be drawn with it's own settings.
Currently implemented compareDrawSettings is used to resolve issue from
bug report only, probably there are extra places where this callback is
needed, but haven't seen configuration where current logic will fail,
so it should be ok.
Also reordered arguments passing to drawMappedFaces DM's callbacks,
so now all drawing callback are accepting list of callbacks and then
userData, instead of using mixed order of callbacks and userData which
was a bit confusing to work with.
This commit fixes:
- #26410: VBO & multitexture doesnt work
- #29464: VBO enabled causes UV coruption
from Andrew Hale (trumanblending), with some edits to use these in mathutils.Vector added.
Added Functions:
- dot_vn_vn - Dot product of two arrays
- normalize_vn_vn - Normalize an array and store the result in a second array
- normalize_vn - Normalize an array inplace
Renamed Functions:
Some functions have been renamed to make them consistent with the naming conventions used by fixed length array functions.
- fill_vni to fill_vn_i
- fill_vn to fill_vn_fl
effect for a render engine using new shading nodes. In short:
* No longer uses images assigned to faces in the uv layer, rather the active
image texture node is what is edited/painted/drawn.
* Textured draw type now shows the active image texture node, with solid
lighting.
* Material draw mode shows GLSL shader of a simplified material node tree,
using solid lighting.
* Textures for modifiers, brushes, etc, are now available from a dropdown in
the texture tab in the properties editor. These do not use new shading nodes
yet.
http://wiki.blender.org/index.php/Dev:2.6/Source/Render/TextureWorkflow
