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.
to get rid of faces with MFace.v3==0
- change all Mesh's to have ->medge now. This is forced by make_edges
on readfile, and in the various exotic important routines, and on
conversion back in python.
- make python NMesh structure always have medges now (needs testing)
- with above two changes it is guarenteed that mf->v3 is never ==0
in main blender code (i.e., all MFace's are actually triangles
or quads) and so I went through and removed all the historic tests
to deal with MFace.v3==0. Equals lots of deleting, I am in heaven!
- removed MEdge edcode flag, no longer needed
- added experimental replacement for edge flag system
Still are some inconsistencies in FACESELECT mode edge drawing to
be ironed out.
NOTE: This commit adds an experimental edge flag calc system, based
on 10-seconds-of-thought algorithm by yours truly. Would appreciate
feedback on how this system works, esp compared to old one and esp
on complex or interesting models.
To Use: New system is enabled by setting G.rt to a value between
1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for
"auto" edge, which is more or less identical to old system but also
makes sure that at least 10% of edges are drawn (solves errors for
super subdivided meshes). Values between 1 and 999 act as percent
(out of 1000) of edges that should be drawn, starting with "most
interesting" edges first. Please try it and comment!
mapping (instead of Edit{Vert,Edge,Face} pointers)
- dropped convertToDispListMeshMapped (whew, glad of it too)
- added DerivedMesh drawMappedFaces function
- dropped EM suffix for DerivedMesh functions, it was neither
particularly correct nor descriptive
- converted test_index_mface to test_index_face that also corrects
MCol and TFace. Good thing we had three versions of this routine,
you never know when one might burn down.
- removed flipnorm_mesh, not used anymore (and was incorrect to
boot)
- Getting face select to work with modifiers turned out to be much
more complicated than expected. Reworked mapping architecture for
modifiers - basically elements in a DispListMesh are now required
to be stored in an order that corresponds exactly to original
ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX
that is set on each element that is set on the first derived element
of each original element. I can't say the code to follow these
requirements for subsurf is particularly transparent, but on the
upside it is a reasonably consistent and simple system that is memory
efficient and allows keeping the DispListMesh structure.
- rewrote mirror modifier to be simpler/conform to new requirements
for mapped DispListMesh structure. This also means that mirror interacts
much better with incremental subsurf calculation (it used to recalc
one entire side on any topology change, now it generally avoids that).
- added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index
functions to handle mapping indices back into appropriate EditMesh
structures.
- bug fix, make edges didn't recalc object data
- bug fix, initial image assignment to TFace's didn't recalc object data
- new feature, added circle select support for FACESELECT
- bug fix, creating new faces in editmode duplicated the TFACE active
flag - but there should only be one active tface
- bug fix, possible crash when deleting all faces in faceselect mode
on mesh with tfaces...
Still todo: TFace edge drawing is still not always correct in face
mode, in particular with a mirror modifier when mesh has edges (and
no preceeding subsurf). Have not yet decided how to deal with this.
Best solution is probably to do switch to meshes all having MEdge's,
in which case I can get rid of TFace edge flags (and need to recalc
modifiers on tface selection change).
- give it the key/items interface
- creates some factory functions for const generation
- genutils methods
- method for getting module constants
- method for throwing errors with a print string
- updates to function names
- clean up interpreter launch a bit
- removed {lattice,curve}_modifier functions
- changed render code to use displist for curve rendering
instead of making its own. required adding a bevelSplitFlag
field to DispList. I also fixed the bevel face splitting
which did not work correctly in many situations.
- changed so all curve data creation happens in makeDispListCurveTypes,
includes making bevel list and filling polys
- changed render code to use displist for surface rendering
- removed Curve.orco variable, built as needed now
- removed stupid BLI_setScanFill* functions... why use a function
argument when you can use a global and two functions! Why indeed.
(this fixed crash when reloading a file with filled curves and
toggling editmode)
- bug fix, setting curve width!=1 disabled simple bevel for no
apparent reason
- cleaned up lots and lots of curve/displist code (fun example:
"if(dl->type==DL_INDEX3 || dl->type==DL_INDEX3)"). Hmmm!
- switched almost all lattice calls to go through lattice_deform_verts,
only exception left is particles
- added DBG_show_shared_render_faces function in render, just
helps to visualize which verts are shared while testing (no
user interface).
- renamed some curve bevel buttons and rewrote tooltips to be
more obvious
- made CU_FAST work without dupfontbase hack
Also by the way I wrote down some notes on how curve code
works, nothing spiffy but it is at:
http://wiki.blender.org/bin/view.pl/Blenderdev/CurveNotes
- added ME_EDGERENDER flag, barely changes things atm except makes
sure plain meshes with FasterDraw/etc set still render all edges.
The edge drawing system needs a bit of a revamping - it is a cool
feature but could use several improvements:
(1) The algorithm could be better in choosing the best edges to
draw.
(2) The drawflags should interact well with modifiers. It is wierd
to have a large grid with a deformer that draws no edges because
flags are only calculated based on base mesh.
(3) Drawflags should not be destroyed by editmode. Better design
would be a "Draw % of edges" button.
Of course, could also be the feature is not worth it and we
should just drop. Feel free to comment if you have an opinion.
wondered what these silly data pointers in MDeformVert were for.
Turns out they aren't even need! Just taking up extra memory and
space and confusing the armature deform algorithm. Naturally I
had to clean things up. Sorry Ton.
Deform weights are still stored in a pretty expensive and unnecessary
way, probably use about twice as much memory as needed, and do
way too many memory allocs.
- moved armature_deform_verts into armature.c
- some python code accessed the MDeformWeight data pointers, but
did so in a completely wrong way, I am positive this code could
never have worked (or maybe things changed during tons refactor),
regardless it wouldn't work now... will test later.
DLM to share data from DerivedMesh (reduces some copying/memory allocation)
- added displistmesh_copyShared function to copy a DLM but not duplicate any
internal data
- changed crease drawing to use DerivedMesh functions... this means varying
edge width style of creases had to go, I replaced by using varying color to
show crease weight instead. Don't think this is a big loss since the subsurf
result gives you a much better indication of the crease weight anyway.
- bug fix in mirror modifier, didn't copy edge creases from editmesh correctly
- remove python access to Optimal and Subsurf flags (they don't
work this way anymore, I suppose need to replace with python
access to modifiers but not going to do right now).
- removed interface access to OPTIMAL mode, needs to be rethough...
this means at the moment subsurfs outside editmode always draw
and render all edges
Blender.NMesh.GetRawFromObject through a displist conversion method as used by
Blender when converting them in the UI.
Notes: Objects with only edges (3D curves/polyline without bevel) do not have
normals, so they are all initialised to (1, 0, 0) on conversion
Converting from meta objects only work on the "mother ball". That is,
the object with the lower base name.
Example: "meta" for all the "meta.*" objects.
Meshes extracted from curve based objects (Font/2D filled curves)
contain both the filled surfaces and the outlines of the shapes.
Materials are taken from the object's material list. Material handling
in NMesh is incorrect anyway, as it always uses the materials from the
mesh, ignoring the setting in ob->colbits.
This patch also makes the include order a little clearer.
A couple of warnings have been fixed by using better types:
- Using char instead of short when parsing color values.
The "constructor" expects and uses char anyway.
- Explicit casting to short when storing normals back in mvert.
- Changing constant doubles to floats with "f" to make compiler happy.
The only warning left regards NMFace.flag which is stored as a short but is
used to fill in TFace.flag which is a char. I didn't want to change the
object's structure so I left it like that. I didn't add an explicit cast when
putting it back in TFace so that the warning can remind us that there might be
something to change there.
with MSVS 8)
- broke mesh_create_shadedColors out of shadeDispList, used to
build vertex colors for mesh in vpaint as well (also fixed
bug where they were not initialized correctly for subsurfs)
- added modifier_copyData and modifier_findByType functions
- change editmode modifiers to only calculate if Realtime and
Editmode bits are both set, makes more sense for copying
modifiers
- update object_copy to correctly copy modifiers
- removed duplicate redefinition of ME_ attributes in python,
this is a horrible idea, why was it done in the first place?
- update armature auto vertex group code to check for subsurf
in modifier stack
- fixed flip_subdivision to work with move to modifier stack
- added copymenu_modifiers, can copy all modifiers or just
data from first modifier of a certain type (not sure how
to deal with multiple modifiers of same type... not
a big issue though I think)
to normalised coordinate (convention in blender, helps with
halo)
- removed vertexnormals(), vertexnormals_mesh()
- removed CTX_NO_NOR_RECALC (always assume already calculated)
- change NMesh.c to call mesh_calc_normals
- chance load_editMesh to call mesh_calc_normals after done
converting instead of using editmesh normals
- update recalc_editnormals to also calc vertex normals (whats
4 more adds and a sqrt among friends)
Its hard to believe, but it just might be the case that there
are only two places mesh normals are calculated now (renderer
and kernel)
and this is better left to user (whee this was a fun commit! so
much deleting!)
- removed mesh_calculate_vertex_normals (replaced by mesh_calc_normals)
builds new DerivedMesh... caching can come later)
- split DerivedMesh returning functions into editmesh and mesh groups
- got rid of DL_NORS displist type (get built on fly for mesh when
needed)
- got rid of Mesh.disp (yay!)
- started to punch DerivedMesh returning functions into shape to introduce
modifier stack
- Mostly this cleans up the #includes and header files in the python project.
- Warning fixes are mostly casting issues and misc fixes. General warning clean up.
- #include Python.h MUST come as the first include to avoid the POSIX redefine warning in the unix makefiles
- fno-strict-aliasing flag added to makefile to fix a unavoidable type punning warning in types.c
which calculates texspace on demand if need be.
- removed almost all calls to tex_space_mesh
There may be a few corner cases where this goes wrong (meshes with vertex
keys) but these should get ironed out by coming modifier system.
