Needed to allow modal UI keymaps, but I'm sure we'll need this more often in future.
First item will be modal eyedropper keymap coming in a following commit.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
Official Documentation:
http://www.blender.org/manual/render/workflows/multiview.html
Implemented Features
====================
Builtin Stereo Camera
* Convergence Mode
* Interocular Distance
* Convergence Distance
* Pivot Mode
Viewport
* Cameras
* Plane
* Volume
Compositor
* View Switch Node
* Image Node Multi-View OpenEXR support
Sequencer
* Image/Movie Strips 'Use Multiview'
UV/Image Editor
* Option to see Multi-View images in Stereo-3D or its individual images
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
I/O
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
Scene Render Views
* Ability to have an arbitrary number of views in the scene
Missing Bits
============
First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report.
Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report.
Everything else is likely small todos, and may wait until we are sure none of the above is happening.
Apart from that there are those known issues:
* Compositor Image Node poorly working for Multi-View OpenEXR
(this was working prefectly before the 'Use Multi-View' functionality)
* Selecting camera from Multi-View when looking from camera is problematic
* Animation Playback (ctrl+F11) doesn't support stereo formats
* Wrong filepath when trying to play back animated scene
* Viewport Rendering doesn't support Multi-View
* Overscan Rendering
* Fullscreen display modes need to warn the user
* Object copy should be aware of views suffix
Acknowledgments
===============
* Francesco Siddi for the help with the original feature specs and design
* Brecht Van Lommel for the original review of the code and design early on
* Blender Foundation for the Development Fund to support the project wrap up
Final patch reviewers:
* Antony Riakiotakis (psy-fi)
* Campbell Barton (ideasman42)
* Julian Eisel (Severin)
* Sergey Sharybin (nazgul)
* Thomas Dinged (dingto)
Code contributors of the original branch in github:
* Alexey Akishin
* Gabriel Caraballo
Currently this is mainly useful for picking camera DOF depth.
- EKey over a distance field prompts you to pick a depth from the camera.
- WKey (Specials menu) to pick from the 3D view (when the active camera's selected).
Make the UI API more consistent and reduce confusion with some naming.
mainly:
- API function calls
- enum values
some internal static functions have been left for now
The issue was that some properties are no direct children of the struct we support in 'copy to selected'
(RNA_Sequence in this case). Since we can't use the ID of sequences here (it's the scene, while we need
a sequence level of control), we had to add a new API helper to RNA path, which takes a RNA type
and return a path relative to the closest ancester of that type.
This way, we get a path from the RNA_Sequence, and can easily apply it to all other valid sequences
to copy the property.
Review, suggestions and edits by Campbell Barton, thanks!
Yep, at last it's here!
There are a few minor issues remaining but development can go on in
master after discussion at blender institute.
For full list of features see:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting
Thanks to Sergey and Campbell for the extensive review and to the
countless artists that have given their input and reported issues during
development.
When setting keymap properties to values equalling the RNA default, they will
get "unset" and automatic operator behavior is used. There is no way to
explicitly set the default value as a user.
1) To allow distinguishing uninitialized (not set) properties in the keymap
items, a few changes to the RNA struct comparison function are needed: Instead
of allowing only strict/non-strict comparison of 2 properties A and B in a
struct, this now has 3 modes:
* STRICT: compare only the actual property values (same as 'strict' before)
* UNSET_MATCH_ANY: if either A or B is unset, consider them a match (same as
non-strict before)
* UNSET_MATCH_NONE: if one property is set and the other not, consider them a
mismatch.
The new UNSET_MATCH_NONE mode is useful for keymaps, because it allows keeping
user-defined property values in the keymap even if they match the default
property value (see wm_keymap_diff function in wm_keymap.c)
2) A new operator is added for unsetting ID properties in the RMB context menu
and in user preferences next to keymap properties. This only works on ID
properties and deletes the ID property storage, so that the default value is used.
In the user preferences for keymaps the properties are shown in an inactive
layout to indicate that the default value is used (which some operators such as
the "select linked" op from the report use to trigger automatic behavior). When
the user sets a property it gets set and stays that way until explicitly "unset"
using the new operator.
Most of the places which relied on RNA_path_resolve() did so believing that if
it returned true, that it had found a valid property, and that the returned
pointer+property combination would be what the path referred to. However, it
turns out that if the property at the end of the path turns out to be a
"pointer" property (e.g. "data" for Object.data), this would automatically
become the pointer part, while the prop part would be set to null. Hence, if a
user accidentally (or otherwise) specifies a path for the single-property driver
variable type like this, then Blender would crash.
This commit introduces two convenience functions - RNA_path_resolve_property()
and RNA_path_resolve_property_full() - which mirror/wrap the existing
RNA_path_resolve() functions. The only difference though is that these include a
check to ensure that what was found from resolving the path was in fact a
property (they only return true iff this is the case), and make it explicitly
clear in the name that this is what they will do so that there's no further
confusion. It is possible to do without these wrapper functions by doing these
checks inline, but the few cases that had been patched already were pretty
hideous looking specimens. Using these just make it clearer and simpler for all.
I've also beefed up the docs on these a bit, and changed these to using bools.
