Split the depsgraph allocation into a separate function
`BKE_scene_ensure_depsgraph()`. Parameters are only passed to those
functions that actually need them. This removes the the "if that boolean
is `false` this pointer is allowed to be `NULL`" logic and more cleanly
decouples code.
No functional changes.
This reverts commit 52f40bcff2.
Apologies for the noise. I caught a problem with this that I hadn't before. I will
commit later after thorough testing.
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
Status Bar can show scene statistics, memory usage, version, etc set by context menu. Part two of T75672.
Differential Revision: https://developer.blender.org/D7557
Reviewed by Julian Eisel
This reverts commit 03c8b048a1.
This commit re-introduced T76837.
While there is a comment explaining why this function is needed,
the naming of the poll function does make this confusing.
The API could be changed to avoid confusion here.
The header of all SPACE_ACTIONs are tagged for redraw. Only when the
action editor is showing the timeline it is needed. No noticeable
performance increase. But better to save some CPU cycles.
Reviewed By: Sybren Stüvel
Differential Revision: https://developer.blender.org/D8074
When playing back animations a playhead is updated in all the animation editors.
The drawing of the playhead is part of the drawing of the main region
`RGN_TYPE_WINDOW` that redraws the whole region.
This change will draw the play head and window scrollers when updating the
screen. This affects the Action editor, Timeline, Graph editor, NLA editor and
Sequence editor. There is noticeable speedup when using complex animation files.
Spring 02_020_A.anim.blend fps went from 11.8 to 12.5 when showing a timeline
and a action editor on a Ryzen 1700.
* When playing back animation the markers don't jump up/down when near the
frame. This could be added back.
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D8066
In big files, ie typical production files, resizing the outliner area would be
very slow. The outliner tree would be rebuilt then, which can easily be avoided.
Channels aren't visually changed by playing back an animation so there
is no need to do this. As rendering channels is using a lot of logic
(filtering animation data, converting fcurves to samples etc) it has an
noticeable overhead.
This change has no functional limitation. Users are still able to do
everything during animation playback. There are other mechanisms in
place that take care of that.
Spring 02_020_A.anim.blend went from 11.8 to 12.0 on a Ryzen 1700. I
didn't test with scenes but it should be more noticeable with more
complex scenes.
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D8073
The operators to open the Preferences, Driver Editor, or Info Log window did
not work when executed from another operator or the Python console. Should work
for all of these now.
I considered using operator properties instead, so the position could be set by
a script, with some fallback (e.g. current window center). But decided that's
not really worth the boilerplate and decreased code readability. Can still be
done if there's a need for it.
Previously the playback mode "Frame Dropping" would not drop the correct
number of frames which would lead to slow playback.
For example, the playback target is 60fps. However we can only muster
around 32 fps.
The delta frames from the last step is in this case ~1.98 or so.
With the previous code, we would floor this. That would lead us to step
forward one frame each time, effectively playing back the animation at
half the speed as we will try to render every frame.
To fix this we simply save the remaining fraction from the previous
frame and use it to compute the current frame step.
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D7694
This was because of the use of uninitialized buffers for TAA.
This patch is a quick fix for the issue which is a missing tagging for a
complete viewport update.
- Changing API for time values from float to double for better precision.
- Fixing minor mistakes in the documentation.
- Fixing minor unnecessary large memory allocation.
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
Follow up of b2ee1770d4 and 10c2254d41, part of T74432.
Now the area and region naming conventions should be less confusing.
Mostly a careful batch rename but had to do few smaller fixes.
Also ran clang-format on affected files.
Both the MS headers and blender headers define the HKEY
which gives all kind of inclusion order issues.
This diff renames all *KEY constants to EVT_*KEY to resolve
this conflict.
Reviewed By: brecht , dfelinto
Differential Revision: http://developer.blender.org/D7164
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
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
