Hopefully it's more readable now. Took me a while to remmeber
all the stuff going on here while was looking into possibility
of implementing some feature here.
The tooltip seemed to hint that this tool is able to resolve all manner of
gimble-lock situations by untangling the curves (i.e. performing some kind of
equivalent-angles resolution, keeping in mind the nearest situations nearby).
However, this tool currently only performs corrections for the most basic case
when large jump+flip discontinuity artifacts appear in euler rotation curves as
a result of rotation values getting clipped to +/- 180 degrees, which arises
when these rotation curves are the result of baking some physics sim or so.
(Also, fixed an unrelated "replace-all" typo in a comment)
proposal was to add another special init hack for the viewer node->id, but rather would do it right and so moved all the special init hacks for constant ID backpointers (Scene for RenderLayer, Composite,
Defocus, FileOutput and MovieClip for MovieClip, MovieDistortion and Stabilization nodes). These are now part of the local init callbacks functions of the appropriate nodes, using the new initfunc_api
callback which takes a Context pointer, so they have access to Scene.
Couple of issues here:
- User shouldn't be able to run into dupligroup recursion.
It was checking already when setting a group for dupli.
Added check to operator which adds object to group.
- It's still possible files with recursion are hanging around,
so made simplify function robust to such kind of crap.
Gives approx 2x speedup on my laptop on such operations
as mesh subdivision in edit mode. Desktops with fancier
CPUs could benefit even more.
Thanks Campbell for review!
Issue was caused by missing X/Y displacement components
flip when flipping the normals (flipping the normals changes
the tangent space apparently and displacement vectors need
to be modified to correspond to new space).
Reported by Jonathan Williamson in IRC.
Now add_freestyle() in pipeline.c takes a second argument to enable/disable
stroke rendering. When stroke rendering is disabled, the function allocates
data structures but does not perform stroke rendering. The allocated data
structures (mostly left unpopulated with data elements) are intended to allow
for the Read Full Sample Layers (Shift-R) command in the compositor.
* Added a node to convert wavelength (in nanometers, from 380nm to 780nm) to RGB values. This can be useful to match real world colors easier.
* Code cleanup:
** Moved color functions (xyz and hsv) into dedicated utility files.
** Remove svm_lerp(), use interp() instead.
Documentation:
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Wavelength
Example render:
http://www.pasteall.org/pic/show.php?id=53202
This is part of my GSoC 2013. (revisions 57322, 57326, 57335 and 57367 from soc-2013-dingto).
to be done in cycles itself to keep compatibility for bytecode too.
Also fix broken button to compile OSL from the text editors, this got broken after
recent change to disable editing of library linked nodes.
Added some special case for two-component channels name.
Maybe magic could be simplified to just use last char of
channel name as an id, but extra paranoid check never hurts.
- BKE_mask_update_scene was only used with do_newframe=FALSE,
removed this argument.
- Made it so BKE_mask_update_scene is able to handle LIB_ID_RECALC_DATA
case. Namely, if mask ID is tagged for data update it means shapekeys
will be re-evaluated (as if do_newframe=true).
If mask id only tagged for LIB_ID_RECALC, then no shapekey evaluation
happens (same as it used to behave before).
This means, doing DAG_id_tag_update(&mask->id, OB_RECALC_DATA) will
lead to shapekeys re-evaluation which is really needed in such
operators as clearing shapekeys (and cleaning shapekeys which is
in tomato branch yet).
This is a bit silly to use OB_RECALC_DATA sine mask is not an OB,
but could not see better way to do it now.
This fixes missing mask re-evaluation after clearing shapekey,
would expect no other functional changes.
don't have any way to deal with scripted node types yet, which could in principle by added with pynodes. The NodeCustomGroup type adds a way of scripting nodes by automating node groups which the
hardcoded system can then interpret like regular groups.
The new NodeCustomGroup type has the basic node_tree pointer property like the regular group node types and also uses the same socket interface system as regular groups. This means that input/output
sockets can be mapped to internal nodes in the same way as regular node groups in renderers and the compositor. On top of that, however, the NodeCustomGroup type can be subclassed in python scripts to flesh out
scripted node types with own draw functions, properties, updates and so on.
NB: Only cycles currently supports this node type and its derivatives, other systems may follow later.
The "Multiply" blending mode for NLA strips worked incorrectly. Instead of
modulating the influence of the current strip, it was in fact scaling the result
of the entire stack (with the strip applied). This caused problems when
influence = 0, as it was in fact muting everything instead of just controlling
the strip we are interested in.
Crash happened in ED_view3d_calc_zfac and happend in cases operator was invoked
from a region different from RGN_TYPE_WINDOW.
For a transformation zfac is only used in convertViewVec in cases region is
RGN_TYPE_WINDOW, so solved by just adding extra check in calculateCenter
for this particular case.
have zero total influence
Previously, when evaluating the NLA stack at a particular point in time, if a
channel hadn't been encountered before, influence values were simply ignored
when accumulating the values contributed by each strip to the overall stack.
This behaviour simplified the handling of the problem of what "baseline" to
blend relative to (i.e. influence basically scales the magnitude of a scalar
around 0, but we may not exactly want a property to get it's value set to 0 as
baseline). However, the problem was that this meant that you'd get popping
artifacts when the a lower strip finally reaches influence=0 but your upper
strips haven't fully reached maximum yet ([#35382]). Another problem was that
you'd end up with less ability to scale the influence of all strips (as in
[#35263]).
So, as a stop-gap fix now, we will allow influence scaling to work on these
strips too. This still doesn't fix some of the other problems regarding
baselines/rest-poses and deterministic behaviour when some channels are only
keyed in one strip which isn't set to extend it's influence... Fixing those
issues is a bit more involved, and would require a bit of refactoring of how we
keep track of accumulation channels.
