This is a follow-up fix for rBa10b2fe. The Action constraint uses a hackish
stub object and pose, which doesn't have a hash table for fast lookups.
This doesn't seem to be a big issue with the old depsgraph, but in the new
depsgraph it creates a large number of cache misses and significant slowdown,
possibly because of additional threading and less simple bone loops.
Normal Map node support for GLSL mode and the internal render (multiple tangents support).
The Normal Map node is a useful node which is present in the Cycles render.
It makes it possible to use normal mapping without additional material node in a node tree.
This patch implements Normal Map node for GLSL mode and the internal render.
Previously only the active UV layer was used to calculate tangents.
- Access with Shift-LMB or from the 'Create' toolbar tab.
- Uses curve fitting for bezier curves, with error and corner angle options.
- Optional tablet pressure to curve radius mapping.
- Depth can use the cursor or optionally draw onto the surface,
for the entire stroke or using the stroke start.
- Stroke plane can optionally be perpendicular to, or aligned to the surface normal.
- Optional radius tapering and for start/end points.
- Supports operator redo and calling from Python.
This was a feature request from a few years back (IIRC from ZanQdo?) to make it
easier to reuse one set of driver variables across several different drivers.
Dev Notes:
* Finally it's done! All that trouble for two little buttons.
* Grr... cmake... grrr!
This is a regression since 4310128 which is cased by really bad logic:
there might be dependencies between dupli-objects, which means _if_ we
really want to ensure derived mesh on dupli creation we have to do it
before any matrix is overwritten.
I'm not sure if such derived mesh trick is really the only way to go
without major refactor, but seems simple fix for now will do it.
Previous fix made another issue even more visible, leading to +1 particle on first vert
and none on last one. This commit should fix both original and new issues.
Support for driver variables that don't resolve to numbers, eg:
objects, bones, curves... etc.
Without this, Python expressions to access this data needed to use an absolute path from `bpy.data`,
however this is inconvenient, breaks easily (based on naming) and wouldn't set the dependencies correctly.
That might consider a bit more objects to be considered deform modified,
but it covers common case of using taper object without require of doing
recursive checks.
In worst case it'll be just some extra synchronization time, no render
time difference will happen for false-positive because of extra checks
happening in Cycles.
When non-random, particle distribution used a small start offset (to avoid
zero-weight faces), which is fine with "continuous" entities like faces, but not
for discrete ones like vertices - in that case it was generating some undesired
"jump" over a few verts in case step was small enough
(i.e. total number of verts/particles was big enough).
Point-cached particles (those using simulations) would not update at all outside of
first frame, due to PSYS_RECALC_RESET flag being ingnored in `system_step()`...
For some mysterious reasons, udate is still non-fully functional outside of startframe
(e.g. changing face distribution between random and jittered), but at least when choosing
'Vertices' you get particles from verts and not faces!
This reverts commit 2bd3acf7cd.
Commit is valid in theory - but in practice, it means nearly all edited hair systems
would need to be re-created from scratch... Not nice, so better revert and note in code
that particle distribution is ugly and does not respect 'use modifier stack' option in most cases.
Follow same logic in `psys_render_restore` as in `psys_render_set` - if hair and
display percentage is not 100%, we have to recompute particles...
With regular 'emitter' particles just hiding some is fine (though using random here
will not give a precise proportion...).
Disclaimer: this is tentative fix, seems to be working but you never know with particles.
If issue arise, we'll just revert this commit and hide 'use modifier stack' option
for grid distribution instead.
This commit also try to make choice of which dm to use during distribution more generic
(deduplication of code), again hopping not to break anything. :P
This commit:
* Fixes bad handling of 'stop iteration' (by adding a status flag, so that we can actually
stop in helper functions too, and jumping to a finalize label instead of raw return, to
allow propper clean up).
* Adds optional recursion into 'ID tree' - callback can also decide to exclude current id_pp
from recursion. Note that this implies 'readonly', modifying IDs while recursing is not
something we want to support!
* Changes callback signature/expected behavior: return behavior is now handled through flags,
and 'parent' ID of id_pp is also passed (since it may not always be root id anymore).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1869
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
When attempting to change a driver variable name to an "invalid" name,
an indicator will now be shown beside the offending variable name.
Clicking on this icon will show a popup which provides more information
about why the variable name cannot be used.
Reasons that it knows about are:
1) Starts with number
2) Has a dot
3) Has a space
4) Starts with or contains a special character
5) Starts with an underscore (Python does allow this, but it's bad practice,
and makes checking security of drivers harder)
6) Is a reserved Python keyword
