User:Fiddle~enwikibooks/Blender

"Blendo" Model re-rigged for Blender 2.40
Recently the BlenderChar website was taken down due to lack of new contributions. Unfortunately, Lyubomir Kovachev's "Blendo" model is therefore no longer available there. Weirdhat challenged someone to rerig Blendo, using the new Blender 2.40 armatures; so, here it is (link will be added here; pending permission)

This is basically the same rig as Lyubomir's original - I have only taken out the null bones (which aren't needed any more), and ensured that all IK chains have the correct length.

The principles of Lyubomir's are decribed in his tutorials which are in the official Blender documentation. The position of each hand is set by the target IK_hand; the position of each of the fingers is determined by IK_fing1, IK_fing2, IK_fing3 and IK_thumb. Since these IK targets are parented to the IK_hand target the relative position of the fingers stays the same even when the hand is moved (Of course, there is a .R and .L version for each of thses targets).

For the feet, the overall foot position is determined by IK_foot. This target has two children: IK_heel and <tt>IK_toes</tt>, which govern the position of the heel and toes (surprisingly) relative to the foot as a whole. This allows you e.g. let the character walk on tiptoe by raising the heel but leaving the toes on the floor.

Note: Lyubomir's original rig used Null bones to connect IK target to tips of bones, and applied the "Copy Location" constraint to connect the IK-chains with each other. In the new setup this is no longer necessary, so that for instance the toes are now connected to the foot bone in a single hierarchy. One consequence (which can be either an advantage or a drawback depending on your animation style) is that it is no longer possible to create some of the stretch of the feet that one could with the original rig.

If I have time I'll attempt to add some more new sophisticated features, like mesh deformation for facial animation.

As a start here are some simple example poses created with the new rig:

Thoughts for Blender 2.50
I have been developing some ideas for improving the internal structure of Blender. For now these are unstructured ideas, which I will summarize here. As soon as I have thread connecting these, the best place to submit these I think is for Blender 2.50

Events
The new event structure could have the following elements

where the attributes have the following meaning: Anything else, that I've forgotten? The idea is that a sequence of interfac (keyboard/mouse) events will get translated into a single COMMAND event Each COMMAND event corresponds to a Python command so that a Python log can be created of the things that the user does interactively, similar to macro recording in Visual Basic in Excel for instance. The Pytohn API model needs to be agreed I am not too familiar with MEL used in Maya but I assumed this is similar. Vice versa, execution of those Python function calls is equivalent to processing the corresponding command events (at this point I don't know if ALL python function calls should have a corresponding COMMAND - or other type - event, but this is something to be considered).
 * type  eg. COMMAND, KEYBOARD, MOUSE, other
 * event, eg. KEY_UP, KEY_DOWN, MMB_UP, RMB_DOWN, MOUSE_MOVE
 * modifiers, eg SHIFT, ALT, CTL and bitmapped combinations where MAC CMD mapped on CTL etc
 * time system time of event
 * command: depends on listener for this event (only when type=COMMAND)
 * listener: editor to which command is sent, could be windowmanager (only when type=COMMAND)
 * mousex: x coordinate of mouse (in window coordinates)
 * mousey: y coordinate of mouse (in window coordinates)
 * window: window in which mouse was when event occurred

Spaces
Currently adding new spacetypes in Blender is quite painful. My idea is that a space is a fully self contained editor which is identified by the SpaceType pointer which points to the SpaceType structure which contains all the external functions as function pointers. This means that the C namespace of a spacetype could be completely local (i.e. if you could implement all functionality in one file ALL functions would be static) The only thing that is visible externally is the SpaceType structure and perhaps the init_spacetype_xxx function.

As a start I have added all the xxx_buttons functions to the space type. So as an example, I created a new pws spacetype as follows:

extern void changeview2dspace(ScrArea *sa, void *spacedata); // defined in space.c

where

Now the simplification is in editscreen.c:

I would like to build on this further