Conflicts resolved:
source/blender/makesrna/RNA_enum_types.h
According to the changes in revision 35667, the Freestyle-related code
in release/scripts/ui/ was moved to release/scripts/startup/bl_ui/.
Now this gives the line number of the scripts thats running, eg:
uiItemFullO: unknown operator 'some.operator'
/c/bin/2.56/scripts/startup/bl_ui/space_view3d_toolbar.py:73
* Effecting particle properties with textures was possible in 2.49,
but not in 2.5 anymore.
* Now particles have their own textures (available in texture panel
for objects with particle systems), which are totally separate from
the material textures.
* Currently a basic set of particle properties is available for
texture control. Some others could still be added, but the whole
system is not intended as an "change anything with a texture" as
this kind of functionality will be provided with node particles in
the future much better.
* Combined with the previously added "particle texture coordinates"
this new functionality also solves the problem of animating particle
properties through the particle lifetime nicely.
* Currently the textures only use the intensity of the texture in
"multiply" blending mode, so in order for the textures to effect
a particle parameter there has to be a non-zero value defined for
the parameter in the particle settings. Other blend modes can be
added later if they're considered useful enough.
- values were added to both the classes __dict__ as well as the internal StructRNA.
- made properties available from the type since this is where the python api assigns them:
>>> bpy.types.Scene.frame_start
<bpy_struct, IntProperty("frame_start")>
- rename RNA_struct_type_properties() -> RNA_struct_type_properties(), added RNA_struct_type_find_property()
when using the Numpad0 feature to reset properties to their default
values.
While this implementation here is not a full/proper implementation, as
you cannot truly specify a default value for some pointers that may
require something other than NULL (i.e. nothing), this should be good
enough for the vast majority of (editable) cases which are fine if set
to NULL.
This is most noticeable with the Active Keying Set field in the
TimeLine header, where it's now possible to simply use Numpad0 to
clear it instead of using a confusing click+backspace+enter dance to
do the same thing.
A note for branch users: CMake 2.8 on 64-bit Windows Vista raised
an error in line 948 of soc-2008-mxcurioni/CMakeLists.txt due to
an invalid argument for the blender_include_dirs macro:
blender_include_dirs(${OPENGL_INCLUDE_DIR})
The command above should be:
blender_include_dirs("${OPENGL_INCLUDE_DIR}")
from Dan Eicher (dna)
This allows automated node tree creation and editing.
developer note, made some changes to the patch.
- removed incorrect use of container_of(), GCC only also, search for the scene instead.
- commented socket min/max access, these are internal use only as far as I can tell.
- commented group/ungroup functions, these use the selection context and are not really data level functions.
- use remove() rather then delete()
Simple python benchmark shows this to be about 3x faster in the case where an update isn't needed.
This also speeds up rna function argument parsing, since each arg in a function call did 2 string lookups on the context which were never needed.
Import unit_settings to scene.
Note: I use here RNA to do this, and I think I might slowly work on replacing low-level DNA usage with RNA where possible.
An example of how this is useful - an importer mixin could define the filepath properties and a generic invoke function which can run the subclasses exec for each selected file.
- Panels and Menus now skip the property check when registering.
- renamed _idproperties_ to _idprops_ in function names, function names were getting very long.
A number of UI elements were newly introduced to control line color, alpha
transparency and line thickness by means of base color/alpha/thickness plus
modifiers that alter the base values. To begin with, three basic modifiers
were prototyped with the aim of putting the new UI framework in practice
and evaluating if it works properly.
The Parameter Editor mode is still in a work-in-progress state and totally
useless from users' viewpoint.
This commit is just meant to give the new GUI framework a concrete shape.
There is no usefulness in newly introduced elements at the moment.
Freestyle options in render layers now include a pull-down menu named Control
Mode that allows you to choose either the Python Scripting or Parameter Editor
mode. The Python Scripting mode is the conventional way of controlling
Freestyle by directly using style modules written in Python. The Parameter
Editor is a new control mode that is intended to be used by everyone without
relying on Python programming.
In the Parameter Editor mode, you can specify multiple line sets for each
render layer. A line set defines feature edge selection criteria, as
well as a line style for drawing the selected feature edges using specific
line stylization parameters. Line style is a new datablock type, meaning
that a line style can be shared by multiple line sets (possibly those in
different render layers in different scenes).
Much more additions are anticipated in subsequent commits to implement UI
controls for specifying feature edge selection criteria and line stylization
parameters.
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.
