patch from jean-michel soler (jms) - .insertShapeKey()
Python API, a function to insert a shape key in an object . It works on Mesh, Lattice curve ans surface .
Example of use :
import Blender
OBJECT=Blender.Object.GetSelected()[0]
OBJECT.insertShapeKey()
a docstring to follow soon
Added Mesh.Modes() function, which allows scripts to get/set the selection
mode settings for meshes. This was necessary in order for the mesh tools
such as triangulate, remove doubles, etc., to work properly.
to get the current value of the IPO shape key. There are still some issues
to discuss as to whether methods/attributes should be used and what they
should be named, but this will (or should) be addressed in the upcoming API
rewrite.
(with make, need to confirm with scons)
after cleaning the changes are in fact minimal, but the situation
is still quite a bit hackish.
Game engine coders, there is also quite a number of warnings that
need to be fixed.
current situation is that everything seems to work, but GLSL shaders
spew a lot of errors on console and blender may crash on exit when
a GLSL shader was used. ARB stuff works fine.
Campbell, most of the changes you made seem ok, but you do have to be careful since it's not just about looking good, it's also about grouping things meaningfully. We did some thoughts on more concrete guidelines for this here: http://mediawiki.blender.org/index.php/BlenderDev/UIAlignRulesGuides
- minor: added missing theme options (bone_solid, bone_pose, strip,
strip_select) to Blender.Window.Theme and also updated accordingly
(version info) the script that saves themes as scripts and the module's
doc.
Aligned filesel buttons|text entry- looked arse also.
Added tooltips for filesel text entry- "Type in dir to create" and "+/- increment" or somthing like that.
- Cam
remove constraint fixed,
Bullet timestep now subdivides Blender game engine timestep, so it runs 60 hertz,
SphereShape reverted to old style, so no support for non-uniform scaled spheres for now,
in the BPy API for the "end point". It was a minunderstanding of what
happens with cyclic Ipos, but we updated the documentation to make this
clearer in the future.
This is using instructions from Ton, so hopefully the implementation is ok.
This is really needed here where we are using all sorts of wacky scales, and
empties look too big or too small. Of course we don't want to scale the
empties because there are often things parented to them.
New options are in edit buttons for empties to control the display style
and the size. New styles are easy to add, too. Just needs useful ideas and
minor effort from anyone who wants to.
Support for copying these values has also been added to the Copy Attributes
->Drawtype menu command.
causing render to crash on cygwin with gcc 3.4.4. Changed
declaration of shadepixel() argument "int facenr" to volatile.
Can anybody recommend a more elegant solution?
- cleanup of color curves code; goes at least twice faster now!
(includes black/white point stuff)
- When using 'Curves' in image window on a byte rect, it creates a (temp)
float rect to operate on. So curves work for regular pictures too now.
Vector.resize4D() didn't put 1 in the 4th component (the scale factor), as it did in 2.37.
While this is more "correct", it is much less usefull. Also, matrix.resize4x4 puts a 1 there too,
so might as well revert and be consistent.
Until now, the zbuffer was written straight from the internal zbuffer,
which has values that are inverse-proportional (like 1.0/z) which makes
it very hard to use it for postprocess, like zblur or other composit effects
that require Z.
Based on info from ILM, the values stored for Z in exr files is the
actual distance from a camera. I think that's about time to migrate to that
convention!
By default now, after render, the z values are converted to floats. This
saves in exr files now, but not in the Iris Z files. That latter was a
blender-only anyway, so might be not a real hassle to drop. :)
You can see the difference in the image window, but notice the range now
is linear mapped from camera clipstart to clipend.
Note; I just discover that ortho Z values need a different correction...
