readfile.c would increment object usercount in three places, where it should not.
Remember kids: Objects are **only** refcounted by Scene's bases, and Object->proxy!
This commit brings some long requested improvements to the workflow for setting up
drivers, which should make it easier and faster to set up new drivers in a more
interactive fashion.
The new workflow is as follows:
1) Hover over the property (e.g. "Lamp Energy" or "Y Location") or properties ("Rotation")
you wish to add drivers to. We'll refer to this as the "destination"
2) Ctrl-D to active the new "Add Drivers" eyedropper
3) Click on the property you want to use as the source/target. The property under the
mouse will be used to drive the property you invoked Ctrl-D on.
For example, to drive the X, Y, and Z location of the Cube using the Y Location of the Lamp,
hover over any of the X/Y/Z location buttons, hit Ctrl-D, then click on the Y-Location
button of the Lamp object. Drivers will be added to the X, Y, and Z Location properties
of the Cube; each driver will have a single variable, which uses the Y-Location Transform
Channel of the Lamp.
Tips:
- Transform properties will automatically create "Transform Channel" driver variables.
Everything else will use "Single Property" ones
- Due to the way that Blender's UI Context works, you'll need two Properties Panel instances
open (and to have pinned one of the two to show the properties for the unselected
object). It's slightly clunky, but necessary for implementing a workflow like this,
as the UI cannot be manipulated while using eyedroppers to pick data.
- The eyedropper operator implemented here actually has three modes of operation.
1) The "1-N" (one to many) mode is the default used for Ctrl-D, and "Add Driver to All"
in the RMB Menu. This is the behaviour described above.
2) There's also a "1-1" (one to one) mode that is used for the "Add Single Driver" in the
RMB Menu.
3) Finally, there's the "N-N" mode (many to many), which isn't currently exposed.
The point of this is to allow mapping XYZ to XYZ elementwise (i.e. direct copying)
which is useful for things like locations, rotations, scaling, and colours.
Implementation Notes:
- The bulk of the driver adding logic is in editors/animation/drivers.c, where most of
the Driver UI operators and tools are defined
- The property eyedropper code is in interface_eyedropper.c along with all the other
eyedroppers (even though they don't share much actual code in common). However, this
turns out to be necessary, as we can't get access to many of the low-level buttons API's
otherwise.
Todo:
- It may be necessary to restore a way to access the old behaviour (i.e. "manual setup")
in case it is not practical to immediately pick a property.
- Other things to investigate here include extra hotkeys (e.g. Ctrl-Shift-D for Add Single?),
and to expose the N-N mode.
- Other things we could try include interactively applying scaling factors, picking
multiple targets (e.g. for location difference and rotation difference drivers),
and/or other ways of using these property picking methods.
Just using DKEY for this was resulting in too many drivers being accidentally created
by users drawing using Grease Pencil. This change also works better with the following
workflow changes to the driver setup process.
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
Steps to reproduce were:
* Open default video editing layout
* Drag down or click '+' icon in upper right corner of sequencer view
* A preview region appears, even though the view type is not set to sequencer-preview split mode
Another bug that has been there since ages :/ Reported by @Blendify via IRC, thanks!
This seems quite useful for the development, so you don't need to wait
all the kernels to be re-compiled when working on a new feature, which
speeds up re-iteration.
Marked as an advanced option, so if it doesn't work so well in practice
it's safe to revert anyway.
This commit makes it so casting subsurface rays will totally ignore all
the BVH nodes and primitives which do not belong to a current object,
making it much simpler traversal code and reduces number of intersection
tests.
Reviewers: brecht, juicyfruit, dingto, lukasstockner97
Differential Revision: https://developer.blender.org/D1823
Steps to reproduce were:
* Go to edit mode, select geometry
* Spacebar -> search for bevel OP
* Activate *using enter key*
* Immediately stops when releasing enter key
To fix we simply make sure the initial release event is ignored. For mouse events that wasn't an issue since activating an element is done on key release in menus. An alternative fix would be to do the same for enter key, but that's more risky. Also, checking event value is highly recommended anyway.
While it was indirectly disabled already, it's handy to use the config
as template and enable certain features. In case of Cycles enabling it
would also enable OSL which is not very expected.
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
This patch adds support for coloring point density textures based on several mesh vertex attributes.
* Vertex Color: Use a vertex color layer for coloring the point density texture
* Vertex Weight: Use a weights from a vertex group as intensity values. (for Blender Render engine the additional color band is used)
* Vertex Normals: Use object-space vertex normals as RGB values.
The vertex color source enum is stored separately from the particle color source, to avoid invalid values when switching.
Note that vertex colors are technically "corner colors" (MLoop), so each vertex can have as many colors as faces it is part of.
For the purpose of point density the mloop colors are simply averaged, which is physically plausible because corners can be viewed
as multiple points in the same location.
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
While most scripted expressions are quite short (e.g. "var" or "frame + 1"),
those that are autogenerated by scripts (to take into account a wide range of factors)
may require a bit more headroom to operate in.
By doubling the maximum length here, we now make it possible to combine up to 38
3-letter variables in some linear combination (with all factors expressed to 4 dp).
That should be more than enough for anyone or anything for quite a while!
Unfortunately, this does increase memory consumption for drivers across the board.
White the config itself could be loaded this way, lookup tables can not. Additionally,
that's not really clear how to solve the issue with search path which is multi-byte
only in the API.
Reverting for further investigation.
This reverts commit ab4307aa08.
Thanks to D1080 by @rockets, I've now been able to easily implement the
ability to type multiple word snippets/partial words into the text filter
field (in the Animation Editors), and have it filter the channels which
contain just some of those parts (instead of having to match everything).
For example, the following search strings will now work:
* "loc rot" or "lo ro" will now filter all location and rotation FCurves
* "col loc" will filter all location and color FCurves
* "scale" will also work as before to filter all scale FCurves
But, the following will not work:
* "lc rt" will NOT filter all location and rotation, as the fuzzy search only
breaks down the search string based on whitespace placement
By default, this is not enabled when using name filtering (i.e. magnifying glass is checked,
and some filtering text is specified). Instead, you need to enable the "AZ" toggle beside
the name field. This fuzzy matching is not enabled by default as it could end up being
quite a bit slower on really heavy scenes. (There are probably some optimisation
opportunities, but that's only a future option if someone really needs it)
This is a mix of regression and old unsupported configuration.
Regression was caused by some checks added on Blender side which was
checking whether python function returned error or not. This made it
impossible to enable Cycles when running from a file path which can't
be encoded with MBCS codepage.
Non-regression issue was that it wasn't possible to use pre-compiled
CUDA kernels when running from a path with non-ascii multi-byte
characters.
This commit fixes regression and CUDA parts, but OSL still can't be
used from a non-ascii location because it uses non-widechar API to
work with file paths by the looks of it. Not sure we can solve this
just from our side by using some codepage trick (UTF-16?) since even
oslc fails to compile shader when there are non-ascii characters in
the path.
* As requested by venomgfx, rotations now only display to 2 decimal places (more than
enough for rotations in degrees)
* Also, made it so that the "factor" types now show 3 dp (previously only 2, which isn't
really enough when dealing with values from 0.0 - 1.0)
The radial control operator is commonly used for setting sculpt brush Size and Strength
settings. However, when using it, it can often be difficult to remember which hotkey
is responsible for which setting, meaning that you can often accidentally modify the
wrong setting without knowing it (or even what new value you've set it to).
This commit makes it so that the property name and the current value are always shown
on the header. Previously this info was only shown when the doing numeric input.
(It also fixes a bug where the numeric input print would hang around even after it
wasn't being used).
