Some callers that access the extension operated on the end of the path
even when there was no extension. Using this avoids having to assign
the end of the string using a separate check.
The file extension was copied into a buffer without checking it's size.
While large extensions aren't typical, some callers used small fixed
size buffers so an unusually named file could crash.
While replacing the extension with an empty string works,
it required a redundant string-size argument which took a dummy
value in some cases. Avoid having to pass in a redundant string size by
adding a function that strips the extension.
Finding the extension included hidden files (starting with a '.'),
now finding the extension matches Python's `os.path.splitext` behavior
which has the advantate a hidden file is not considered one long
extension - with an empty name part.
Also update code to use BLI_path_extension in cases which previously
in-lined this logic.
BLI_path_frame_get path argument is now const,
it was being manipulated unnecessarily.
The following functions only supported back slashes on WIN32,
which can use both forward and back slashes.
- BLI_path_append
- BLI_path_append_dir
- BLI_path_slash_ensure
- BLI_path_slash_rstrip
Follow up to [0] which is a more limited bug-fix.
[0]: a16ef95ff6
Support both forward and back slashes on WIN32.
Forward slashes for paths in WIN32 was removed in [0] (for BLI_path_join)
& [1] (for BLI_path_name_at_index), this is correct on UNIX as back
slashes can be used in paths but not on WIN32 which can use both.
Note that other path functions such as BLI_path_append &
BLI_path_slash_ensure should be updated too, but this is out of scope
for a bug-fix.
Documenting and ensuring Windows path handling functions all handle
forward slashes can be done separately.
[0]: 8f7ab1bf46
[1]: 511ae22264
Reviewed By: harley
Ref D16700
The new Xcode 14.1 brings the new Apple Clang compiler which
considers sprintf unsafe and geenrates deprecation warnings
suggesting to sue snprintf instead. This only happens for C++
code by default, and C code can still use sprintf without any
warning.
This changes does the following:
- Whenever is trivial replace sprintf() with BLI_snprintf.
- For all other cases use the newly introduced BLI_sprintf
which is a wrapper around sprintf() but without warning.
There is a discouragement note in the BLI_sprintf comment to
suggest use of BLI_snprintf when the size is known.
Differential Revision: https://developer.blender.org/D16410
Normalize is no longer necessary as BLI_path_name_at_index skips
redundant path components such as "//" and "/./".
This has the advantage that the path length isn't limited to FILE_MAX.
While relatively harmless, BLI_path_parent_dir wasn't returning failure
when passed in "./" which wouldn't succeed.
Instead of adding a ".." and normalizing, normalize the path and remove
the last directly. This is simpler than inspecting the resulting path
to see if normalize removed it or not.
Add additional tests which failed previously.
Regression in [0] on WIN32 caused joining paths {"//", "path"} to
result in "//\path".
This made the file selector show paths with a "\" prefix.
Add an exception for WIN32 where an initial path of forward slashes
is joined without a back-slash.
[0]: 8f7ab1bf46
The check for BLI_path_normalize having succeeded only checked for a
trailing "../" which isn't correct. This caused going up a directory
in the file selector to do nothing on directories ending with "..".
This also caused an empty path to expand into "../" because
BLI_path_extension_check didn't account for this case.
Resolve using BLI_path_name_at_index which extracts the last component
of the path without having to match the the surrounding slashes.
The logic to go up a directory (using "..") ran before stripping "/./"
from the path. This caused "/a/b/./../" to result in "/a/b/"
instead of "/a/". Now redundant characters are removed before before
checking for ".." in paths.
Include test to ensure this works as expected.
Previously both slashes were considered when joining paths, meaning
slashes that were part of the path name could be stripped before joining
the path.
Prefer using the native path separator for low level path functions,
callers can always convert slashes into the expected direction if they
need. This also matches BLI_path_append behavior.
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.
This function did multiple things making it difficult to know
what was intended by the caller:
- Directory & file join.
- Expand relative '//' prefix to an optional directory.
- Expand drive letters on windows (guessing with fall-backs).
- Switch slashes to native direction.
This functionality wasn't needed as the full directory was always passed
in, so guessing the drive letter wasn't needed.
If functionality to add drive letters onto paths is needed in the future
a function that only does this can be added.
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
Assert when "//" prefixed relative paths are passed to
BLI_path_cmp_normalized as this can't be expanded
and it's possible the paths come from different blend files.
Changes to recent addition: c85c52f2ce.
Having both BLI_paths_equal and BLI_path_cmp made it ambiguous
which should be used, as `BLI_paths_equal` wasn't the equivalent to
`BLI_path_cmp(..) == 0` as it is for string equals macro `STREQ(..)`.
It's also a more specialized function which is not used for path
comparison throughout Blender's internal path handling logic.
Instead rename this `BLI_path_cmp_normalized` and return the result of
`BLI_path_cmp` to make it clear paths are modified before comparison.
Also add comments about the conventions for Blender's path comparison
as well as a possible equivalent to Python's `os.path.samefile`
for checking if two paths point to the same location on the file-system.
Add `USD Preview Surface From Nodes` export option, to convert a
Principled BSDF material node network to an approximate USD Preview
Surface shader representation. If this option is disabled, the original
material export behavior is maintained, where viewport setting are saved
to the Preview Surface shader.
Also added the following options for texture export.
- `Export Textures`: If converting Preview Surface, export textures
referenced by shader nodes to a 'textures' directory which is a
sibling of the USD file.
- `Overwrite Textures`: Allow overwriting existing texture files when
exporting textures (this option is off by default).
- `Relative Texture Paths`: Make texture asset paths relative to the
USD.
The entry point for the new functionality is
`create_usd_preview_surface_material()`, called from
`USDAbstractWriter::ensure_usd_material()`. The material conversion
currently handles a small subset of Blender shading nodes,
`BSDF_DIFFUSE`, `BSDF_PRINCIPLED`, `TEX_IMAGE` and `UVMAP`.
Texture export is handled by copying texture files from their original
location to a `textures` folder in the same directory as the USD.
In-memory and packed textures are saved directly to the textures folder.
This patch is based, in part, on code in Tangent Animation's USD
exporter branch.
Reviewed By: sybren, HooglyBoogly
Differential Revision: https://developer.blender.org/D13647
This implements the design detailed in T92696 to support virtual
filenames for UDIM textures. Currently, the following 2 substitution
tokens are supported:
| Token | Meaning |
| ----- | ---- |
| <UDIM> | 1001 + u-tile + v-tile * 10 |
| <UVTILE> | Equivalent to u<u-tile + 1>_v<v-tile + 1> |
Example for u-tile of 3 and v-tile of 1:
filename.<UDIM>_ver0023.png --> filename.1014_ver0023.png
filename.<UVTILE>_ver0023.png --> filename.u4_v2_ver0023.png
For image loading, the existing workflow is unchanged. A user can select
one or more image files, belonging to one or more UDIM tile sets, and
have Blender load them all as it does today. Now the <UVTILE> format is
"guessed" just as the <UDIM> format was guessed before.
If guessing fails, the user can simply go into the Image Editor and type
the proper substitution in the filename. Once typing is complete,
Blender will reload the files and correctly fill the tiles. This
workflow is new as attempting to fix the guessing in current versions
did not really work, and the user was often stuck with a confusing
situation.
For image saving, the existing workflow is changed slightly. Currently,
when saving, a user has to be sure to type the filename of the first
tile (e.g. filename.1001.png) to save the entire UDIM set. The number
could differ if they start at a different tile etc. This is confusing.
Now, the user should type a filename containing the appropriate
substitution token. By default Blender will fill in a default name using
the <UDIM> token but the user is free to save out images using <UVTILE>
if they wish.
Differential Revision: https://developer.blender.org/D13057
