BPy conventions were not being followed for PyObject_New;
now they are. I still doubt the usefullness of doing this,
however its important to maintain module standards.
Which reminds me, anyone know where I can get that source code
prettier that was used on the api files? It was kindof
hard following the coding style of bpy with it being so
different from normal blender, and also what with having
to write the IDProperty code from scratch. :)
Another bug from the tracker, reported by Mike Stramba.
A duplicated Py_XDECREF in the wrong place made assigning
arrays from Vector objects not work.
Also, fixed nasty bug in C API of idproperties (the function
to look up a property from a group was broken). Fixed a memory
leak too.
In addition, made "del group['property']" delete properties
from group; previously this would just crash (or at least it
should have). Added a small addition to the example in the
epydocs for IDGroup.
Fixed the bug of "print type(property)" crashed blender;
just needed to add PyType_Ready init code for all ID property
python types; I made a function IDProp_Init_Types and put
code to call it in types_initAll().
Also added GPL/BL headers to idproperty files.
Misspelled __members__ __member__ in IDProperty's
getattr function; this made "print dir(prop)" not
work. Eventually I need to replace the whole thing
with getsetters.
Still need to find out why "print type(a_property)" crashes
blender. :S
IDProperties was doing a name check where it shouldn't;
thise made executing "prop['value'] = something" not work
if the property 'value' already existed. Fixed it by
making the code replace existing properties, like it
should.
This update changes Object.properties to Object.game_properties
(as discussed) so .properties can be used for ID Properties.
This should be fine as, after all, .properties was undocumented anyway :)
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.
==========
Bugfix #4951: This might be a serious change for python script writers.
-- ob.getMatrix('localspace') did not return the correct matrix when the object
had a parent; this has been corrected.
-- ob.setMatrix(m) did not work predictably (more correctly, in an easy-to-
predict manner) when an object had a parent. The method has been changed
so that if thee is a parent, it ASSUMES the matrix is "localspace",
relative to the parent. The documentation now states this.
-- ob.mat and ob.matrix are now read-only attributes, while ob.matrixLocal
(which calls Object_setMatrix() ) is now read-write.
Ton is not thrilled (is that a fair summary, Ton? ;-) with this method since
the ob->obmat is calculated from the loc/rot/size attributes of an object.
I'll let him speak on this, but I believe his desire is for this method to be
deprecated in the future and replaced with something else.
The epydocs are now updated to have idproperties;
all the modules that have bindings for ID properties
now has docs for them. E.g Materials have a .properties
members, Image, Texture, Scene, Object, NMEsh, and Mesh.
I realized that .properties was already taken in
Objects, so I renamed it to .idproperties. There was
also a nasty little problem with an example inside
Object.getType; the entire example was being pasted inside
the return field. I fixed it by just moving the return
definition to after the example, like it should be.
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
Using acos(dot(u, v)) to find the angle between two vectors is quite
inaccurate, and there's a better way to do it, as explained here:
http://www.plunk.org/~hatch/rightway.php
Also changed the use of atan for computing roll to atan2 in some places,
the latter avoids accuracy and division by zero issues.
I wonder how this survived so long in Blender... (2005/03/09 commit).
Reason was the call to BPY_free_screen_spacehandlers(sc) in kernel,
which was freeing up scripthandlers in a weird way. That call is
really obsolete. The real freeing should go in the del_area() call,
to prevent copying and deleting area in the UI to go wrong.
(Crash happened in testing timeline markers, and holding CTRL+Uparrow
a while...)
IDProperties now have a sanity check to prevent different ID properties
in the same group from having the same name. The appropriate code has been
added to the python bindings to catch this and raise an error.
This commit adds a new constant dict to the top Blender module
called PropertyTypes. This dict represents all the ID Property
constants: STRING, INT, FLOAT, ARRAY and GROUP.
Further python work, including epydocs, are forthcoming.
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.
This commit adds supports for per-ID properties to blender.
See http://mediawiki.blender.org/index.php/BlenderDev/ID_Property
for more information on how it all works.
ID properties are accesable by python; but note that
bindings have only been added to Object and Material thus
far. However adding more bindings is easy and I plan
on adding several more hopefully within an hour of this inital
commit.
A generic UI panel is also planned, that will go wherever its
needed; for example in the material buttons, editing buttons, etc.
I'll likely submit the initial code for that as a patch, though,
so matt and ton and others can go over it and make sure it's
all good. :)
VERY important, if you intend to use ID properties please
go to http://mediawiki.blender.org/index.php/BlenderDev/PropertyStandards
and start writing the appropriate standards for it.
Bugfix #4989: some Python types were not correctly initialized, resulting in
segfaults when "type()" was used. Added missing initialization to Type.c.
Thanks to Fernando (fbs) for tracking this down.
