| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Only the volume object is exposed in the user interface. It is based on OpenVDB
internally. Drawing and rendering code will follow in another commit.
https://wiki.blender.org/wiki/Source/Objects/Volume
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Volumes
Hair and PointCloud object types are hidden behind a WITH_NEW_OBJECT_TYPES
build option. These are unfinished, and included only to make it easier to
cooperate on development in the future and avoid tricky merges.
https://wiki.blender.org/wiki/Source/Objects/New_Object_Types
Ref T73201, T68981
Differential Revision: https://developer.blender.org/D6945
|
|
NOTE: While most of the milestone 1 goals are there, a few smaller features and
improvements are still to be done.
Big picture of this milestone: Initial, OpenXR-based virtual reality support
for users and foundation for advanced use cases.
Maniphest Task: https://developer.blender.org/T71347
The tasks contains more information about this milestone.
To be clear: This is not a feature rich VR implementation, it's focused on the
initial scene inspection use case. We intentionally focused on that, further
features like controller support are part of the next milestone.
- How to use?
Instructions on how to use this are here:
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/How_to_Test
These will be updated and moved to a more official place (likely the manual) soon.
Currently Windows Mixed Reality and Oculus devices are usable. Valve/HTC
headsets don't support the OpenXR standard yet and hence, do not work with this
implementation.
---------------
This is the C-side implementation of the features added for initial VR
support as per milestone 1. A "VR Scene Inspection" Add-on will be
committed separately, to expose the VR functionality in the UI. It also
adds some further features for milestone 1, namely a landmarking system
(stored view locations in the VR space)
Main additions/features:
* Support for rendering viewports to an HMD, with good performance.
* Option to sync the VR view perspective with a fully interactive,
regular 3D View (VR-Mirror).
* Option to disable positional tracking. Keeps the current position (calculated
based on the VR eye center pose) when enabled while a VR session is running.
* Some regular viewport settings for the VR view
* RNA/Python-API to query and set VR session state information.
* WM-XR: Layer tying Ghost-XR to the Blender specific APIs/data
* wmSurface API: drawable, non-window container (manages Ghost-OpenGL and GPU
context)
* DNA/RNA for management of VR session settings
* `--debug-xr` and `--debug-xr-time` commandline options
* Utility batch & config file for using the Oculus runtime on Windows.
* Most VR data is runtime only. The exception is user settings which are saved
to files (`XrSessionSettings`).
* VR support can be disabled through the `WITH_XR_OPENXR` compiler flag.
For architecture and code documentation, see
https://wiki.blender.org/wiki/Source/Interface/XR.
---------------
A few thank you's:
* A huge shoutout to Ray Molenkamp for his help during the project - it would
have not been that successful without him!
* Sebastian Koenig and Simeon Conzendorf for testing and feedback!
* The reviewers, especially Brecht Van Lommel!
* Dalai Felinto for pushing and managing me to get this done ;)
* The OpenXR working group for providing an open standard. I think we're the
first bigger application to adopt OpenXR. Congratulations to them and
ourselves :)
This project started as a Google Summer of Code 2019 project - "Core Support of
Virtual Reality Headsets through OpenXR" (see
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Some further information, including ideas for further improvements can be found
in the final GSoC report:
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/Final_Report
Differential Revisions: D6193, D7098
Reviewed by: Brecht Van Lommel, Jeroen Bakker
|
|
|
|
|
|
This commit is a full refactor of the grease pencil modules including Draw Engine, Modifiers, VFX, depsgraph update, improvements in operators and conversion of Sculpt and Weight paint tools to real brushes.
Also, a huge code cleanup has been done at all levels.
Thanks to @fclem for his work and yo @pepeland and @mendio for the testing and help in the development.
Differential Revision: https://developer.blender.org/D6293
|
|
This commit replaces the "Use Gradient" checkbox theme option with an
enum and implements a radial background.
Whith this change, it should be easier to implemet other types of more
complex background types, like a world space oriented gradient.
Reviewed By: billreynish, fclem, brecht
Differential Revision: https://developer.blender.org/D6825
|
|
Issue raised by Sergey in D6634
|
|
The term guide makes sense on it's own in this context.
|
|
Also remove dead code which checked for SPACE_TIME.
|
|
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
|
|
Also correct some outdated symbol references,
add missing 'name' commands.
|
|
Custom profiles in bevel allows the profile curve to be controlled by
manually placed control points. Orientation is regularized along
groups of edges, and the 'pipe case' is updated. This commit includes
many updates to comments and changed variable names as well.
A 'cutoff' vertex mesh method is added to bevel in addition to the
existing grid fill option for replacing vertices.
The UI of the bevel modifier and tool are updated and unified.
Also, a 'CurveProfile' widget is added to BKE for defining the profile
in the interface, which may be useful in other situations.
Many thanks to Howard, my mentor for this GSoC project.
Reviewers: howardt, campbellbarton
Differential Revision: https://developer.blender.org/D5516
|
|
|
|
This makes it so that some display related properties of the file
browser state are remembered in the Preferences. Otherwise, users often
end up doing the same set up work over and over again, so this is a
nice way to save users some work.
It's typical for other file browsers to remember their state too, so
another benefit is having a more conventional behavior, meeting user
expectations better.
Some points:
* We currently store: Window size, display type, thumbnail size,
enabled details-columns, sort options, "Show Hidden" option. More can
be added easily.
* No changes are stored to the Preferences if "Auto-save Preferences"
is disabled. This is how Quick Favorites behave too and it's a
reasonable way to make this behavior optional.
* The Preferences are only saved to permanent memory upon closing
Blender, following existing convention of Preferences and Quick
Favorites.
* If settings weren't actually changed, Preference saving is skipped.
* Only temporary file browsers save their state (invoked through
actions like open or save), not regular file browser editors. These
are usually used for different purposes and workflows.
* Removes "Show Thumbnails" Preferences option. It would need some
special handling, possibly introducing bugs. For users, this
simplifies behavior and should make things more predictable.
Left in DNA data in case we decide to bring it back.
Reviewers: brecht, #user_interface, billreynish, campbellbarton
Reviewed By: #user_interface, William Reynish, Campbell Barton, Brecht
van Lommel (quick first pass review in person)
Maniphest Tasks: T69460
Differential Revision: https://developer.blender.org/D5893
|
|
|
|
|
|
|
|
|
|
Needed for getting struct member offsets.
|
|
This doesn't cause problems at the moment,
it just makes using name sizes possible in the future.
|
|
|
|
Use existing theme & preferences for defaults.
|
|
This provides an API to access structs
with their members set to default values:
- DNA_struct_default_get(name)
- DNA_struct_default_alloc(name)
Currently this is only used for scene & view shading initialization,
eventually it can be used for RNA defaults and initializing
DNA struct members on file reading.
|
|
|
|
|
|
T68035 by @luzpaz
|
|
Note that BLI_STATIC_ASSERT use in headers is likely to cause this
error again, we could have a version that takes a unique ID
to be used in headers.
|
|
Renaming was only done to ED_time_scrub_ui.h, function names
and struct members used term 'scrubbing' which is ambiguous.
|
|
Passing a const char** to MEM_recallocN lead to
C4090 'function': different 'const' qualifiers
warnings with MSVC
|
|
passing a const pointer to BLI_ghash_insert causes warning
C4090 'function': different 'const' qualifiers
with MSVC
|
|
|
|
Allow versioning code to use checks which use run-time naming
instead of the old names which are only listed in dna_rename_defs.h.
Addresses T64791.
|
|
|
|
|
|
There is now a checkbox to enable/disable depth of field per camera. For Eevee
this replace the scene level setting. For Cycles there is now only an F-Stop
value, no longer a Radius.
Existing files are converted based on Cycles or Eevee being set in the scene.
Differential Revision: https://developer.blender.org/D4882
|
|
|
|
After a lot of thinking about this, I decided that all operation modes
that I've tried over the past couple of years, including the original
2.79 one, have their uses after all. Thus the only reasonable solution
is to add yet another option.
The modes are:
- Strict: The current 2.80 mode, which overrides the original scaling
of the non-free axes to strictly preserve the volume. This is the most
obvious way one would expect a 'Maintain Volume' constraint to work.
- Uniform: The original 2.79 mode, which assumes that all axes have been
scaled the same as the free one when computing the volume. This seems
strange, but the net effect is that when simply scaling the object
uniformly with S, the volume is preserved; however, scaling the non-
free axes individually allows deviating from the locked volume.
This was obviously intended as a more or less convenient UI tool.
- Single Axis: My own variant of the intent of the Uniform scale, which
does volume-preserving if the object is scaled just on the Free axis,
while passing the non-free axis scaling through. I.e. instead of
uniform S scaling, the user has to scale the object just on its
primary axis to achieve constant volume. This can allow reducing the
number of animation curves when only constant volume scaling is needed,
or be an easier to control tool inside a complex rig.
|
|
|
|
|
|
As far as I can tell, there is no technical reason why the B-Bone
segment thickness scaling can't be separated into two axes. The
only downside is the increase in complexity of the B-Bone settings,
but this is inevitable due to the increase in flexibility.
Updating the file is somewhat complicated though, because F-Curves
and drivers have to be duplicated and updated to the new names.
Reviewers: campbellbarton
Subscribers: icappiello, jpbouza
Differential Revision: https://developer.blender.org/D4716
|
|
|
|
|
|
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
|
|
No functional change, this adds LIB definition and args to cmake files.
Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS'
since there are many platforms/configurations that could break when
changing linking order.
Manually add and enable WITHOUT_SORTED_LIBS to try building
without sorted libs (currently fails since all variables are empty).
This check will eventually be removed.
See T46725.
|
|
Use doxy references to function and enums,
also correct some names which became out of sync.
|
|
|
