I was careful in selectively rolling back revisions, but if you've committed changes unrelated to BPY mixed with BPY changes, I might have reverted those too, so please double check.
using the last selected face was almost good enough however when selecting verts and edges the last selected face would become inactive and the space image would flicker about too much.
The active face is used for getting the space image at the moment and keeps scripts that use this flag working also.
This has 2 commands to get and set, so the variable is not accessed directly.
all "UV Calculate" scripts work now
last commit crashed when in solid draw mode, it seems subsurf modifier is ignoring the displayMask since MTFACE is available. just made it do a null check for now.
uvcalc_follow_active_coords.py - should be done inC and put in the snap menu.
This broke theeths UV-Exportscript.
updated and added 2 missing decref's, as well as a check not to write a list of faces greater then the size of the NMesh (mesh and NMesh face lengths can differ)
Data from Armature.c and logic.c still leaks.
Mostly todo with PyList_Append adding a refcount and the bpython api not decrefing.
Also added some features needed to fix a bug in mesh_clean.py (ob.pinShape and ob.activeShape)
Updated Python Mesh API to support UV and Color layers with names.
Similar to vertex group's
renamed a function in customdata.c CustomData_free_layers -> CustomData_free_layers_active and made CustomData_free_layers accept an index, this is needed so python could free layers that arnt active.
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.
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.
The wait cursor was being called during editmode enter and exit for meshes.
This was a problem for several reasons. First of all, python modules like
Mesh now make use of editmode features. These methods that wrap editmode
tools may be called many times during the execution of a script
and lead to the wait cursor rapidly flickering on and off.
The other problem was that the wait cursor wasn't being called for editmode
enter and exit of all data types. This is unified now.
-New Arguments
enter_editmode() should be passed a nonzero integer or simply EM_WAITCURSOR
if the wait cursor is desired. Currently only the python API passes a '0'
to enter_editmode()
exit_editmode() has several options and they are passed in as the bitflags
EM_FREEDATA, EM_FREEUNDO and EM_WAITCURSOR. These flags are defined in
BDR_editobject.h.
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.
- Found several places, where people explicitly casted the frame number
to short.
- Fixed the crash in BPY_interface by adding an empty line (to make it
recompile everywhere, make clean doesn't help...)
For the build system maintainers:
Problem was: The change in makesdna changed the position of the
scriptlink structure. BPY_interface.c somehow didn't get recompiled
(not even after a make clean!!!) which triggered crashes on adding
scriptlinks.
recalculate, causing a segfault when the curve was selected in the Ipo
window. lattice.insertKey() has similar code. Added calls to
allspace(REMAKEIPO,0) to correct this.
Bugfix #3660: NMesh.getVertexInfluences() was broken following the changes
to the armature system. Tron Thomas (kudos) came up with a fix that seems
to perform identically to the old method. I'm also adding it to the Mesh
module for compatibility.
NMesh lists before trying to build a new mesh (used by mesh.PutRaw() and
mesh.update()). It was possible to put junk into the NMesh lists, resulting
in some messed-up meshes.
- malformed nmeshes could crash Blender with a sigsegv. Related to old
behavior that accepted "faces" with one or two verts.
- removing unused var (store_edges) + doc update.
returning Python exceptions. EXPP_ReturnPyObjError() always returns a
NULL because Python expects error conditions to return a NULL pointer
instead of an object. Since the pointer is cast to a PyObject *, it's
ugly to use for propagating the errors back in this case, so this fix just
uses PyErr_SetString() to set the error and return NULL (see the body
of EXPP_ReturnPyObjError() ).
NOTE: I had to fix NMesh.c, Mesh_fromNMesh(), that is a real bad
function... it was returning a Py object as a Mesh (on error).
This is still not really solved (NULL return is not handled).
Changed Object.link() to allow link objects with both BPython-type meshes
Changed Object.getData() to allow retrieving both types of BPython-type meshes
Added new mesh types to Types module
- #2781, reported by Ed Blake: crash on undo when there were active space handlers. Space Handler script links belong to screen areas, which do not get saved on undo. Thanks Ton for pointing out the function that restores ui pointers gone bad.
- Applied patch #2822 by Ken Hughes for bug #2647 ("Setting a Face UV"), reported by Campbell Barton.
- #3022, reported by Timothy Wakeham: "Blender.BGL.glDrawPixels crashes when drawing more pixels then buffer size". Made glDrawPixels check buffer dimensions.
- #2882, reported by Campbell: crash in nmesh.getMaterials(arg == 0 or 1) when nmesh came from GetRawFromMesh(). Raw nmeshes are not linked to Blender meshes, so the method doesn't support these options (getting mat info from the actual mesh) for it.
- #2817, reported by Tod Koeckeritz: Dir_Depth var was not being decremented in BPY_Menus.c, causing dir depth limits to be reached prematurely.
- #2954, reported by Daniel Holtz: "Python scripts crash hard with valid windows paths". Blender.Load() was not meant for background mode, now it's been update to support it, using BKE_read_file instead of BIF_read_file in this case. Also found another issue with command line scripts using Blender.Load() that could crash Blender: trying to free the Text when it wasn't available anymore (loading a new .blend already removed it). There are still issues with one case, though, causing a crash on start or "Memoryblock winopen: double free" at end, when running a script that is already a Blender Text (only if the script calls Blender.Load, of course). Will investigate.
- #2897: reported by Timothy Wakeham: object.setMaterials was asking the length of a Python list w/o confirming first if the passed obj was really a list.
Thanks all for the help and for being patient (long delay, again).
reads from the old mface->edcode flag to set edge drawing.
ALso; added a pointer check in draw_mesh_object(), here the derivedmesh
gives NULL on reading regression file lostride.blend. Zr needs to check!
- Pontus Lidman contributed a new module: Blender.Key + access to key objects from NMesh, Lattice and Curve + docs (thanks and sorry for taking so long to check/commit the patch!)
- Allowing EVENT spacehandlers to call the file selector (scriptlinks in general are not allowed, but this special case should be able to). Requested by Paolo Colombo (thanks!)
- tiny doc update (Ken Hughes pointed an error in the space handlers example)
I didn't have time to update the Key module to follow the current bpython design, will do that later and also test it better than I did.
