The issue here is that the preferences are still used because both can be accessed from the 3D View, view menu. In the future, it is likely that the old mode will be removed (maybe 2.8?) but for now we want to keep both operational.
Differential revision: https://developer.blender.org/D2320
For Windows 8.1 and X11 (Linux, BSD) now use the DPI specified by the operating
system, which previously only worked on macOS. For Windows this is handled per
monitor, for X11 this is based on Xft.dpi or xrandr --dpi. This should result
in appropriate font and button sizes by default in most cases.
The UI has been simplified to a single UI Scale factor relative to the automatic
DPI, instead of two DPI and Virtual Pixel Size settings. There is forward and
backwards compatibility for existing user preferences.
Reviewed By: brecht, LazyDodo
Differential Revision: https://developer.blender.org/D2539
This adds the ability to switch between different application-configurations
without interfering with Blender's normal operation.
This commit doesn't include any templates,
so its mostly to allow collaboration for the Blender 101 project
and other custom configurations.
Application templates can be installed & selected from the file menu.
Other details:
- The `bl_app_template_utils` module handles template activation
(similar to `addon_utils`).
- The `bl_app_override` module is a general module
to assist scripts overriding parts of Blender in reversible way.
See docs:
https://docs.blender.org/manual/en/dev/advanced/app_templates.html
See patch: D2565
Although this wasn't so obvious since it
only showed up for factory settings and in the preferences window.
Panel display order depends on registration order,
Sorry for the noise. On the bright side we no longer need to move
classes around to re-arrange panels.
Intended to replace legacy GL_SELECT, without the limitations of
sample queries which can't access depth information.
This commit adds VIEW3D_SELECT_PICK_NEAREST and VIEW3D_SELECT_PICK_ALL
which access the depth buffers to detect whats under the pointer,
so initial selection is always the closest item.
The performance of this method depends a lot on the OpenGL
implementations glReadPixels.
Since reading depth can be slow, buffers are cached for object picking
so selecting re-uses depth data, performing 1 draw instead of 3
(for 24, 18, 10 px regions, picking with many items under the pointer).
Occlusion queries draw twice when picking nearest,
so worst case 6x draw calls per selection.
Even with these improvements occlusion queries is faster on AMD hardware.
Depth selection is disabled by default, toggle option under select method.
May enable by default if this works well on different hardware.
Reviewed as D2543
For the multi-GPU case users still have to reconfigure the devices they want to use.
Based on patch from Lukas Stockner.
Differential Revision: https://developer.blender.org/D2347
Previously, it was only possible to choose a single GPU or all of that type (CUDA or OpenCL).
Now, a toggle button is displayed for every device.
These settings are tied to the PCI Bus ID of the devices, so they're consistent across hardware addition and removal (but not when swapping/moving cards).
From the code perspective, the more important change is that now, the compute device properties are stored in the Addon preferences of the Cycles addon, instead of directly in the User Preferences.
This allows for a cleaner implementation, removing the Cycles C API functions that were called by the RNA code to specify the enum items.
Note that this change is neither backwards- nor forwards-compatible, but since it's only a User Preference no existing files are broken.
Reviewers: #cycles, brecht
Reviewed By: #cycles, brecht
Subscribers: brecht, juicyfruit, mib2berlin, Blendify
Differential Revision: https://developer.blender.org/D2338
When WITH_INPUT_NDOF is disabled, 3D mouse handling code is removed
from:
- GHOST (was mostly done, finished the job)
- window manager
- various editors
- RNA
- keymaps
The input tab of user prefs does not show 3D mouse settings. Key map
editor does not show NDOF mappings.
DNA does not change.
On my Mac the compiled binary is 42KB smaller after this change. It
runs fine WITH_INPUT_NDOF on or off.
This never really worked that well, and often ended up being far too strong
to be of practical use. The new options do similar things, but with greater
control, so removing this old method now.
This is an attempt to improve the User preferences panel for the 3DView. I made 2 changes:
- I reordered the sequence of properties by grouping them into more logical groups as it made sense to me. Please indicate where to rearrange the order if necessary.
- Then i added some changes in the code to get the groups better arranged visually. I am pretty sure that this can be done much better, more clever, more generic, whatever. This is just what i could figure out on my own so far.
Reviewers: aligorith, sergey, gaiaclary
Subscribers: sergey
Projects: #user_interface
Maniphest Tasks: T47295
Differential Revision: https://developer.blender.org/D1757
GPUBuffer rendering is now done using vertex buffers.
Vertex arrays are completely removed from GL 3.2 core profile, so we'll
have to do this change at some point anyway.
This commit, though big, is not modifying blender in any way. Use should
be exactly as if the vetex buffer option is constantly on.
Implements "Auto-offset" (called "insert offset" in code) feature for Node Editor, developed during and after LSOC :)
Idea and sponsoring by Sebastian König, blendFX, Mathias Eimann, Mikavaa, Knick Design
When you drop a node with at least one input and one output socket onto a an existing connection between two nodes, Auto-offset will, depending on the direction setting, automatically and animated move the left or right and all of its following nodes away to make room for the new node.
The direction for offsetting can be toggled while you are moving the node by pressing „T“.
The auto-offset is enabled by default but can be disabled in the header of the node-editor. The offset margin can be changed in the editing section of the User Preferences.
Thanks a lot to the sponsors, and especially to Sebastian who helped *a lot* with this. That's how users can help developing Blender!
This commit contains all the remained parts needed for initial integration of
OpenSubdiv into Blender's subdivision surface code. Includes both GPU and CPU
backends which works in the following way:
- When SubSurf modifier is the last in the modifiers stack then GPU pipeline
of OpenSubdiv is used, making viewport performance as fast as possible.
This also requires graphscard with GLSL 1.5 support. If this requirement is
not met, then no GPU pipeline is used at all.
- If SubSurf is not a last modifier or if DerivesMesh is being evaluated for
rendering then CPU limit evaluation API from OpenSubdiv is used. This only
replaces the legacy evaluation code from CCGSubSurf_legacy, but keeps CCG
structures exactly the same as they used to be for ages now.
This integration is fully covered with ifdef and not enabled by default
because there are several TODOs to be solved first:
- Face varying data interpolation is not really cleanly implemented for GPU
in OpenSubdiv 3.0. It is also not implemented for limit evaluation API.
This basically means we'll have really hard time supporting UVs.
- Limit evaluation only works with adaptivly subdivided meshes so far, which
basically means all the points of CCG are pushed to the limit. This gives
different result from old code.
- There are some serious optimizations possible on the topology refiner
creation, which would speed up initial OpenSubdiv mesh creation.
- There are some hardcoded asumptions in the GPU and DerivedMesh areas which
could be generalized.
That's something where Antony and Campbell can help, making it so the code
is structured in a way which is reusable by all planned viewport projects.
- There are also some workarounds in the dependency graph to make sure OpenGL
buffers are only freed from the main thread.
Those who'll be wanting to make experiments with this code should grab dev
branch (NOT master) from
https://github.com/Nazg-Gul/OpenSubdiv/tree/dev
There are some patches applied in there which we're working on on getting
into upstream.
team.
There are 3 options here:
1) Keep range (previous behaviour)
2) Seconds - allows a specified offset in seconds around current frame
3) keyframes - zoom to include a number of keyframes around the cursor
Options 2 and 3 have their own properties to tweak the behaviour and all
options can be found in User Preferences->Interface under the 2D
viewports section.
Number 3 will probably need some refinement so commiting here for the
hwoozeberry team to test first.
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.
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 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
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
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.
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!
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
