This constraint allows an object or bone to have their rotations applied as if their origin/pivot-point was located elsewhere. The most obvious uses include foot-roll, see-saws, but could also include more complicated rolling-box examples.
== Usage Examples ==
=== Foot Roll ===
1. Add 'Pivot' Constraint to the bone without any target.
2. Set the 'Y' value of the offset to the length of the bone. Usually this should be negative (if you rig with feet facing 'forwards' along -Y axis). This gives you a pivot point relative to the bone's (preconstraint) location, which should be at the tip of the bone here. Disabling the 'Use Relative Offset' would make this offset be relative to 0,0,0 instead of to the owner/bone-head.
3. Ensure that the 'Pivot When' setting is set to '-X Rot', (default) which means that the pivot will only used when the rotation on the X-Axis is negative to get tip-toe 'roll'.
=== See Saw ===
1. Add a 'Pivot' constraint too see-saw plank object, this time with a target that you wish to have as the pivot-point. It's possible to do this without too (as before), but is less intuitive.
2. Optionally, if you want the plank slightly raised, set the z-offset value, which should make the pivot-point used to be relative to the target with the z-offset applied.
3. Ensure that 'Pivot When' is set to 'Always', which means that the pivot will always be used, irrespective of the rotation.
== Notes ==
* The 'Pivot When' setting has been integrated in the constraint, since this is something that will often be required for these setups. Having to set up additional drivers to drive the constraint to do this kindof beats the purpose of providing this.
* The 'Offset' functionality is probably not presented as clearly as it could be. We may need to go over this again.
* For foot-roll - if any scaling of the foot is required, simply set up a driver on the y-offset to make this dynamically respond to the "scale" RNA property of the bones (don't use the "Transform Channel" vartype since that won't work correct here). However, this shouldn't be common enough to warrant special treatment.
This commit puts the ground work in place, swapping out the crusty old Logic Editor
UI code for the new RNA-based layout engine. It's disabled with ifdefs at the moment
because it's incomplete, but Dalai can now do the grunt work to fill it all out and get it running.
Also includes a bug fix to LINK buttons, and two new logic operators to add and delete sensors.
Dalai, just switch the #if 0 and #if 1 in logic_window.c:3412 and 3469
This adds MULTICAM-editing support for blender. (Well, the beginning of.)
There is now a new effect track, named MULTICAM, which just selects
one of the lower tracks.
Doesn't sound that exciting, but if you combine this with A/B-Trim (moving
split points of two directly connected tracks around, while magically
resizing both strips, something to be added), you just do:
* add several tracks for your camera angles
* (optionally) sync those tracks
* add one multicam track on top
Use that multicam-track to edit your movie. (Either using fcurves on the
multicam source selector or using knife-tool and A/B-Trim.)
Compare that to:
* add several tracks
* add cross fades between them
* do some python scripting to add several fcurves to make that beast
somewhat work.
* cry out loud, using it, if you have to move cut points around
Alternatively, even harder:
* just edit the old way and put strip after strip
You might think, that this isn't really helpfull for animators, but
consider using scene-strips (in OpenGL-mode) for input, that are set for
different camera angles and can now be intercut a lot more easily...
Also: small fix on the way: the speed effect can now be used in cascade.
(Don't know, if anyone used it that way, but now it works.)
by Xavier Thomas
This adds the waveform monitor and vectorscope to the image editor 'scopes'
region, bringing it inline (plus a bit more) with sequence editor functionality,
and a big step closer to the end goal of unifying the display code for image/
comp/sequence editor. It's non-intrusive, using the same code paths as
the histogram.
There's still room for more tweaks - I modified the original patch, changing
the openGL immediate mode drawing of the waveform display to vertex arrays for
speed optimisation. Xavier can look at doing this for the vectorscope now too.
Thanks very much Xavier!
This patch add SPH (Smoothed Particle Hydrodynamics)fluid dynamics to the
blender particle system. SPH is an boundless Lagrangian interpolation
technique to solve the fluid motion equations.
From liquids to sand, goo and gases could be simulated using the particle
system.
It features internal viscosity, a double density relaxation that accounts
for surface tension effects, static internal springs for plastic fluids,
and buoyancy for gases.
---------------------------------------
This is a commit of the core fluid physics. Raul will work on proper
documentation soon and more features such as surface extraction from
the particle point cloud and increasing stability by sub-frame calculations
later.
didnt commit this patch because curves are generally better to create a shape to lathe however now that curves can have modifiers applied to them I think its good to have this.
Added options to offset the lathe so it can work like the screw tool as well.
- optional object for axis which also controls the center point.
- screw offset so rather then just lathing this can work more like the screw tool.
- screw optionally using the object distance along the axis.
- iterations so the screw can be applied multiple times.
tested to work well with curves.
* Copy/Paste operators for F-Modifiers
Available in Graph and NLA Editors. Use the Copy/Paste buttons beside the 'Add Modifier' buttons.
Copy copies all the modifiers of the ACTIVE F-Curve or Strip depending on the editor.
Paste pastes modifiers from the buffer to all the selected F-Curves or Strips, adding the new modifiers to the ends of each list.
* 'Stepped Interpolation' F-Modifier
This modifier holds each interpolated value from the F-Curve for several frames without changing the timing.
This allows to preview motions 'on-twos' for example without altering the timing, or having to go through setting heaps of keyframes. In this case, Andy wanted to use this for CG <-> StopMo.
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
Many string properties need tweaks to work correctly with this, since many don't have any reasonable defaults set (especially name fields, which often get cleared with these changes).
F-Curves now internally store radians again instead of degrees.
- This solves problems with inconsistencies when working with drivers.
- No need to version patch old files, potentially screwing them up. As such, removed the version patching for F-Curves.
- Is better suited to optionally showing radians throughout the UI instead or degrees.
As a result, values are now converted on the fly in the Graph Editor for display and operators that operate on values. I've made the conversion system for this rather general, so that other unit type conversions can also be hooked up with the type conversion backend.
Also, made some tweaks to F-Curve RNA wrapping to make it represent the data better.
TODO:
- Transform code currently still needs to be corrected to work with these changes. Currently moving keyframes for rotation curves will make them change too rapidly vertically when using degrees.
Fixed and completed support for returning multiple values. This includes support for returning arrays, both fixed and dynamically sized. The way this is achieved is by storing an additional int value next to the dynamic parameter in the ParameterList stack which gets passed to the C function as an additional parameter. In the case of return parameters it is duty of the C function to set this int to the correct length value for the dynamic parameter (which makes sense). Note that for the dynamic output/return parameter it is assumed the function has allocated that memory (which gets freed automatically).
Also, I cleaned the makesrna's bridge function generation code a bit and renamed PROP_RETURN to PROP_OUTPUT, which represents better the reality now that there are multiple returns. The function now to mark multiple returns (outputs) is RNA_def_function_output.
For an example, look at Action.get_frame_range in rna_action_api.c, by the way Aligorith I removed the #ifdef for this function now that there's support for returning arrays, feel free to modify (the function seems to work).
* Added a generic 'histogram' ui control, currently available in new image editor
'scopes' region (shortcut P). Shows the histogram of the currently viewed image.
It's a baby step in unifying the functionality and code from the sequence editor,
so eventually we can migrate the sequence preview to the image editor too,
like compositor.
Still a couple of rough edges to tweak, regarding when it updates. Also would
be very nice to have this region as a partially transparent overlapping region...
blender supports type changing for textures in a way that python doesnt.
add a new general function.
Example usage:
tex = bpy.data.textures.new("Foo")
tex.type = 'IMAGE'
tex = tex.recast_type()
Macro to give the number of users accounting for fake user.
ID_REAL_USERS(id)
Use this so you can remove a datablock if it has a fake users as well as apply transformations to it in the 3D view.
Move api function bpy.data.add_texture() --> bpy.data.textures.new()/remove()
* Added Theme support for the console.
You can change:
-Header Color
-Text Color of Output, Input, Info and Error Messages. (Inside the User Preferences -> Themes)
* Finished baking code for motion paths, generalising it so that it works for both Objects and Bones.
It is based on the old code for baking bones, although I have modified the updating code to use a more 'correct' method of updating dependencies. However, this may turn out to be too slow, and another API method should be added for that...
* Moved some of the old version-patching code for animviz settings out of the drawing functions, instead doing this on the version patching proper.
* Added RNA support for the new AnimViz types, and included RNA access via their users too. The old settings have still been left in for now, since there are still some things not ready to use yet.
----
* F-Curve's with sample points (i.e. sounds to F-Curves) now perform linear interpolation between sample points instead of using constant interpolation.
Highlights:
* Support for Multi-Target Variables
This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that.
* New Variable Types
With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones).
* New Driver Types
In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to.
* Fix for Driver F-Curve colouring bug
Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used.
Notes:
* This commit breaks existing 2.5 files with drivers (in other words, they are lost forever).
* Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later.
* Version patching for 2.49 files still needs to be put back in place.
patch from Elia Sarti, (vekoon) with some modifications mainly for the python api.
- multiple values are returned as a typle in the order that are defined.
- added support for registered types returning multiple arguments (untested).
- renamed func->ret --> func->c_ret, since this only defines what the C function returns.
bpy.types.register(MacroClass)
instead of
bpy.ops.add_macro(MacroClass)
The rest is unchanged.
Also remove some now unused code for the old registration methods (there's still some remaining).
Mostly the same as the recently added editmode tool with some extras.
* Options to disable filling in the rim between inner and outer surface, since its faster not to detect this in cases where its not needed.
* Option to disable high quality normal calculation, mostly noticable when operating on building walls, not needed for cloth or more organic shapes.
* Option to disable 'even thickness', again, not needed in some cases.
Also options for creasing inner/outer and rim edges, need this for makign Sintels cloths solid since zero crease looks far too soft.
note:
* UVs and VCols etc are copied to the new skin however rim faces dont get the UVs or vcols set from the faces they are created from yet.
* Normals are assumed to be pointing outwards
* used patch from Uncle Entity as a template since it added the DNA and RNA entries but the actual modifier from the patch wasnt used.
Until we have proper multi-object editing, this adds a Copy To Selected
option to the right mouse button menu for Object and Bone properties, to
copy the value from the active object to the selected objects.
Also includes some implementation changes to reset to default operator.
Added a new operator for properties which resets RNA-based settings to their 'default' values, as defined in RNA. This currently only works for floats, ints, enums, and booleans (strings and pointers still need to be implemented).
The current extensions to the RNA API that I've made here seem a bit excessive, and can be toned down if necessary. In short, I've just added accessor functions for the default-values of the property definitions.
For this to be really useful, many properties in RNA will need to get defaults defined, since the current defaults for quite a few properties tested were less than ideal.
* Property update functions no longer get context, instead they get only
Main and Scene. The RNA api was intended to be as context-less as
possible, since it doesn't really matter who is changing the property,
everything that uses the property should be updated.
* There's still one exception case that use it now, screen operations
still depend on context too much. It also revealed a few places using
context where they shouldn't.
* Ideally Scene shouldn't be passed, but much of Blender still depends on
it, should be dropped when we try to support multiple scene editing.
Change was planned for a while, but need this now to be able to call
update without a context pointer.
Basic definition works like a python operator but you derive from "bpy.types.Macro" instead.
Operators are added to the macro after it has been added with "bpy.ops.add_macro" through the class method "define" which takes an operator id and returns an OperatorMacroType (new RNA type) for which properties can then be defined to be passed to the operator when run.
Example: http://blenderartists.org/~theeth/bf/macro.py
Using this system, it should be easy to add an operator to the console that converts selected lines into a macro or even a more generic record macro system.
