The python wrapper code for shape keys was really bad; whoever wrote it
(mis)read the wrong section of blender's codebase and got the totally wrong
idea. The code was definitely broken to the point where either it had to be
fixed for 2.45, or else the entire keyblock wrapper would have to be removed
from the stable branch. The fact that it didn't crash is just sheer luck;
the code assume mesh keys were MVerts, when in fact mesh keys are just
arrays of three-float vectors.
So shapekey data can now be editing directly, and is exposed as Mathutils.Vectors.
Also I updated the epydocs to explain how it all works now.
The actual "bug" is much more general than simple viewmove. In fact, any time the center (for viewmove, or transform, or ...) on which initgrabz is called was behind the camera (in perspective, then), all mouse motion where reversed.
What I added is a special handling case that reverts those situation to the default case (center = viewport offset).
This changes the behavior for those case to something much more predictable/useable, but I doubt anyone expected it to work incorrectly, so I'd say that's alright.
This covers other cases than transform and viewmove (which are the only ones I really tested), but I don't expect breakage elsewhere.
If anyone disagrees with the change, feel free to offer a better solution.
- nicer drawing of highlight for bookmarks
- fix slight positioning issue of bookmark highlight
- resetting bookmark highlight when mouse outside bookmark area
- cleaned up define that isn't needed anymore
This commit replaces the old function used to draw time node
user interface with new one. This should fix the issue. The
function can later be reused time node for material node
system.
Mat3ToScalef and Mat4ToScalef
These return a floating point scale value which is the average of the 3 axies.
Use this to adjust curve radius when applying scale/rot
Bugfix:
The mem cache limitor didn't take mmap-allocated memory into account,
resulting in effectively disabling it, since all imbuf-data is
currently allocated using mmap.
Initial commit of imagebrowser in trunk.
BIG COMMIT!
Main changes:
* completely reworked imasel space
* creation and storage of the preview images for materials, textures, world and lamp
* thumbnails of images and movie files when browsing in the file system
* loading previews from external .blend when linking or appending
* thumbnail caching according to the Thumbnail Managing Standard: http://jens.triq.net/thumbnail-spec/
* for now just kept imasel access mostly as old imgbrowser (CTRL+F4, CTRL+F1) a bit hidden still.
* filtering of file types (images, movies, .blend, py,...)
* preliminary managing of bookmarks ('B' button to add, XKEY while bookmark active to delete)
More detailed info which will be updated here: http://wiki.blender.org/index.php/User:Elubie/PreviewImageBrowser
Places that need special review (and probably fixes):
* BLO_blendhandle_get_previews in readblenentry
* readfile.c: do_version and refactorings of do_library_append
* UI integration
TODO and known issues still:
* Accented characters do not display correctly with international fonts
* Crash was reported when browsing in directory with movie files
* Bookmark management still needs some UI work (second scrollbar?), feedback here is welcome!
Credits:
Samir Bharadwaj (samirbharadwaj@yahoo.com) for the icon images.
Many thanks to everyone who gave feedback and helped so far!
The conversion from float to char (byte) was not correct. It should include
the possibility for colors like 0.999999 to become 255 still. The correct
multiplication factor I don't know though... and this should become a system
wide definition!
Outliner "make local" was not coded properly. Removed it for now...
Proper implementation would check all other used pointers, to indicate
the data is now local, and ID pointers should be of type "lib extern"
This commit ports Hue Saturation Value node to the material node system.
Unlike in composite version, each value is an input. Composite node version
will be updated later to use the same scheme.
for shading if their 'visibility factor' is below 0.001. This
gives no perceptible visual difference in my tests, but can
significantly speed up shading when using lots of omni lights
with quad falloff over a large area. Since quad lamps never
actually fall off to 0, previously every lamp would be considered
for shading each pixel, even if such lamps had a tiny falloff
distance, and were miles away.
