Logic in FileBrowser and/or `BKE_blendfile_library_path_explode`
probably changed at some point, and the generic 'invalid filetype' error
message was reached before the path is compared to current blendfile path.
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
Renames `OB_MODE_EDIT_GPENCIL`, `OB_MODE_PAINT_GPENCIL`, `OB_MODE_SCULPT_GPENCIL`, `OB_MODE_WEIGHT_GPENCIL`, `OB_MODE_VERTEX_GPENCIL, and the context modes` to `*_LEGACY`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109648
Image buffer display in the animation player was difficult to reason
about because it could potentially access the entire play-state on load
(frame-step, modifier keys... etc) even though these are are only
intended to be used interactively.
Add playanim_toscreen_ex which is called by both
playanim_toscreen & playanim_toscreen_on_load which doesn't use the
PlayState struct.
Replace `typedef struct X {} X;` with `struct X {};`
In some cases the first and last name didn't match although this
is rarely useful, even a typo in some cases, e.g. TrachPathPoint.
Small inconsistency leftover from ebb5643e59, 32bbfbb06e and 7ef8389dad
commits.
Weirdly enough that was not a problem on Linux X11, but did cause
issues at leaast on Windows and Linux Wayland.
Similar to 5f16e24cc9, this adds support for edit mode
to the point cloud object type, which is currently hidden behind an
experimental option. No interaction is possible yet, for now this
can be used as a testing for a node-group-operator-only mode.
The multiplication sign looks like an "x" but should be used in its
stead to display calculations and dimensions such as "1920x1080". It
is supported in many fonts including DejaVu Sans, the font currently
used for the UI.
Pull Request: https://projects.blender.org/blender/blender/pulls/106388
No user visible changes expected.
This function was added in 86b2cf4574 as a more type safe and more
convenient way of setting button callbacks. So use it for simple cases.
Avoid BLI_strcpy_rlen use as this has the same problems as strcpy
(it just returned the length which is useful at times).
Use memcpy instead when the size is calculated immediately beforehand.
Other uses of have been replaced by BLI_string_join_array that prevents
buffer overruns by taking the destination buffer length.
This is cached in Render, and gets cleared along with render pass GPU
textures when there is no editor open using it, or a new final render is
started.
The context and texture pool are cached. But the evaluator is re-created
every time as this only runs on compositing node changes, which require
recreating it anyway (unlike the viewport where e.g. camera navigation
does not need a new evaluator).
Pull Request: https://projects.blender.org/blender/blender/pulls/108909
Before this change the ImBuf struct had dedicated fields for the
buffer data. Now the color space is stored inside of the struct
which wraps around the buffer information.
This only changes the field placement, without changing the way
it is handled. In the future one might imagine that operations
like stealing buffer data should null-ify the buffer colorspace
pointer. Such changes would need to have more accurate thinking
before implementation.
Should be no functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/109291
This was due to a wrong mapping of tools in the toolbar.
The fix makes sure that the correct selection tools are used for the
old grease pencil objects.
In order to accomplish this properly, the new grease pencil objects
use their own edit mode context.
This way the two objects are cleanly seperated.
* Store per RenderPass in RenderResult.
* Caches are cleared when starting rendering, to make more memory available
to GPU rendering.
* Caches are cleared on UI changes, when no compositing node editor and no
image editor with a render result or viewer node image is visible.
* Store 3 channel RGB passes as such, and set alpha 1 in shader.
This is an intermediate step before implementing GPU backed ImBuf, to
improve performance and figure out cache eviction.
Pull Request: https://projects.blender.org/blender/blender/pulls/108818
`AssetHandle` is meant as temporary design and should be replaced by
`AssetRepresentation`. This moves us another step closer to that.
Rather than taking data from the volatile asset handle and storing that
in the drag data, store the (more persistent) asset representation there
and access data from it where needed.
Hopefully now the behavior is fully consistent with before the refactor,
current implemented one by this commit:
- When loading factory settings file on startup, go full-screen.
- In all other startup cases, use size as stored in the startup .blend
file.
Regression from ebb5643e59 and 32bbfbb06e.
* opengl_context -> system_gpu_context. This is the operating system OpenGL,
Metal or Vulkan context provided by GHOST.
* gpu_context -> blender_gpu_context. This is the GPUContext provided by
the Blender GPU module, which wraps the GHOST context and adds some state.
* Various functions create/destroy/enable/disable both contexts, these have
just gpu_context in the name now.
Pull Request: https://projects.blender.org/blender/blender/pulls/108723
When opening 'homefile' (i.e. startup or factory startup) at Blender
start (i.e. when there is no existing WM yet), the size of the windows
in the newly read WM is reset to zero, which will then cause `WM_check`
to re-size them the the maximum possible size on current monitor.
Regression from ebb5643e59.
This commit affects:
* Reading undo steps from memfile (aka 'Global Undo');
* Handling of UI IDs (WindowManager, Workspaces and Screens) when
opening a .blend file.
While no major changes are expected from a user PoV, there may be some
unexpected changes in rare edge-cases. None has been identified so far.
Undo step loading should be marginally faster (`setup_app_data` itself
is 2-3 times faster, as it does not do remapping anymore, which makes the
whole 'read undo step' process about 20% faster - but the most
time-consuming step on undo is the depsgraph processing, which remains
unchanged here).
This commit also solves some bugs (crashes) in some relatively uncommon
cases, like e.g. if the WM had an IDProperty pointing at an object and
UI is not loaded when opening a new .blend file with the 'Load UI' option
enabled (as in previous code on file opening WM ID would never be
remapped).
From a more technical side, this commit aims mainly at cleaning things
up, in preparation for the introduction of new 'no undo, no readfile'
type of handling (as part of the Brush Assets project):
- Prevent WM code from doing (too much) horrible ID 'management' on
its WM when opening a new file. It used to remove current WM from
the Main database, store it in a temporary own list, and then free
it itself...
- Trying to make the complex logic behind WM handling on file reading a
bit more easy to follow, at least way more documented in code.
- Keep the handling of 'IDs being re-used from old Main' in a single
place, as much as possible:
-- Readfile code itself in undo case (because it's more efficient,
and undo case is in a way simpler than actual .blend file
reading case). The whole `blo_lib_link_restore` block of code
is also removed.
-- (Mostly) setup_app_data code in actual file reading case.
- Sanitize the usage of the 'libmap' in readfile code in undo case
(waaaaay too many pointers were added there, which was hiding some
other issues in the related code, and potentially causing (in
rare cases) memory addresses collisions.
Pull Request: https://projects.blender.org/blender/blender/pulls/108016
Failure to load an image-buffer during animation playback would exit,
display a text warning instead because it could potentially
exit during user interaction/playback.
References to data-blocks in a material were stored in-memory and could
crash if the data-blocks referenced by the material no longer existed
when pasting.
Resolve by using a blend-file for material copy/paste, matching how the
clipboard works in the 3D view-port.
Currently there is no support for including indirectly linked
data-blocks when pasting the material. Instead, data-blocks are restored
by name, by inspecting the current file.
This also fixes a crash where the `SpaceNode::nodetree` could point to
freed memory when pasting a material.
Ref !108496.
Includes contributions by @mont29.
