With the popularity of dark themes, and the fact that our default theme
is dark, make the initial background color (before the program fully
loads) a darker shade of grey. {0.25f, 0.25f, 0.25f} versus current
{0.55f, 0.55f, 0.55f}. Also set Windows class background brush to the
same color to remove a potential flash.
Pull Request: https://projects.blender.org/blender/blender/pulls/115968
This adds a new `Bake` node which allows saving and loading intermediate geometries.
Typical use cases we want address with this currently are:
* Bake some data for use with a render engine.
* Bake parts of the node tree explicitly for better performance.
For now, the format that is written to disk is not considered to be an import/export format.
It's not guaranteed that data written with one Blender version can be read by another
Blender version. For that it's better to use proper interchange formats. Better support for
those will be added eventually as well. We also plan an `Import Bake` node that allows
reading the blender-specific baked data independent of the Bake node and at different frames.
The baking works very similar to the baking in the simulation zone (UI and implementation
wise). Major differences are:
* The Bake node has a `Bake Still` and `Bake Animation` mode.
* The Bake node doesn't do automatic caching.
Implementation details:
* Refactored how we create the Python operators for moving socket items so that it also
makes sense for non-zones.
* The `ModifierCache` stores an independent map of `SimulationNodeCache` and
`BakeNodeCache`, but both share a common data structure for the actually baked data.
* For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make
sure that the node is baked even if it's currently not connected to the output.
* Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used
during baking. It's necessary because I want to evaluate the object again even though none
of its inputs changed. The reevaluation is necessary to create the baked data. Using
`DEG_id_tag_update` technically works as well, but has the problem that it also uses the
`DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches
which shouldn't happen here.
* Slightly refactored the timeline drawing so that it can also show the baked ranges of
Bake nodes. It does not show anything for baked nodes with a in Still mode though.
* The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the
code easier to follow compared to the previous nested
`ObjectBakeData > ModifierBakeData > NodeBakeData` data structure.
* The bake operators are disabled when the .blend file is not yet saved. This is technically
only necessary when the bake path depends on the .blend file path but seems ok to force
the user anyway (otherwise the bake path may be lost as well if it's set explicitly).
* The same operators are used to bake and delete single bakes in `Bake` nodes and
`Simulation Zones`. On top of that, there are separate operators of baking and deleting all
simulation bakes (those ignore bake nodes).
* The `Bake` node remembers which inputs have been fields and thus may be baked as attributes.
For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data
may still contain attribute data, even if the inputs to the bake node are disconnected.
* Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes
evaluation from the outside (from the modifier only currently). This is done by providing the
new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes.
Next Steps (mostly because they also involve simulations):
* Visualize nodes that have not been evaluated in the last evaluation.
* Fix issue with seemingly loosing baked data after undo.
* Improve error handling when baked data is not found.
* Show bake node in link drag search.
* Higher level tools for managing bakes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115466
The intent of `ghost_event_proc_timestamp_warning` is to give a console
warning when an event time is outside of an expected 5 second window
around the last time. However if an event happens within the first 5
seconds we get an overflow in a calculation and we get warnings for
normal times within the range.
Pull Request: https://projects.blender.org/blender/blender/pulls/116164
Link/append code sets the scene pointer to `null` when the active
scene is a linked one, to avoid attempt to instantiate linked data
(objects or collections) into a linked scene, which is forbidden.
However, code was still calling some functions expecting a valid scene
pointer, leading to crash.
It is unclear when exactly this issue was introduced code wise. From a
user perspective, it seems to have been revealed between 3.6 and 4.0
release (bisect points at 00a36cbf24, which does not seem to be
directly related...).
In any case, the fix is trivial and safe, so should we do another 4.0
bugfix release, this commit should be backported.
There are operators in Blender that allow the user to import multiple
files at the same time, however this functionality is only implemented
when importing with blender's file browser, drag and drop files only
takes first selected file.
The patch adds support for drag and drop multiple files.
Notes:
* The files are filtered according to the extension of the first
selected file.
* Not all operators that import files support importing multiple files,
so they will still import one.
* Changes must be made to allow importers to read all file paths.
This will be used in upcoming drag & drop import.
Pull Request: https://projects.blender.org/blender/blender/pulls/107230
Report suspicious time-stamps as they could cause bugs which are
difficult to troubleshoot.
Currently the time-stamps are only used for double-click detection but
we may want to use them in the future, so ensure they're valid.
Print an error when two events are handled in the last second and the
current event has a time-stamp 5 seconds before or after the current
time.
Due to changes in the build environment shader_builder wasn't able to
compile on macOs. This patch reverts several recent changes to CMake files.
* dbb2844ed9
* 94817f64b9
* 1b6cd937ff
The idea is that in the near future shader_builder will run on the buildbot as
part of any regular build to ensure that changes to the CMake doesn't break
shader_builder and we only detect it after a few days.
Pull Request: https://projects.blender.org/blender/blender/pulls/115929
This is a smaller rewrite/refactor of the VSE copy paste code to use the file copy buffer logic that is used in other places of Blender.
This makes Blender able to copy paste between Blender processes.
It can also paste successfully after closing and reopening Blender.
Other than that, the functionally should remain the exact same as the current copy paste operator with one exception: Scene strips does not retain their scene pointer when pasting into the same file.
This is to make it consistent with how it was before when copy pasting between .blend files.
(The scene data for the scene strips were never copied in when doing that)
Logic for pulling in or linking scenes into new or current files are purposely left for later when a proper proposal of how this would work in a nice fashion is done.
Now the strip data gets copied either fully or partially besides for scene strips. There only the script data gets copied and not the scene data.
If there is a audio/video data block of the same name as in the paste data, it will be reused to reduce potential duplication of data.
Pull Request: https://projects.blender.org/blender/blender/pulls/114703
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
Prefer the name 'hit_result' since 'result' was sometimes used for
a vector of GPUSelectResult and is often used a functions return value.
Use hit_results for the span/vector and hit_result for a single hit.
Also assign struct members for new GPUSelectResult as it reads better
and avoids depending on struct order.
`wmDragActiveDropState` contains a `bContextStore` unique pointer, so
when constructing/destructing an object of this type `BKE_context.hh`
had to be included. It wouldn't be obvious why this include is necessary
in some cases. And the pointer is otherwise managed internally in the
source file, so the need for this include shouldn't bleed into other
files.
Make sure the unique pointer construction/destruction happens in the
translation unit of the source file that otherwise also manages it.
Avoids include in #107230.
Texture usage flag `GPU_TEXTURE_USAGE_MIP_SWIZZLE_VIEW`
was originally implemented and used too conservatively for many
cases in which the underlying API flags were not required.
Renaming to `GPU_TEXTURE_USAGE_FORMAT_VIEW` to reflect
the only essential use case for when a texture view is initialized with
a different texture format to the source texture. Texture views can
still be created without this flag when mip range or base level is
adjusted,
This flag is still required by stencil views and internally by the Metal
backend for certain feature support such as SRGB render toggling.
Patch also includes some small changes to the Metal backend to
adapt to this new compatibility and correctly capture all texture view
use-cases.
Related to #115269
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/115300
Address regression in [0] which allowed wmKeyMapItem::properties to
remain set when a valid wmKeyMapItem::ptr can't be created because the
wmOperatorType isn't available (temporarily in the case of reloading).
Resolve by freeing wmKeyMapItem::properties when the `ptr` isn't set.
Also add null pointer check not to assume wmKeyMapItem::properties
implies an allocated wmKeyMapItem::ptr. Something which is already
accounted for everywhere else.
[0]: 08e5f94a70
Also add null pointer check not to assume wmKeyMapItem::properties
implies an allocated wmKeyMapItem::ptr. Something which is already
accounted for everywhere else.
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 was fixed by [0] however that fix didn't account for IMB
sometimes freeing GPU resources created by color management
(resolved by [1] which effectively reverted [0]).
Resolve by re-initializing IMB in the case of drag & drop.
[0]: 51467b0611
[1]: 05c56603a9
