These are for use in pose mode or armature edit mode, to let you quickly traverse up and down a chain of bones.
It's quite useful for bones that are in hard-to-click places.
The tools are:
*Select parent/child ( [ and ] )
selects the parent or child of the active bone, deselecting the original active bone
* Extend select parent/child (shift [ and shift ] )
selects the parent or child of the active bone, adding to the selection
Thanks to Joshua for reviewing this so promptly!
PS. I'd like to use these [ and ] keys more widely in blender as consistent 'select next / previous' tools. I can imagine it being very useful for a lot of things like keyframes, nodes, mesh edges, etc.
* Material.c - functions for get/setRayTransGlossSamples were not being used.
* BPY_interface.c - removed function GetName(), since everything else just uses id->name+2.
* header_info.c - added ifdef win32 around copy_game_dll since its not needed for other os's yet
This fixes:
[#16655] Blender crashes when Fraps videos are added to the sequencer
(sorry, color conversion is not supported by swscaler for some reason,
so currently, only the crash is fixed)
Fixes:
[#15082] Sequencer: for image strips, the Input file field disappears if the cursor is out of the selected strip
also it wasn't really a bug, since the file name of image input strips
_has_ to depend on CFRA.
Well, we choose the next possible image strip, which is most likely the thing,
most people expected...
This fixes:
[#17405] Sequencer: unselected black strips are unreadable
using
[#17418] Fix for bug #17405: unselected black seq strips text unreadable
Thanks to Roelf De Kock for providing the patch and
mindrones for the bug report :)
Some WIP code for 'nicer' drawing of thick 2d-strokes that will hopefully result in smoother lines, particularly with abrupt direction changes. Currently the code is hidden behind the rt button (for rt != 0), as in some cases, it still looks rather bad.
Under Windows, all DLLs are copied to the same folder as the runtime .EXE, so that the process becomes a single click and deploy solution.
Linux doesn't require this ( thx for info centralnoise ) and will update to work on OS/X after I do a bit of research on .a and .so files ( thx for info kaito ).
Doh - I forgot to add a comment to the previous commit.
This adds a file exists check for Make Dynamic Runtime for the GE. It also removes this menu option for now, as the required file ( blenderdynplayer.exe ) hasn't been included with the Blender app for quite a few releases ( therefore the feature has been broken ).
I also renamed the option, to make it a bit more understandable. This might even be better moved to the Game menu, but I didn't want to do that ( yet :) )
Improved accuracy of the eraser a bit. Now it does a boundbox test first before trying to erase strokes, which means that other (rather unrelated) strokes are less likely to be affected as well.
With this patch, only sensors that are connected to
active states are actually registered in the logic
manager. Inactive sensors won't take any CPU,
especially the Radar and Near sensors that use a
physical object for the detection: these objects
are removed from the physics engine.
To take advantage of this optimization patch, you
need to define very light idle state when the
objects are inactive: make them transparent, suspend
the physics, keep few sensors active (e,g a message
sensor to wake up), etc.
This commit introduces the ability to erase strokes. Admittedly, the code for this is not totally stable yet, and doesn't always produce optimum results. I'm committing now for backup purposes.
It currently uses the lasso code to check whether segments of the strokes (a segment occurs between two recorded points) occur inside a region defined by the 'eraser' stroke, or any intersections it makes with the 'eraser' stroke.
There are multiple ways to erase strokes:
* With 'Draw Mode' on, use RMB-drag to erase
* With a tablet, use the 'eraser' end of the stylus
* Hold the Alt Key, and use the 'selection' mouse-button (i.e. LMB if mouse-button swapping is on, RMB otherwise) to erase. For this one, this is necessary to avoid overriding the view-rotation hotkey combo for 2-button mice!
Todo:
* 3d-strokes are not correctly mapped back to screen-space for sampling yet
* Drawing of eraser strokes is still not distinctive enough
* After running a few times, may cause stack corruption/segfaults, so be careful!
== Bugfixes ==
* Grease-Pencil Onion-Skinning works again. Onionskining was being supplied the wrong frames, and the alpha factor was still the old one used for 0-255 ranged colour values
This includes...
- Renaming dLoc and dRot as Loc and Rot ( as well as changing the tooltip to location and rotation ). dLoc and dRot are programming terms, not user terms.
- Placing Loc and Rot as the two initial shown values, so that the physical ones are all shown together.
I also changed it so that only Loc and Rot are shown in the UI, unless the object is Dynamic ( as the other values only make sense if it is dynamic ).
These are just a few simple changes, that should make a lot of difference to users when learning how to use the GE.
--------------------------------------
Things I'd *really* like to do to this, when I get a chance to code Blender again ( hopefully in a few days time, after I have finished teaching on the GE course )...
Color / Colour tint the X,Y and Z entry boxes as slightly red, green and blue, to reflect the colour of the axis / transform gizmo
...or...
Just show X,Y and Z labels above all of the values.
Getting to grips with the whole XYZ thing is very confusing for users, esp when they are presented with 6 x 3 entry boxes.
There existed two options to copy only the mass, and only the damping, but no option to copy all of the physical attributes.
This patch adds in this option, right under the Mass and Damping listings.
This one deals with the very small default clipend value ( 100.0 ) when pressing P to run the GE from a non-camera view. ( ie if the user zooms out a bit from the default box area, the box will get clipped out of view, so it's a WFT from the user )
To see what this fixes, load up Blender default scene, go into perspective, and press P. Everything looks grand. Now, zoom out until the box is about 10 pixels high, and press P again. The box will disappear / be clipped out.
I've set the clip end to the maximum ( 5000 ) as defined in Camera.h.
This should be suitable for inclusion in 2.47 branch also.
=======================================
Alpha blending + sorting was revised, to fix bugs and get it
to work more predictable.
* A new per texture face "Sort" setting defines if the face
is alpha sorted or not, instead of abusing the "ZTransp"
setting as it did before.
* Existing files are converted to hopefully match the old
behavior as much as possible with a version patch.
* On new meshes the Sort flag is disabled by the default, to
avoid unexpected and hard to find slowdowns.
* Alpha sorting for faces was incredibly slow. Sorting faces
in a mesh with 600 faces lowered the framerate from 200 to
70 fps in my test.. the sorting there case goes about 15x
faster now, but it is still advised to use Clip Alpha if
possible instead of regular Alpha.
* There still various limitations in the alpha sorting code,
I've added some comments to the code about this.
Some docs at the bottom of the page:
http://www.blender.org/development/current-projects/changes-since-246/realtime-glsl-materials/
Merged some fixes from the apricot branch, most important
change is that tangents are now exactly the same as the rest
of Blender, instead of being computed in the game engine with a
different algorithm.
Also, the subversion was bumped to 1.
Bone-locking should only be set if the bone (and not its parent/children) are selected. Transposition error from the patch (I had to manually apply as there were some oddities about the patch file).
The pasting code for text-buttons (when hovering over the button), was incorrectly using the drawstr (i.e. the string that is displayed in the text-button, and includes the 'name' of the button) as the old value. This meant that the renaming code could not correctly detect matches to rename.
This bug-report revealed a critical error made in the menus for Constraints Owner/Target spaces. It seems that the wrong values have been used for 'pose space' and 'local with parent' space. This has now been rectified, so that old rigs won't break (just that the labels will be a bit different).
Submitted by: Lorenzo Pierfederici (lento)
This patch adds the ability to lock transformation on bones in edit mode, to protect them from accidental editing.
Bones can be locked from the editing buttons, the transform property panel, the specials popup menu or the python api.
This now works even when there is a proxy-protected bone selected with a few differences.
* The Transform Locks, IK-Flags, and Custom Bone Shape settings are unavailable, as they would be reset by the proxy protection anyway
Also, the Copy Constraints options have been altered so that they do NOT free all existing constraints on the target bones before copying.
* Constraints are now appended to the end of the constraint stacks, with those added to bones belonging on proxy protected layers getting tagged as 'local' constraints.
* This is more useful for riggers than the previous behaviour (which was quite nasty too).
Render/postrender events were missing from bg rendering (and also from rendering called inside scripts). Found this because of bug #17389, the code to prevent race conditions with pynodes is currently inside BPY_do_all_scripts (that runs scriptlinks) and so was not being called in bg mode or rendering via scripts.
http://projects.blender.org/tracker/?func=detail&atid=125&aid=17389&group_id=9
This commit attempts to fix some of the problems with the accuracy of strokes recorded.
I've disabled the post-draw smoothing of strokes as it deviated from the source stroke too much. This was introduced to try to eliminate the effects of fine 'jitter' (which is especially noticable when using optical mice + fast computer).
Now, I've introduced two thresholds which determine the 'minimum' distances that the mouse needs to have moved from the previous mouse-coordinates recorded, to be recorded. These are currently hardcoded, but may be exposed in the UI if there is significant need to do so.
- The first is for the distance that the mouse must have moved on both axes to be considered.
- The second is for the 'pythagorean' distance that needs to have been travelled by the mouse.