The average times weren't reset so the last draw time would be used
making the FPS seem low for the first ~10 or so frames.
The averages from the last time the playback operator ran were also
used which could be misleading although this was also limited to the
first 8 frames.
Resolve by freeing the ScreenFrameRateInfo on animation start/end.
Calculating the average FPS was done in the draw function which
also overwrote the old value. With multiple viewports the same
time-delta would be written multiple times causing the FPS display
not to use use REDRAW_FRAME_AVERAGE as intended.
Resolve by only calculating the average once per frame change across
multiple viewports.
This was noted in code comments and checked in Python documentation
generation but not at build time.
Since these enums are identifiers that end up included in various places
enforce the `rna_enum_*_items` convention which was noted as
the convention but not followed strictly.
Partially reverts [0], avoids having to deal with multiple prefix types.
[0]: 3ea7117ed1
TransInfo wasn't initialized, causing drawSnapping to depend on
uninitialized stack memory. When `t.tsnap.flag & SCE_SNAP` happened
to be set - snap would draw.
Initialize the TransInfo struct and set SCE_SNAP explicitly.
The situation at this stage of readfile process is now sane enough, that
the regular Pose freeing code can be called, avoiding potential
memleaks.
Note that this whole 'non-Empty object with NULL obdata' case should now
be very hypothetical, since in case a linked obdata goes missing,
Blender will generate and empty place-holder for it at read time.
Tested by artificially setting all Armature objects' obdata pointer to
null in read_data code, and loading some complex production files from
Pets Project.
Keeping a mutable reference to vertex normals for the entire lifetime
of the PBVH structure makes caching the normals and sharing the cache
harder than it should be. Generally code is safer when we reduce the
number of mutable references to data.
Currently the normals are modified in two places. First is the sculpt
mesh normal recalculation. There we can just retrieve the normals from
the mesh each time. Second is the restore from an undo step. That is
unnecessary because the normals are marked for recalculation anyway.
It doesn't even make much sense to store the normals in an undo step
when we can easily recalculate them based on new positions.
This change helps with #110479. These were also the last place that
kept a mutable reference to normals. I tested undo and redo after
sculpting, and it works well for each PBVH type.
Pull Request: https://projects.blender.org/blender/blender/pulls/111470
The `lib_link` callback cannot always be fully replaced/removed, as in
some case it is also doing some validation checks, or data editing based
on the result of lib_linking internal ID pointers.
The callback has been renamed for that purpose, from `read_lib` to
`read_after_liblink`. It is now called after all ID pointers have been
fully lib-linked for the current ID, but still before the call to
`do_versions_after_linking`.
This change should not have any behavioral effect. Although in theory
the side-effect of this commit (to split lib linking itself, and the
validation/further processing code) into two completely separated steps
could have some effects, in practice none are expected, and tests did
not show any changes in behavior either..
Part of implementing #105134: Removal of readfile's lib_link & expand code.
As pointed out in #111426, the filtering for only editable channels
was wrongly set for grease pencil layers,
the layer being editable if it is not locked, and not the other way around.
Pull Request: https://projects.blender.org/blender/blender/pulls/111475
Co-authored-by: Pratik Borhade <PratikPB2123>
"Auto Keying On" display now respects users MINI_AXIS preferences (default, minimal, none), as well as the navigation (en)disable option. No more text overlapping.
Co-authored-by: Abhinav Chennubhotla
Pull Request: https://projects.blender.org/blender/blender/pulls/111356
There was a difference between drag&drop assets from the asset browser
vs. using the search menu (in that doing it from the menu would
correctly hide the data-block selector on the nodegroup).
Since drag&drop in the Node Editor uses `NODE_OT_add_group` (not
`NODE_OT_add_group_asset` as the menu does), we have to add the hiding
here too (for this, an operator property is added which is set in
`node_group_drop_copy` if we are dropping an asset.
Alternatively, we could use `NODE_OT_add_group_asset`, too, but that
would require somehow setting the "asset" context pointer from the
dropbox copy function [how to do this wasnt obvious for me]. In that
case, we would need to set up a separate dropbox with appropriate poll
functions (so there would be one for asset groups and for the the other
groups).
Pull Request: https://projects.blender.org/blender/blender/pulls/111427
If this is not a system override, this leads to the override actually
being reset (which might affect the 3Dview and most probably affects the
Properties Editor).
Now use the same modifiers as used elsewhere for resetting a library
override.
Pull Request: https://projects.blender.org/blender/blender/pulls/111469
Since the 5e1470d1b3 / 0f51b5b599 the `fmodifier_add` operator has
moved to the Channel menu in the Graph Editor and also the channels
context menu in the channels region. The shortcut was not working in the
channels region though since the operator was only in the keymap for the
main region (not the channels region).
Now move the keymap entry to the generic keymap of the Graph Editor so
it works in both regions.
Pull Request: https://projects.blender.org/blender/blender/pulls/111378
Extract a mask from the stencil buffer and use that texture instead
when texture views are not available.
Needed for supporting the Windows ARM software driver.
The workaround is isolated on its own class so it's easy to remove once
it's no longer needed.
Note that while this adds a function to check if texture views are available
(`GPU_texture_view_support`), at the moment this always returns true in
practice, since OpenGL 4.3 is the minimum supported version.
A separate patch will be needed to allow Blender to run using
OpenGL 4.2 + extensions.
Pull Request: https://projects.blender.org/blender/blender/pulls/111402
This PR adds an initial set of nodes using the new rotation socket.
6 nodes build rotations or convert them to other formats, a 7th rotates
a vector with a rotation, and the last inverts rotations.
The design task #109965 describes the choice to use separate nodes
for the rotation construction and separation operations. In the future,
a "Switch Node" operator (#111438) will help to make working with
these separated nodes faster.
- **Axis Angle to Rotation**
- **Rotation to Axis Angle**
- **Combine Quaternion**
- **Separate Quaternion**
- **Euler to Rotation**
- **Rotation to Euler**
- **Rotate Vector**
- **Invert Rotation**
See #92967
Pull Request: https://projects.blender.org/blender/blender/pulls/109030
This fixes a bug where only the time sample for the first frame
is written to a USD animation.
Replaced the hard-coded USDExporterContext::time_code value with a
USDExporterContext::get_time_code function wrapper which is called
from USDAbstractWriter::get_export_time_code() to query the current
frame when writing an animation.
Pull Request: https://projects.blender.org/blender/blender/pulls/111248
Refactor the Add menu in the Compositor, with manually created menus,
inspired by Geometry Nodes.
Minor sorting adjustments by splitting categories in groups, with
separators in between groups, and sorted alphabetically. Compositor
node group assets are also populated in the menus.
This is the first part of the re-organization of the Add menu project,
proposal coming in another patch after this.
Pull Request: https://projects.blender.org/blender/blender/pulls/111282
Though this means a few loops are duplicated, overall the code is
easier to reason about because the cases are separated more. This
makes potential changes to the way normals are stored clearer
(related to !110479), and makes potential optimizations easier too.
The operator handled faces visibility change correctly but not
multires. Use the existing PBVH API function for that, also remove
a redundant call to the function that fetched the attribute pointers
again after the change.
After undoing a visibility change, the visibility is propagated from
multires grids to mesh faces and vertices. This progress was completely
single threaded and more complicated than necessary. Simplify it
using newer C++ data structures and APIs.
The current color was just temporary. The new color
is meant to be in between "Vector" and "Boolean"--
close to the vector color but distinct enough to allow
seeing the difference at a glance.
Pull Request: https://projects.blender.org/blender/blender/pulls/111446
Instead of putting all the tool specific nodes (inputs, operations, etc)
in a single menu, use the existing categories. This is similar to how
the shader editor shows nodes depending on which render engine
is enabled. It's also more scalable for when more tool-specific nodes
are added.
---
I discussed this with Pablo on Tuesday-- it came up when we talked
about the organization of the compositor add menu.
Pull Request: https://projects.blender.org/blender/blender/pulls/111449
Vulkan device was deallocated, but when destroying the GHOST context
the GPU context is reactivated and want to allocate buffers lazilly.
This is solved by de-initializing the device on platform exit, resetting
buffer pointers so double free can be detected.
Pull Request: https://projects.blender.org/blender/blender/pulls/111462
When GLSL sources were first included in Blender they were treated as
data (like blend files) and had no license header.
Since then GLSL has been used for more sophisticated features
(EEVEE & real-time compositing)
where it makes sense to include licensing information.
Add SPDX copyright headers to *.glsl files, matching headers used for
C/C++, also include GLSL files in the license checking script.
As leading C-comments are now stripped,
added binary size of comments is no longer a concern.
Ref !111247