----------
Undo for part of previous commit. Campbell reminded me that UV texture faces
aren't "users" like other objects, so removing the code which changes them.
----------
Bugfix/enhancement: allow image of mesh's UV faces to be removed/cleared by
"del f.image" or "f.image = None", and handle image user counts correctly
when assigning/clearing images.
added python api stuff to deal with Color and UV/Image layers.
me.activeUvLayer - int
me.activeColorLayer - int
me.totUvLayers - int
me.totColorLayers - int
me.addUvLayer()
me.addColorLayer()
me.removeUvLayer()
me.removeColorLayer()
Variable names may need changing.
These can be created and deleted in the Mesh panel in the same place as
before. There is always one active UV and vertex color layer, that is
edited and displayed.
Important things to do:
- Render engine, material support
- Multires and NMesh now lose non active layers
Also CustomData changes to support muliple layers of the same type, and
changes to layer allocation, updated documentation is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
This commit upgrades the modifier stack to only calculate the data which is
needed, either by modifiers further down the stack or by other functions at
the end of the stack (e.g. drawing functions).
This speeds up modifier stack recalculation, especially where vertex
groups and UV coordinates are concerned. For example, a mesh with an Armature
modifier followed by a Subsurf modifier would previously have required the
Subsurf modifier to interpolate all the vertex groups in the mesh, slowing
down modifier calculations considerably. With this update, vertex group data
is not propagated beyond the Armature modifier, so calculations are faster.
Note that this depends on the order of modifiers in the stack. If the Armature
and Subsurf modifiers were swapped in the above example, the Subsurf modifier
would have to interpolate vertex groups, as they are needed by the Armature
modifier.
Crash using Shape Widget Wizard script, was an error in customdata copy.
The script still throws a python error though, but that seems unrelated
to this crash.
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
ID Properties binding have now been added for textures. Also,
the beginnings of supporting "del IDProperty Object" (which
basically removes the property from it's parent group then frees
it) in python were done; really the only thing now is to figure
out exactly *how* you overload the del operator. :S
This commit adds file reading/writing of ID properties to all ID types,
and also adds python access for NMesh, Mesh, Scene and Image. Note
that the file reading code might need some more work for certain
future/planned features to save right. Also I updated a few comments in idprop.c.
Added Mesh .key .removeAllKeys() and .insertKey() for MDD support (was using NMesh just for keys before)
Since this is aparently an experemental feature in NMesh we may want to change this.
This made nested loops with the same python object mess up.
eg-
faces= me.faces
for f1 in faces:
for f2 in faces:
print f1.index,f2.index
This didnt work, fixed by initializing the iter value at -1, so any greater value will create a new BPyObject with its own iter value.
once iteration is finished, its set back to -1.
Also made face and edges iter value a char instead of an int to save some memory.
exactly the same as mesh_create_derived_render(ob) except it uses the view modifier settings.
Added an optional arg to getFromObject to 'render' so you can choose to get the mesh displayed in the 3d view or generate one with render settings.
Solved bug 4612 getFromObject now works with soft body meshes (error was caused by getting the derived mesh from a copy of the object)
removed workaround for softbody bug in object_apply_def.py
aside from avoiding unneeded memory alloc/dealloc and bing faster this works around a recently discovered bug with the user count of copied Mesh keys... causing getFromObejct leak memory when used with mesh keys.
It also fixes a bug where getFromObejct with fluid-sim would corrupt memory.
indices that are within the passed group. If one of the indices was not
in the group, it returned an exception, as opposed to just removing it from
the group as the documentation states.
In a quick glance: (temp image)
http://www.blender.org/bf/rt.png
Main reason is that Lattices are useful a lot for Armature deformation.
Lattices just provide much more precise and interesting control. However,
with only bone envelopes it's very hard to use.
Working with Lattice vertex groups is nearly identical to Mesh:
- on CTRL+P 'make parent' you can choose the deform option now
- In editmode, the buttons to control vertex groups are available
- In outliner you can select vertexgroups too
- Deforming Lattices with Armatures has all options as for Mesh now.
Note:
- No WeightPaint has been added yet. To compensate, the editmode
drawing for a Lattice with vertex group shows weight values for the active
vertex group.
- Lattice editmode doesn't undo/redo weight editing yet.
- Softbody for Lattice still uses own vertex weights
Implementation notes:
- derivedmesh weight_to_rgb() is now exported to drawobject.c
- been doing cleanups in code (order of includes, var declarations, etc)
- weightpaint button handling now is generic
I've checked on Brecht's proposal for Custom Element data;
http://mediawiki.blender.org/index.php/BlenderDev/CustomElementData
It could have been used, but that would mean the existing code for
vertexgroup handling and armature deform couldn't be re-used. I guess this
is really a later todo.
More additions for Mesh.faces.extend(); allow faces with 2 verts or duplicate
verts to remain in the input list (although they are still not added to the
mesh) so that indexList option can return None for them. The goal is for all
faces which are discarded to still be ignored but return None.
New keyword parameters for Mesh.faces.extend() method:
* ignoreDups: turns off checks for duplicate faces in the input list and
existing mesh faces. Intended for constructing new meshes where the
faces are known to be unique.
* indexList: makes the method return a list of new faces indices, which
can be used to index new faces to add other attributes like color. If
duplicate faces are removed, None is placed in their list slot.
Bugfig #4527: add more robust bitfield checking for Mesh.mface.flags;
unconfirmed bug report that an exception was caused with RC3a that could
not be reproduced. It was possible that a pre 2.42 .blend might have
some additional flag bits set that would have caused an error.
Bugfix #4605: mball_to_mesh() doesn't create edges for new mesh, so
me.getFromObject() wouldn't display the new mesh until edit mode was entered.
Added a call to displistmesh_add_edges() to calculate them and then insert
into the new mesh.
A problem with the current flag seting in Mesh is that Mesh needs to know of all possible flags or setting a flag can raise an error from the faces own unrecognezed flag.
also stopped the active face flag raising an error so pythoners can do face1.flag |= face2.flag without checking for active face flags. if the flag is a part of the arg its removed quietly.
Checked Mesh flags, face modes and edge flags, should all be ok now.
