- rename 'no_bg' argument to 'emboss' (and negated)
- added 'emboss' option for operator buttons.
- Addon UI Layout slight modifications, changed enable/disable buttons for checkbox, grey out text of disabled addons to make it obvious at a glance whats enabled.
- column expanded enums now align text to the left.
- renamed ui_item_enum_row to ui_item_enum_expand since its used for columns and rows.
displaying lamp properties regardless of type hence causing errors. Now
active object controls what properties to display. Still it's possible to
manage multiple mixed lamps types at once. Also added useful items for
cameras and empties
Layout is now simpler, more easy to scan. This commit also simplifies the Python code and gets rid of hundreds of wasted lines of code, making it much easier to make layout changes.
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.
- #22155: keyframe dots not shown on path for bone keyframes that aren't in a group with a matching name. Since this situation is going to become more common in 2.5, I've added an option which will alternatively just search the entire action to find all F-Curves associated with bones. The old option is still the default though for the general cases.
- When keyframe drawing is enabled, the current frame will also be indicated on the path now as a (bigger) green dot, as requested by William. This makes it easier to see the position on the path on the current frame.