Our current keymap doesn't give us enough room to make such changes in
the event system. To fix small issues caused by this, we would need to do
drastic changes in Blender's keymaps and internal handling. It was worth
a try, but it didn't work.
I can write down a more descriptive statement in a few days, but for now
I need a break of this stuff.
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
Design task: T42339
Differential Revision: D840
Initial implementation proposal: T41867
Short description:
With this we can distinguish between holding and tabbing a key. Useful
is this if we want to assign to operators to a single shortcut. If two
operators are assigned to one shortcut, we call this a sticky key.
More info is accessible through the design task and the diff.
A few people that were involved with this:
* Sean Olson for stressing me with this burden ;) - It is his enthusiasm
that pushed me forward to get this done
* Campbell and Antony for the code and design review
* Ton for the design review
* All the other people that gave feedback on the patch and helped to
make this possible
A big "Thank You" for you all!
OpenGL is detected:
Hoping to decrease the frequency of by far one of the most frequent bug
reports by windows users.
There is some reorganization of the GHOST API to allow easy addition of
further OpenGL options in the future. The change is not propagated too
deep to keep the size of the patch managable. We might reorganize things
here later.
For OpenGL we do two checks here:
One is a combination of GDI generic renderer or vendor microsoft
corporation and OpenGL version 1.1. This means the system does not
use GPU acceleration at all. We warn user to install a graphics
driver and of cases where this might happen (remote connection, using
blender through virtual machine)
The other one just checks if OpenGL version is less than 1.4 (we can
easily change that in the future of course) and warns that it is
deprecated.
Both cases will still let blender startup correctly but users should now
have a clear idea of the system being unsupported.
A user preference flag is provided to turn the warning off.
Now stop posting those bug reports without installing a driver first -
please?
* Rename "emboss" to "widget_emboss"
* Remove duplicated UI_GetThemeColor4ubv function
I made sure version bump and Save User Settings are working correctly ;P
This is mainly to address old issue when one need to have SDL library installed
in order to use our official builds. Some hip distros already installs SDL,
but it's not quite the same across all the variety of the distros.
We also now switching to SDL-2.0, most of the distros have it in repositories
already, so it shouldn't be huge deal to install it if needed.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D878
This adds a theme option for the embossing of UI widgets. By doing this users have much greater flexibility for creating nice themes. Previously many themes (particularly dark ones) looked quite bad due to the very obvious emboss. This made simpler, flat-style themes very challenging.
Closes T42228
Reviewed by @campbellbarton
* Only use last key for pies if it hasn't been released already
* Confirm threshold is now measured as distance after regular threshold.
zero disables.
* Only display the confirm threshold if there's a valid direction (mouse
is after threshold).
* Calculate confirm threshold taking recentering into account
The nodes wire was using 'TH_HEADER' flag to get its color and thus would be in sync with the header. Now make it so it uses its 'own' flag (actually 'TH_SYNTAX_R', the only TH_SYNTAX_* which wasn't yet used by the nodes).
Also expose the setting to the user so it can be themified.
This fixes T42209
Reviewers: lukastoenne
Reviewed By: lukastoenne
Maniphest Tasks: T42209
Differential Revision: https://developer.blender.org/D827
This commit adds a confirm threshold property to pie menus.
Basically, this will confirm the pie menu automatically when
the distance from the center of the pie exceeds that threshold without
a need to release the pie button.
The confirm threshold will only work if it is larger than the pie
threshold.
The confirmation actually occur when the mouse stops moving, to
allow multiple pie menus to be better linked together, (see below)
This functionality also facilitates the ability for chained pie menus by
dragging. Basically, a pie menu item can be a call_menu_pie operator and
the new pie menu will still use the original pie menu release event for
confirmation. This should allow for quick, gesture based navigation in
pie menu hierarchies (going back in the hierarchy is still not supported
though)
There will be a demonstration pie in the official add-on soon
quit.blend.
This will use a slower file write if an object is in edit or sculpt
mode.
Autosaving will explicitly not be supported to keep it fast.
Added a tooltip warning.
On 4k devices the default pixel size leads to tiny OpenGL drawing
that is hardly usable without doubling the DPI. The retina system
on OSX aims to alleviate this problem by introducing a general 2x
pixel size.
No equivalent feature exists on other platforms so far. However,
to emulate the effect this patch introduces a "virtual" pixel size
factor for OpenGL drawing.
Note that the user currently has to enable this manually by selecting
the "Virtual Pixel Mode" in the user preferences (defaults to native).
All windows of a Blender instance share the same virtual pixel size as well.
It may be possible to handle this on a per-window basis and automate
the selection somewhat (if enabled by the user), so working with
multiple screens becomes more convenient, but technical limitations
make this a bit difficult (on X11 with nvidia drivers the actual screen size
is not reported correctly).
Reviewers: ton, campbellbarton
Differential Revision: https://developer.blender.org/D669
This commit merges the code in the pie-menu branch.
As per decisions taken the last few days, there are no pie menus
included and there will be an official add-on including overrides of
some keys with pie menus. However, people will now be able to use the
new code in python.
Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/
Thanks:
Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review
and design comments
Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for
suggestions during the development.
Special Thanks to Sean Olson, for his support, suggestions, testing and
merciless bugging so that I would finish the pie menu code. Without him
we wouldn't be here. Also to the rest of the developers of the original
python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who
did the research and first implementation and whose code I used to get
started.
Looks like mask points coloring was recently changed, and IMAGE space colors were left uninitialized...
Factorized a bit the code about vertex_handle & co too, was quite duplicated.
This patch creates an interface for selection mechanisms in opengl. This
makes it possible to switch between occlusion query based or select
rendermode based selection transparently.
This is really useful on graphics drivers that do not accelerate the
select rendermode path (some ATI cards are notorious for this, and the
new path is used by default there), since occlusion queries are always
hardware accelerated due to their use in games.
The option can be found under system - selection. Auto just enables
occlusion queries for ATI users while the rest of the options enforce
one of the two methods always.
There is just one known change, previous code enforced nearest bone to
always get selected, even when mouse selecting near the same position, I
couldn't replicate the behaviour though.
patch by me with edits and review by Campbell.
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.
Simply add an option to render settings to save an EXR cache,
just when the render is finished. Also changed RE_ReadRenderResult() to read
cache instead of temp sample files (those are fully volatile now anyway).
Path to save cached render results is an UserPreferences setting.
Also added 'Reload render' feature to the Image Editor (so one can now re-open a blend,
and in an Image Editor hit ctrl-R to (try to) reload last render from cache).
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D553
Current temporary data of Blender suffers one major issue - default 'temp' dir on Windows is never
automatically cleaned up, and can end being quite big when used by Blender, especially when we have
to store per-process data (using getpid() in file names).
To address this, this patch:
* Divides tempdir paths in two, one for 'base' temp dir (the same as previous unique tempdir path),
the other is a mkdtemp-generated sub-dir, specific to each Blender instance.
* Only uses base tempdir when we need some shallow persistance accross Blender sessions - and we always
reuse the same filename (quit.blend...) or generate small file (crash reports...).
* Uses temp sub-dir for heavy files like pointcache or renderEXRs (Save Buffer option).
* Erases temp sub-dir on quit or crash.
To get this working it also adds a working 'recursive delete' to BLI_delete() under Windows.
Note that, as in current code, the 'recover render result' hack-feature that was possible
with SaveBuffer option is still removed. A real renderresult cache feature will be added
soon, though.
Reviewers: campbellbarton, brecht, sergey
Reviewed By: campbellbarton, sergey
CC: sergey
Differential Revision: https://developer.blender.org/D531
Summary:
The title actually says it all, it's just possible to
have independent free handles for mask splines. Also
it's now possible to have aligned handles displayed
as independent handles.
Required changes in quite a few places, but they're
rather straightforward.
From user perspective there's one really visible change
which is removed Handle Type menu from the panel. With
asymmetric handles it's not clear which handle type to
display there. So now the only way to change handle type
is via V-key menu.
Rewrote normal evaluation function to make it deal
with new type of handles we support. Now it works in
the following way:
- Offset the original spline by maximal weight
- Calculate vector between corresponding U positions
on offset and original spline
- Normalize this vector.
Seems to be giving more adequate results and doesn't
tend to self-intersect as much as old behavior used to,
There're still some changes which needed to be done, but
which are planned for further patch:
- Support colors and handle size via themes.
- Make handles color-coded, just the same as done for
regular bezier splines in 3D viewport.
Additional changes to make roto workflow even better:
- Use circles to draw handles
- Support AA for handles
- Change click-create-drag to change curvature of the
spline instead of adjusting point position.
Reviewers: campbellbarton
CC: sebastian_k, hype, cronk
Differential Revision: http://developer.blender.org/D121
Was using wire or black in many places, this color is used for cursor,
camera guides, transform helper lines. So its possible to have a dark
background with light overlay color.
Patch D331 by Brita, with some edits.
This is a standard Hue - Saturation - Lightness model
(see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV)
Note though the difference between HSV and HSL saturation, which are not the same.
The advantage of having this color selection scheme is that artists can select
shades and tints of a color easily by using the lightness slider. Also colors
are arranged on (approximated) perceived lightness on the color wheel.
Beware, Old files opened with this preference saved will crash!
Reviewers: sergey, brecht, campbellbarton
Differential Revision: https://developer.blender.org/D385
After some discussion it seems both are valid defaults but useful for
very different purposes.
- 'free' lets you explore the scene with full 6dof (like fly mode)
- 'orbit' is closer to typical mouse view orbit, constraining to orbiting about a central location.
This doesn't effect orbit/pan which are available with modifier keys.
