Add a preference to "Work Offline" system preference as well as command
line options `--offline-mode` & `--online-mode`
(which overrides the preference).
This option is displayed in the initial setup screen too.
This is currently respected by:
- Check for updates on startup
- Disables running an update when enabling extensions.
When Blender is launched with `--offline-mode` the option cannot be
enabled in the preferences. This is intended for environments
where internet access is intentionally disallowed.
Background: with Blender supporting access to online-repositories
as well as 3rd party extensions themselves potentially accessing the
internet. This setting provides a way for users to disable online
functionality.
This prevents error messages when online access fails in environments
without internet access as well as the ability for users who prefer
Blender doesn't access the internet to have one place to turn this off.
While it does not enforce limitations on add-ons, 3rd party scripts
are expected to respect this setting using `bpy.app.internet_offline`.
The details for this will be handled along with other policies scripts
are expected to follow.
Ref !121994
While additional context is typically useful to include,
this is such a corner-case that it's not expected script authors
would run into this during regular development.
Support freedesktop file association on Linux/Unix via the command line
arguments: `--register{-allusers}` `--unregister{-allusers}` as well
registration actions from the user preferences.
Once registered, the "Blender" application is available from launchers
and `*.blend` files are assoisated with the blender binary used for
registration.
The following operations are performed:
- Setup the desktop file.
- Setup the file association & make it default.
- Copy the icon.
- Setup the thumbnailer (`--register-allusers` only).
Notes:
- Registering/unregistering for all users manipulates files under
`/usr/local` and requires running Blender as root.
From the command line this can be done using `sudo`, e.g.
`sudo ./blender --register-allusers`.
From the GUI, the `pkexec` command is used.
- Recent versions of GNOME execute the thumbnailer in a restricted
environment (`bwrap`) requiring `blender-thumbnailer` to be copied
into `/usr/local/bin` (synlinks don't work).
So thumbnailing copies the binary rather than linking and only works
when registering for all users.
Ref !120283
MoltenVK original intent was to let developers work on a mac system developing
for the vulkan eco-system. MoltenVK doesn't support all the features that we
require and would require additional workarounds to be actually supported.
It is not expected that we will release Blender with MoltenVK for this reason.
But it still has value for shader developers to validate shaders on metal and
vulkan on a single platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/117940
While calling into scripts with an empty `Main` shouldn't be possible
under normal circumstances, I ran into this during development.
This situation is meant to print an error, add a null check so it works
as expected.
Making arguments call into Python was impractical because Python
is only initialized for ARG_PASS_FINAL.
Replace "--command" specific logic with a general method of arguments
requesting to be executed once all sub-systems have been initialized.
Without this, the `main()` function needs hard coded logic to support
any time an argument needs to use Python internally.
Replace: `{BLENDER_RESOURCE_PATH_USER}/extensions`
With: `{BLENDER_USER_EXTENSIONS}`
This follows BLENDER_USER_CONFIG & BLENDER_USER_SCRIPTS conventions.
Reading the environment variable and accessible via
`bpy.utils.user_resource('SCRIPTS')`
Add support for add-ons to define commands using the new argument
`-c` or `--command`.
Commands behave as follows:
- Passing in a command enables background mode without the need to pass
in `--background`.
- All arguments following the command are passed to the command
(without the need to use the `--` argument).
- Add-ons can define their own commands via
`bpy.utils.register_cli_command` (see examples in API docs).
- Passing in `--command help` lists all available commands.
Ref !119115
Other minor changes:
- Remove reference to `TMP` environment variable in the `--help` text
as this isn't a posix standard and is noted as something that may be
removed in the future.
- Show WIN32 `TEMP` when showing all help text so it will be included
in the user manual.
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
This PR adds a new command line argument to validate all statically
defined shaders. It is useful for platform support to understand
what isn't working.
It only checks statically defined shaders. Dynamic shaders (EEVEE/Compositor)
can still be fail.
The report is printed to console. After checking with windows platform and
triaging we could also add it to gpu debug script. There is a risk of adding it there
as it might crash and don't store any output.
Pull Request: https://projects.blender.org/blender/blender/pulls/117326
Running background mode now behaves as if the "-noaudio" was passed in.
The -setaudio command now has a "Default" option which can be used
in the rare cases audio playback is desired in background mode. e.g.
blender --background -setaudio Default
Ref !118192
- "can not" -> "cannot" in many places (ambiguous, also see
Writing Style guide).
- "Bezier" -> "Bézier": proper spelling of the eponym.
- Tool keymaps: make "Uv" all caps.
- "FFMPEG" -> "FFmpeg" (official spelling)
- Use MULTIPLICATION SIGN U+00D7 instead of MULTIPLICATION X U+2715.
- "LClick" -> "LMB", "RClick" -> "RMB": this convention is used
everywhere else.
- "Save rendered the image..." -> "Save the rendered image...": typo.
- "Preserve Current retiming": title case for property.
- Bend status message: punctuation.
- "... class used to define the panel" -> "header": copy-paste error.
- "... class used to define the menu" -> "asset": copy-paste error.
- "Lights user to display objects..." -> "Lights used...": typo.
- "-setaudio require one argument" -> "requires": typo.
Some issues reported by Joan Pujolar and Tamar Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/117856
`UUID` generally stands for "universally unique identifier". The session identifier that
we use is neither universally unique, nor does it follow the standard. Therefor, the term
"session uuid" is confusing and should be replaced.
In #116888 we briefly talked about a better name and ended up with "session uid".
The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender
already.
This patch changes all uses of "uuid" to "uid" where it's used in the context of a
"session uid". It's not always trivial to see whether a specific mention of "uuid" refers
to an actual uuid or something else. Therefore, I might have missed some renames.
I can't think of an automated way to differentiate the case.
BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`)
but there it also does not mean "session uid", so it's *not* changed by this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117350
Update the command line help message to reflect the actual image output
formats available. Remove mention of IRIZ and DDS, rename MPEG to
FFMPEG. HDR and TIFF are always valid now.
Pull Request: https://projects.blender.org/blender/blender/pulls/115987
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Avoid awkward kludges with IMB_init/exit & IMB_ffmpeg_init calls.
The animation player was responsible for calling IMB_exit, not IMB_init,
this complicated drag & drop which needed to re-internalize IMB before
returning.
Delay initializing IMB since none of the other argument handlers
depend on it, make wm_main_playanim_intern responsible for calling
both initialization & exit calls for IMB.
Also expand code comments for ARG_PASS_SETTINGS.
This commit makes using (most of) `BKE_report` API safe in
multi-threaded situation.
This is achieved by adding a `std::mutex` lock to the `ReportList`
struct (in a slightly convoluted way unfortunately, due to this being a
DNA struct). This lock is then used to make most operations on
`Reportlist` data thread-safe.
Note that while working on this, a few other minor issues aroze in
existing usages of Reportlist by the WM code, mainly the fact that
`wm_init_reports` and `wm_free_reports` were both useless:
- init was called in a context where there is not yet any WM, so it
was doing nothing.
- free was called on a WM that would be later freed (as part of Main
freeing), which would also call cleanup code for its `reports` data.
Both have been removed.
Further more, `wm_add_default` (which is the only place where a WM ID is
created) did not initialize properly it reports data, this has been
fixed.
This change is related to the wmJob thread-safety tasks and PRs (#112537,
!113548).
Pull Request: https://projects.blender.org/blender/blender/pulls/113561
This PR enables vulkan backend as experimental option.
It will only be available in alpha builds on Linux and Windows.
This option is highly experimental and enabled to get some insight
on supported platforms. Don't expect a fully working Blender
yet. Also don't expect it to have usable performance.
**What is known to not work?**
* OCIO textures are not supported on Intel and AMD GPUs. sRGB/Standard is supported
on those platforms.
* AMD Polaris based GPUs on Linux will generate a crash when drawing the 3d cursor as it
doesn't support the needed vertex format. Comment out `DRW_draw_cursor` in `DRW_draw_region_info`.
* The colors in the node editor and sequencer are of as sRGB viewports aren't detected correctly.
* The image / UV editor isn't working as many texture formats haven't been tested yet. Some
tweaks are also needed to do correct depth testing.
* 3D Viewport is known to be flickering. Sometimes workbench doesn't display anything.
* 3D Viewport wireframe will crash as it uses a framebuffer with gaps between color attachments,
which isn't supported yet. (#113141)
* Rotate the view widget is partially drawn due to incompatible depth clipping.
* GPU Selection isn't working. It is expected to be solved when Overlay-Next will become the
default engine. For now disable GPU depth picking in the preferences.
* Cycles/EEVEE are known to not work with Vulkan yet. Cycles requires Vulkan Pixel Buffer.
Cuda <-> Vulkan interop might require a different approach than OpenGL as Vulkan doesn't allow
importing memory from a Cuda context. EEVEE uses features that aren't available yet in the backend
* Workbench is working, except Workbench shadows.
* EEVEE-Next basics are working. Shadows, lights are known to be not working. Materials/Shading
works in simple scenes. Changes are expected in EEVEE-Next that will break Vulkan compatibility
in the near future.
* Systems with multiple GPUs is not expected to work.
* Wayland support is in development and requires some iterations. You can start Blender, but
the protocols are not aligned yet.
* OpenXR hasn't been modified and is expected to fail.
* The backend is very strict when mis-using the GPU module. In debug builds it may crash
on asserts.
* Older drivers/GPUs might not have all the features that we require. The workarounds
for the missing features still need to be implemented.
**A word about performance**
In the project planning we focus first on stability and platform support. The performance of Vulkan is
around 20% of what we want to achieve. The reason is that each command sent to the
GPU is done one at a time. The implementation even waits until we have feedback that the GPU
is idle again.
Geometry is currently stored in System RAM. The GPU will read and cache the data when
accessing geometry. This slows down when using objects with much geometry.
Some performance features like MDI (Multi-Draw-Indirect) hasn't been implemented and
falls back to Single Draw Indirect.
**Why enable it is an experimental option?**
* Ensures that new features are being tested with Vulkan
* Ensure that building with Vulkan is possible on supported platforms
* Get feedback from developers if Vulkan can run on their system or that
there are special cases that we are not aware of. Main development
environment has been Linux/X11 with occasionally testing using Windows.
* Validate Add-ons that use the `gpu` module.
* Possible to enable GLSL validation on the buildbot. (Needs more work).
* Does it compile on all machines or does it require more changes to cmake
config. We expect it to be able to compile without installing the Vulkan SDK.
The Vulkan SDK is a very powerful tool, but only when actually doing GPU
development. Otherwise it is an overhead which slows down other
activities.
**How can the backend be enabled?**
Currently the Vulkan backend can be enabled per Blender session by starting
using the command line argument `--gpu-backend vulkan`. In the future, when
the backend is more mature, we will add a user preference to switch between
OpenGL and Vulkan.
Pull Request: https://projects.blender.org/blender/blender/pulls/113057
Enable tests for EEVEE Next.
As a workaround for allowing the use of EEVEE Next (still an
experimental feature) with `--factory-startup`, `arg_handle_engine_set`
enables the feature when `-E BLENDER_EEVEE_NEXT` is used.
In addition, EEVEE Next is always registered, so it's available when
calling `WM_init`.
If it's actually disabled, it will be immediately unregistered after that.
Notes:
- `get_gpu_device_type` always fails with error:
> GPU API is not available in background mode
- Setup and tests are the same as EEVEE. There are many tests that
only make sense for Cycles, and many EEVEE Next features that are
not actually tested.
Pull Request: https://projects.blender.org/blender/blender/pulls/112161
Blender has the option to disable SSBO support. This was accessible
as a command line option `--debug-gpu-disable-ssbo`.
Blender 4.0 has a hard requirement for OpenGL 4.3 which includes
SSBO support by default.
This PR removes the command line option as it makes no sense to
have it anymore.
Related to #112224
Pull Request: https://projects.blender.org/blender/blender/pulls/112571
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
