* Moved render layer-specific Freestyle options to a separate "Freestyle"
tab (in addition to the "Freestyle: Line Style" tab that has been introduced
in the previous commit).
* Added UI controls for specifying feature edge selection criteria in the
Parameter Editor mode. Feature edge selection starts with a set of all
feature edges in the view map. Each line set specifies edge selection
criteria (e.g., to select only visible crease edges) by enabling appropriate
UI controls (e.g., by turning on the "Crease" and "Visibility" toggle
buttons). Selected criteria are combined by logical conjunction. Logical
disjunction (e.g., "crease edges or contours") is represented by two or
more line sets.
* Slightly rearranged several UI controls in the Python Scripting mode.
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 started off doing pointcache debugging but it's also very useful for users too.
Previously it was very hard to see the state of the system when you're working caches
such as physics point cache - is it baked? which frames are cached? is it out of date?
Now, for better feedback, cached frames are drawn for the active object at the bottom
of the timeline - a semitransparent area shows the entire cache extents, and more
solid blocks on top show the frames that are cached. Darker versions indicate it's
using a disk cache.
It can be disabled in general in the timeline View -> Caches menu, or by each individual
system that can be shown.
There's still a bit to do on this, behaviour needs to be clarified still eg. deciding what
shows when it's out of date, or when it's been played back but not cached, etc. etc.
Part of this is due to a lack of definition in the point cache system itself, so we should
try and clean up/clarify this behaviour and what it means to users, at the same time.
Also would be interested in extending this to other caches such as fluid cache,
sequencer memory cache etc. in the future, too.
Minipatch to add the Origin button in the Toolshelf in the Transform section.
I missed this because
1) it was called "center" in 2.4 and it's difficult to find just searching if you don't know it's "origin"
2) it was in the the object » transform menu, not very practical to use often
Discussed with Gensher, Campbell and Matt before committing :)
Add Convert operator and button (missing in 2.5)
Fix stroke selection (uneeded separate operator and missing redraw)
Map sketch operators to LEFTMOUSE and RIGHTMOUSE instead of SELECTMOUSE AND ACTIONMOUSE (more in line with other sketching operators, might work better with swapped mouse buttons)
- release/scripts/ui/space_userpref.py
added the change to add a 'warning' field to bl_addon_info
warning icons are used to show 'broken' scripts or warnings
asked permission to campbell and matt in blendercoders to apply this
- source/blender/python/doc/sphinx_doc_gen.py:
small fix in the url
path -> filepath (for rna and operators, as agreed on with elubie)
path -> data_path (for windowmanager context functions, this was alredy used in many places)
a bit arbitrary but with most cases where solidify is used in durian we get UV texture stretching since there is no way to access the newly created size faces this gives us a way to switch out the material on the rim.
- added relative option to saving external multires data
- renamed multires external functiosn to have save / pack as suffix.
- added TODO's for file select operators that should support relative paths but dont.
- also disable openmp on linux cross compile, mingw currently isnt linking -lgomp
* Now it displays the last report from the global list, not just from operators
* Rather than disappearing when a new operator is run, it stays until it times
out or a new report is added
* Fun animated transitions ;)
http://mke3.net/blender/devel/2.5/reports_header.mov
Now need to investigate report usage with popups. Ideally we can have most
reports non-blocking, so they're less intrusive, only popping up for dire errors.
Problem is many things in Blender right now are marked as RPT_ERROR
when probably RPT_WARNING is more appropriate. Should probably keep
RPT_ERROR for things that demand immediate attention.
clear properties operator
- now it's not part of the copy properties anymore (Matt's suggestion).
If anyone want to change the menu, please help yourself (renaming, putting in it's own submenu, making it invisible when mode is not Game ..)
Request from mindrones :)
* Next to the Wiki URL, it's now possible to have a link to the tracker, for bug reports.
"bl_addon_info" dictionary:
* Renamed 'url' to 'wiki_url'
* Added 'tracker_url'
* Path drawing now works for non hair particles.
* Should fix the following bugs too:
[#21316] Hair weight drawing is wrong
[#21923] Consistent Crash When Rendering Particle Scene.
[#21950] Path rendering option for particles causes crash
1) Fixed some weird formatting introduced during math-lib cleanups, and some other inconsistencies
2) Optimised the Maintain Volume constraint by taking the value calculations out
Copy All Constraints Operators:
* Added one for bones too
* These are now included in the menus
* Removed some weird/extra code copying/changing/bleh the actcol/totcol stuff...
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.
Now, rather than the bit-too-alarming stop sign, threaded wmJobs
display a progress indicator in the header. This is an optional feature
for each job type and still uses the same hardcoded ui template
(could use further work here...).
Currently implemented for:
Render - parts completed, then nodes comped
Compositor - nodes comped
Fluid Sim - frames simulated
Texture Bake - faces baked
Example: http://mke3.net/blender/devel/2.5/progress.mov
- own mistake in scene help text.
- rename properties to have users as the prefix for better ordering.
- use fixed height for stamp, gives better aligned text.
