Attention! Rather large sequencer rewrite:
* Implemented layer blending using implicit effects. (works like layers
in "The Gimp" or Photoshop.)
* Fixed Space-Bar start-stop in preview windows.
You can start playback using spacebar within a preview-window and it _works_!
* Fixed Flip Y (didn't work for float)
* Fixed premul (didn't work for float)
* Added IPOs to _all_ tracks. In blend-mode REPLACE it drives the
"mul"-parameter in all other blend modes it drives the effect.
* you can meta single tracks.
* moved "mute track" from "M" to "Shift-M"
* added "Shift-L" for "lock track"
* changed inner workings for Metas. Now all ImBufs have to use the
reference counting mechanism. (Only interesting for coders :)
!!! Really important change, that affects current files!
Since you can mute tracks and now there is real layer blending capabilities
in place, I changed the silly behaviour that chose the output track.
Old behaviour: if we have an effect track visible, use the uppermost effect
track. If there is _no_ effect track visible, use the lowest input track.
New behaviour: always use the uppermost track. With blend modes active:
work our way down starting from the uppermost track to the first
"replace"-mode track. This is the way the gimp, photoshop, basically _all_
other applications work...
So if this change ruins your day: please try to fix your files using
"mute". If this doesn't work out, I can still restore the old behaviour,
but I really hope, that this is _not_ necessary!
Rational: most people won't get affected by this change, since you can't
really do anything usefull with the (old) sequencer without at least one
effect track and then you are on the safe side...
This means one group can contain proxy objects to display in the 3d view as well as hi quality models that are only rendered. - again for peach tree's.
* Most were uninitialised vars
* Fixed whitespace in a few places
* The change I made in rendercore.c -> do_bake_shade() was for an uninitialised var, but I hope it does't cause any rendering errors...
Based on feedback from Ton, I've recoded the way "PoseLibs" are implemented/exposed. Therefore, quite a bit of code has been changed to fit this in better.
Now, ANY ACTION can be a "PoseLib". A set of Markers which belong to the Action (it's taken a year, but they're finally back), are used to tag "poses" in the Action. These markers are shown using diamond-shaped blue icons (designed by Matt Ebb) in three shades - unselected/normal, selected, active.
Notes:
* Each Armature Object has an Action which acts as a PoseLib.
* Improved UI presented in buttons panel for this
-- added proper buttons for action assigning
-- renamed "Validate PoseLib" to "Auto-Sync PoseLib" (this option auto-tags poses based on keyframes found)
Like in the 3d-view, use the hotkeys:
* Shift-L to add a local marker
* Ctrl-Shift-L to rename a local marker
* Alt-L to delete selected local markers
Note: transforms, etc. are not currently available with these markers
== PoseLib Preview ==
Added a few features here:
* Left/Right-Arrow keys now change the poses too (previous and next respectively)
* Up/Down-Arrow keys also change the poses, but "jump" to a pose 5 steps away in their respective directions
- protecting the particle cache now actually protects the cache a bit better and not just prevent the clear button from working
- cache was being used for "none" physics.
- a bad tooltip for "reactor initial velocity"
Directional Blur node allows the users to do various blur operations on the input
image. It essentially offers three different kind of ways of blurring in one node.
It is possible to blur using a certain direction, spin and zoom. These three ways
can be used in conjunction.
The node contains following controls:
*Iterations, Wrap
*Center: X, Y
*Distance, Angle
*Spin
*Zoom
Iterations is used to determine the smoothness of the result. The more iterations,
the smoother result. Low values are good for preview.
Wrap means that the image is wrapped as if it was tiled on both x and y directions.
To see better what this means, try it with spin for instance.
Center values (X and Y) determine the location which is used as a pivot point for
the operations. It is center (0.5) of the image by default.
Distance and angle are used to adjust directional blur. The result can be described
as a sweep that varies based on given distance (bigger distance, longer sweep) and
angle. Angle is given in degrees.
Spin produces rotating blur based on given angle. Yet again it is in degrees. Also
negative values work.
Zoom causes the image to be zoomed towards set center point (Center values).
Thanks to Alfredo de Greef (eeshlo) for contribution.
Possible development ideas:
*Make an algorithm to extend image in case spin is used. Extend would temporarily
change the size of the canvas of the input image. Canvas would be filled based on
colors on the edges of the input image. After the blur operation has been done,
the image would be cropped back to normal size. The advantage of this would be nicer
result of spin (no problems with image size) on a computational cost.
*Make values animatable. This is something that is better solved on more general
level. ("everything is animatable" paradigm)
*Provide an option to calculate automatic value for iterations. A good value that
produces a smooth result could be calculated based on direction deltas. This would be
useful in conjuction of animatable values.
This commit adds a new tool, Toggle Links, to the node editor. This tool
allows the user to toggle the status (linked/not linked) between desired
sockets. The tool can be used either by using the f key or the menus.
This functionality is analogue to one found in object editing modes except
for its additional toggle functionality.
To use this tool, the user has to first select an input and an output socket.
Selecting is done by clicking with right mouse button on a socket. After the
tool has been invoked, the link between those two sockets is toggled. The
result may vary based on existing linkage.
There can be only one input and one output selected at maximum in a node
tree. This means that if the user selects a socket while one of the same
type is already selected, the old one will be deselected.
The tool complements the current way of connecting nodes. One possible use
for it is to use it to review output of nodes by using a viewer node. Just
select wanted input socket of a viewer node, set it visible and use selection
of an output socket in conjuction with f key to show the output in the viewer
node. Select another output and hit f to see its output and so on.
Node curves maintain handles status (normal, auto, vector) even after adding
a control point now. This makes the behavior the same as in case of removing a control
point. Previously the status of handles was reseted.
"A slightly late Christmas present for the Animators out there :-)"
This tool allows animators to store frequently used poses in an action, and be able to label those poses to help them retrieve them later. In a way, it acts as a glorified clipboard for poses.
One of the cool features with this is the ability to select which stored pose to use interactively in the 3d-view. Once a few poses have been stored in the PoseLib, simply use the "Ctrl L" hotkey to start previewing. Use the Mousewheel or the Page Up/Down keys to change poses, and confirm/cancel the preview in the same way as you do for transforms.
Usage Notes:
* Each Armature may get its own PoseLib. PoseLibs are simply actions with extra data, so they can get relinked.
* Manually editing actions used as PoseLibs is not a good idea, as some data may not be able to be found. Tools to automagically find poses in an action could be investigated...
* PoseLib will only apply/retrieve poses to/from selected bones
* A basic UI for this can be found in the "Links and Materials" panel. Most of the PoseLib tools are presented there.
Useful Hotkeys (also found in Pose->PoseLib menu):
* Ctrl L - interactively preview poses
* Shift L - add a new pose or replace an existing pose in the PoseLib with the current pose
* Ctrl Shift L - rename an existing pose in the PoseLib
* Alt L - remove a pose from the poselib.c
Cleaned up bad level calls for multires; moved most of multires functions to blenkern, where they should have been in the first place. Functionality of the tool is unchanged.
Applying Stephan Kassemeyer's patch (#6750) to add a curve modifier for sculpting.
A few changes from the patch:
* The default curve is closer to the old behavior
* Fixed loading files already saved in sculpt mode
* Changed the interface; split the brush texture controls off into a third sculpt tab, and put the curve (and curve reset) into the Brush tab.
============================
- Strand render now has options to remove child strands as
the object's faces becomes smaller, in the Simplification
particle panel.
- "Reference Size" is the approximate size of the object on
screen, after which simplification starts.
- "Rate" is how fast strands are removed.
- "Transition" is the percentage of strands being faded out as
they are removed.
- Another "Viewport" option removes strands on faces that are
outside of the viewport. "Rate" again controls how fast these
are removed.
- Strand render in Blender Units now has an adjustable minimum
width. Below this minimum width, strands start fading out
instead of getting smaller.
=========
- The render and realtime button for the particle system modifier
and the enabled button for particles now work seperate again,
made a bad design decision to tie them together. Now with only
the render button and not realtime enabled it renders.
- Fix for bug #7948: particle mode crash while constraining axis.
- Fix for bug #7945: crash loading effector groups from an old file.
- Fix for bug #7942: crash for reactor particles emitting from particles.
I was careful in selectively rolling back revisions, but if you've committed changes unrelated to BPY mixed with BPY changes, I might have reverted those too, so please double check.
http://wiki.blender.org/index.php/Rewriting_the_2.4x_BPython_API
Some areas are not yet finished, the 2.4 api can remain "import Blender" and the bpy api "import bpy" gives access to the new api.
Todo
* event, link, etc are not assigned to Blender.*
* Scripts need to be tested and updated.
* Scripts cannot mix bpy and Blender modules anymore.
* Makefiles need to be updated (only works with scons now)
* Make the 2.4 api optional with IFDEF's
* Lots of testing and small fixes
=================
Big commit, but little user visible changes.
- Dupliverts and duplifaces are now rendered as instances, instead
of storing all of the geometry for each dupli, now an instance is
created with a matrix transform refering to the source object.
This should allow us to render tree leaves more memory efficient.
- Radiosity and to some degree raytracing of such objects is not
really efficient still. For radiosity this is fundamentally hard
to solve, but raytracing an octree could be created for each object,
but the current octree code with it's fixed size doesn't allow this
efficiently.
- The regression tests survived, but with I expect that some bugs will
pop up .. hopefully not too many :).
Implementation Notes
====================
- Dupligroups and linked meshes are not rendered as instances yet,
since they can in fact be different due to various reasons,
instancing of these types of duplis that are the same can be added
for them at a later point.
- Each ObjectRen now stores it's own database, instead of there being
one big databases of faces, verts, .. . Which objects that are actually
rendered are defined by the list of ObjectRenInstances, which all refer
to an ObjectRen.
- Homogeneous coordinatess and clipping is now not stored in vertices
anymore, but instead computed on the fly. This couldn't work for
instances. That does mean some extra computation has to be done, but
memory lookups can be slow too, and this saves some memory. Overall
I didn't find a significant speed impact.
- OSA rendering for solid and ztransp now is different. Instead of e.g.
going 8 times over the databases times and rendering the z-buffer, it
now goes over the database once and renders each polygon 8 times. That
was necessary to keep instances efficient, and can also give some
performance improvement without instances.
- There was already instancing support in the yafray export code, now it
uses Blender's render instances for export.
- UV and color layer storage in the render was a bit messy before, now
should be easier to understand.
- convertblender.c was reorganized somewhat. Regular render, speedvector
and baking now use a single function to create the database, previously
there was code duplicated for it.
- Some of these changes were done with future multithreading of scene
and shadow buffer creation in mind, though especially for scene creation
much work remains to be done to make it threadsafe, since it also involves
a lot of code from blenkernel, and there is an ugly conflict with the way
dupli groups work here .. though in the render code itself it's almost there.
not mirrored exactly, though the problem is not completely solved.
The way local frames are computed for particles is still not fully
symmetric, which shows especially on long hairs...
Also made the shift+o subsurf switch work recursively into
dupli-groups, did only the first level before.
the depsgraph relations for constraints with a local ipo were being
skipped, but I have no idea why this code was added? Uncommenting
it seems to work fine.
Brecht Van Lommel
Campbell Barton
Peter Schlaile
Janne Karhu
Joshua Leung
Matt Ebb
Jens Ole Wund
Juho Vepsalainen
Nicholas Bishop
Martin Poirier