Only use the term len & maxlen when they represent the length & maximum
length of a string. Instead of the available bytes to use.
Also include the data they're referencing as a suffix, otherwise it's
not always clear what the length is in reference to.
- Rename name/filename/path to filepath when it's used for full paths.
- Rename name/path to dirpath when it refers to a directory.
- Rename file to filepath or path (when it may be a file or dir).
- Rename ImBuf::name & anim::name to filepath.
Keep these operations separate to simplify path handling logic & docs.
Many callers passed NULL and there were times paths were passed in which
didn't make any sense (where the paths had already been made absolute).
These functions are almost identical, the main difference being
BLI_join_dirfile didn't trim existing slashes when joining paths
however this isn't an important difference that warrants a separate
function.
Using varargs had the disadvantages, replace with a macro which has
some advantages.
- Arguments are type checked.
- Less verbose.
- Unintended NULL arguments would silently terminate joining paths.
- Passing in a NULL argument warns with GCC.
Rename BKE_appdir_folder_id_version to
BKE_appdir_resource_path_id_with_version because BKE_appdir_folder_id
and BKE_appdir_folder_id_version didn't accept compatible arguments.
Also add notes to GHOST_getSystemDir & GHOST_getUserDir that
BKE_appdir_resource_path_id(..) should be used instead (in most cases).
Even though individual USER/SYSTEM paths could be set using environment variables,
it wasn't possible to override the USER or SYSTEM paths.
This meant the result of `bpy.utils.resource_path('USER')` &
`bpy.utils.resource_path('SYSTEM')` could still be used by scripts,
making the Blender session potentially the default USER directory
(even when `BLENDER_USER_CONFIG`, `BLENDER_USER_SCRIPTS` &
`BLENDER_USER_DATAFILES` all point elsewhere).
Resolve by adding environment variables:
- BLENDER_USER_RESOURCES
- BLENDER_SYSTEM_RESOURCES
These will be used for `bpy.utils.resource_path('USER')` &
`bpy.utils.resource_path('SYSTEM')`, as well as a basis for user &
system directories, unless those environment variables are
set (`BLENDER_USER_*` or `BLENDER_SYSTEM_*`).
Resolves issue raised by T101389.
Example usage & output:
{P3225}
Reviewed By: brecht
Ref D16111
The following changes have been made to this attribute with
WITH_PYTHON_MODULE is defined:
- Defaults to an empty string (instead of pointing to __init__.so).
- It's writable, so script authors can point to a valid Blender binary.
`where_am_i(..)` is no longer used by BKE_appdir_program_path_init,
there is now a separate code-path for setting the initial program
directory, calls after this can be used to set the binary path.
Replace the argument with an in ifdef in BKE_appdir_program_path_init.
At the time `blenkernel` didn't define WITH_PYTHON_MODULE, since it does
now there is no need for an argument. With the minor benefit of fewer
preprocessor checks in the main() function.
Building WITH_PYTHON_MODULE was creating a "bpy" module that required
Blenders data-files to be located in the module search path too.
This mean that a typical installation on Linux would create:
- `/usr/lib/python3.10/site-packages/bpy.so`
- `/usr/lib/python3.10/site-packages/3.4`
(containing `scripts` & `datafiles`).
The new behavior creates:
- `/usr/lib/python3.10/site-packages/bpy/__init__.so`
- `/usr/lib/python3.10/site-packages/bpy/3.4`
With the advantage that the "bpy" directory is the self contained Python
module.
No changes are needed for the module loading logic as the mechanism to
swap in blend internal Python "bpy" module
(defined in `release/scripts/modules/bpy/__init__.py`)
works the same in both instances.
Thanks to Brecht for macOS support.
Reviewed by brecht
Ref D15911
BKE_appdir_program_path_init would override the module path extracted
from the Python module, replacing it with the Python executable.
This caused the data files not to be found and the module not to load.
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Replaces `HOME` environment variable usage for user
directories like in D12802.
Reviewed By: #platform_macos, brecht
Differential Revision: https://developer.blender.org/D13212
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
Accessing the default directory in the file selector
would crash if HOME was undefined.
Add BKE_appdir_folder_default_or_root which never returns NULL.
Initial defaults for userdef->fontdir for Mac and Linux.
See D12802 for more details.
Differential Revision: https://developer.blender.org/D12802
Reviewed by Campbell Barton
Introduces `BKE_appdir_folder_caches` to get the folder that
can be used to store caches. On different OS's different folders
are used.
- Linux: `~/.cache/blender/`.
- MacOS: `Library/Caches/Blender/`.
- Windows: `(%USERPROFILE%\AppData\Local)\Blender Foundation\Blender\Cache\`.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D12822
Also replace integer with bool in Ghost API when only used as boolean,
and uint8* with char* in Ghost API when variable is a string.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11617
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
This changes the following items:
- package name is now `blender-3.0.0-git.09eb04c0a865-windows64`
rather than `blender-3.00.0-git.09eb04c0a865-windows64`
- Fix version resource for blender.exe not building
- Data directories are now `3.0\...` rather than `3.00\....`
- User prefs are now in:
`c:\Users\users\AppData\Roaming\Blender Foundation\Blender\3.0\`
rather than:
`c:\Users\users\AppData\Roaming\Blender Foundation\Blender\3.00\`
- Updating startup & preferences from previous release
has a special exception for 3.0 to check for 3.93 and older.
See T87532
Ref D10986
When doing a debug build on windows, blender will
start with the following warning:
"Unable to find the python binary, the multiprocessing
module may not be functional!"
The root cause for this issue is: for a debug build
the python binary is called python_d.exe rather than
just python.exe
This change fixes BKE_appdir_program_python_search
to look for the _d suffix for debug builds on windows
Differential Revision: https://developer.blender.org/D9775
Reviewed by: Campbell Barton
The previous `BKE_appdir_folder_default()` was confusing, it would return the
home directory on Linux and macOS, but the Documents directory on Windows.
Plus, for the Asset Browser, we want to use the Documents directory for the
default asset library on all platforms.
This attempts to clean up the API to avoid confusion, while adding the newly
needed functionality.
* `BKE_appdir_folder_default()` should behave as before, but the implementation
changed:
** Removes apparently incorrect usage of `XDG_DOCUMENTS_DIR` on Unix systems -
this seems to be a config file variable, not an environment variable. Always
use `$HOME` instead, which this ended up using anyway.
** On Windows it doesn't attempt to use `%HOME%` anymore and gets the Documents
directory directly.
* Add `BKE_appdir_folder_home()` to gives the top-level user directory on all
platforms.
* Add `BKE_appdir_folder_documents()` to always get the user documents
directory on all platforms.
There should be no user noticable behavior change.
Differential Revision: https://developer.blender.org/D9800
Reviewed by: Brecht Van Lommel
This patch adds support for AOVs in EEVEE. AOV Outputs can be defined in the
render pass tab and used in shader materials. Both Object and World based
shaders are supported. The AOV can be previewed in the viewport using the
renderpass selector in the shading popover.
AOV names that conflict with other AOVs are automatically corrected. AOV
conflicts with render passes get a warning icon. The reason behind this is that
changing render engines/passes can change the conflict, but you might not notice
it. Changing this automatically would also make the materials incorrect, so best
to leave this to the user.
**Implementation**
The patch adds a copies the AOV structures of Cycles into Blender. The goal is
that the Cycles will use Blenders AOV defintions. In the Blender kernel
(`layer.c`) the logic of these structures are implemented.
The GLSL shader of any GPUMaterial can hold multiple outputs (the main output
and the AOV outputs) based on the renderPassUBO the right output is selected.
This selection uses an hash that encodes the AOV structure. The full AOV needed
to be encoded when actually drawing the material pass as the AOV type changes
the behavior of the AOV. This isn't known yet when the GLSL is compiled.
**Future Developments**
* The AOV definitions in the render layer panel isn't shared with Cycles.
Cycles should be migrated to use the same viewlayer aovs. During a previous
attempt this failed as the AOV validation in cycles and in Blender have
implementation differences what made it crash when an aov name was invalid.
This could be fixed by extending the external render engine API.
* Add support to Cycles to render AOVs in the 3d viewport.
* Use a drop down list for selecting AOVs in the AOV Output node.
* Give user feedback when multiple AOV output nodes with the same AOV name
exists in the same shader.
* Fix viewing single channel images in the image editor [T83314]
* Reduce viewport render time by only render needed draw passes. [T83316]
Reviewed By: Brecht van Lommel, Clément Foucault
Differential Revision: https://developer.blender.org/D7010
