This is done by checking the number of bitplanes from the image buffer.
We assume that for float buffer to use the same bitplanes as it was a
byte buffer.
Then, the data of the image buffer is packed at the start of the `rect` or
`float_rect` before upload.
**Statistics - einar.v004.blend **
Note that not all grayscale textures have been stored as BW images so the
amount of memory that can be reduced would be more.
Without patch
```
104 Textures - 3294.99 MB (3294.47 MB over 32x32), 37 RTs - 192.52 MB.
Avg. tex dimension: 2201.88x1253.51 (2283.53x2202.13 over 32x32)
464 Buffers - 25.01 MB total 1.24 MB IBs 23.50 MB VBs.
3512.52 MB - Grand total GPU buffer + texture load
```
Patch applied
```
104 Textures - 2917.66 MB (2917.14 MB over 32x32), 39 RTs - 215.45 MB.
Avg. tex dimension: 2221.38x1252.75 (2323.28x2253.47 over 32x32)
467 Buffers - 25.01 MB total 1.24 MB IBs 23.51 MB VBs.
3158.13 MB - Grand total GPU buffer + texture load.
```
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D15484
Since {rB2542fda14d85}, `r_node` is an unused parameter.
Changed `load_texture_image` to reflect that.
Differential Revision: https://developer.blender.org/D15759
Main motivation is from T54314 where there was no way to read from a
Viewer image datablock after setting another viewer node active.
Part of the problem was addressed in rB16d329da284c (where handlers for
the compositing background job were added so that you can act after the
compositor has run), however there was still the remaining issue that
setting another viewer node active would not properly tag the node
NODE_DO_OUTPUT. This forced users into a complicated workaround (using
switch nodes feeding into a single viewer node).
Now handle NODE_DO_OUTPUT properly in RNA, too, and do proper updates so
that behavior from RNA matches that of the Node Editor when setting a
viewer node active.
ref T54314.
Reviewed By: JacquesLucke
Maniphest Tasks: T54314
Differential Revision: https://developer.blender.org/D15203
When changing the frame_number of a grease pencil frame, the grease
pencil object is not updated correctly. The frame stays where it
previously was.
The fix adds a `property_update` callback to the `frame_number` RNA
property.
Maniphest Tasks: T99524
Reviewed By: antoniov
Differential Revision: https://developer.blender.org/D15394
This makes workspaces more translatable:
- New Workspace menu
- header
- preset menus
- preset entries
- workspace names upon factory file template load
- new workspace name upon workspace addition
To properly translate those names, an extraction function for
workspace names from app templates was added as well.
(Do not do anything when loading a user-saved file!)
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15727
This was the case when the "Show in Editmode" option was used and a
vertexgroup affected the areas.
Probably an oversight in {rBdeaff945d0b9}?, seems like deforming
modifiers always need to call `BKE_mesh_wrapper_ensure_mdata` in
`deformVertsEM` when a vertex group is used.
Maniphest Tasks: T100578
Differential Revision: https://developer.blender.org/D15756
Since {rBb0cb0a785475}, changing the active texture in the Node Editor
would also change the current image in the Image Editor.
While this was an overall improvement, this was not desired when the
image currently looked at was a `Render Result` or a `Viewer Node`
(artists usually want to keep focus on these).
With this patch, syncing the active texture change from the Node Editor
to the Image Editor will now only happen if the Image Editor's current
image is not a Render Result or a Viewer Node.
NOTE: Syncing the active paint slot to the Image Editor still happens
(even if the Image Editor's current image is not a Render Result or a
Viewer Node), behavior was not changed since this is a much more
explicit action while texture painting and probably desired in that
case.
Maniphest Tasks: T99493
Differential Revision: https://developer.blender.org/D15749
The realtime compositor sometimes produces fuzzy results when the
interpolation is set to bilinear. This was due to the domain realization
shader, which incorrectly sampled the input image.
This patch fixes such fuzziness by introducing a 0.5 offset to evaluate
the sampler at the center of pixels. Additionally, it makes sure the
centring offset is an integer offset by taking its floor, retaining the
previous 0.5 offset even with the difference in size is odd.
Add missing labels, and also add tooltips.
Unfortunately there is no way currently to extract two messages from a
single 'function' call, so unless those type of macros become very
widely used, would keep it as manual tagging.
Also disambiguate `case` in text context, pretty sure English is one of
the very rare languages to use this word for character case too.
- Keying (keyframe insertion)
- Roughness (particle children)
- New image, collection, text (in menus)
- Parents (particles)
- Wrap (text)
- Light (add menu)
- Empty (volume add menu)
- Empty (empty add menu)
- Cycles (f-curve modifier)
- Drag (workspace tool type)
- Power (light intensity)
- Power (math nodes)
This last change also moves all math operations in nodes to the
ID_nodetree context. It's needed only for some operations, but we
can't be more granular here.
Also...
- Fix context extraction for interpolation mode headers in F-Curves
and GPencil interpolation operator
- Enable new translation: "Slot %d" in image editor
- Fix an English message in the node editor:
"Replace the input image's alpha channels by..." -> channel
Ref. T43295
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15694
`UI_context_active_but_prop_get_templateID` became much more widely used
with recent rBfec254364884, which revealed that it did not do any check
on actual type of data it accesses, resulting easily in undefined
behavior.
Now also check the callback function pointer, this should be safe
enough.
Patch by @Severin (Julian Eisel), many thanks!
There was a memory leak in the GPU code generator for the compositor
output. It was just due to a missing free in the GPU code generator
destructor, so this patch makes sure it is freed.
This fixes a compilation error in eevee_light_culling_debug shader.
Some compilers complained when accessing the same data twice. Unclear
why. We should investigate that this change doesn't harm the performance
of the shader.
Although the light is a local variable it might clutter available
registers. If so it will harm developers during debugging.
Due to a copy-paste error there was an out of bound read. Some drivers
didn't complain about it, others did. This patch fixes the compilation
error by accessing the array within bounds.
Imeplemented **ViewLayer.aovs.remove** by Adding a new rna function to call the internal **BKE_view_layer_remove_aov**, removed assert from **BKE_view_layer_remove_aov**.
Reviewed By: jbakker
Maniphest Tasks: T99259
Differential Revision: https://developer.blender.org/D15341
Restore old hitbox for connecting links to sockets.
Commit rBd9d97db018d2 improved the node socket snapping when nodes
are close together by decreasing the tolerance around the cursor when
checking for nodes in front, that might occlude the socket.
In doing so it also reduced the hitbox of the node socket itself that
extended outside of the node.
This commit restores the old node socket hitbox while keeping the
improved behavior when nodes are close together with the following
changes:
1) When looking for the socket under the cursor, iterate through the
nodes front to back, which prioritizes node sockets in the foreground.
2) Instead of checking for another node underneath the cursor it checks
if the socket is actually occluded by another node.
The way the occlusion test for sockets is tweaked you can now connect to
sockets that are only partially occluded, which is a bit more forgiving
than previously.
Reviewed By: Hans Goudey
Differential Revision: http://developer.blender.org/D15731
Restore old hitbox for connecting links to sockets.
Commit rBd9d97db018d2 improved the node socket snapping when nodes
are close together by decreasing the tolerance around the cursor when
checking for nodes in front, that might occlude the socket.
In doing so it also reduced the hitbox of the node socket itself that
extended outside of the node.
This commit restores the old node socket hitbox while keeping the
improved behavior when nodes are close together with the following
changes:
1) When looking for the socket under the cursor, iterate through the
nodes front to back, which prioritizes node sockets in the foreground.
2) Instead of checking for another node underneath the cursor it checks
if the socket is actually occluded by another node.
The way the occlusion test for sockets is tweaked you can now connect to
sockets that are only partially occluded, which is a bit more forgiving
than previously.
Reviewed By: Hans Goudey
Differential Revision: http://developer.blender.org/D15731
Fix possibility of getting invalid fixed-pitch advance size.
See D15735 for more details.
Differential Revision: https://developer.blender.org/D15735
Own Code.
When displaying the Hierarchies view of the Library Overrides display
mode in a specific Heist production file, Blender would become
unresponsive for about 30 seconds and every redraw in the Outliner would
lag noticably. Issue is that the sum of hierarchy elements is multiple
thousands, and that really brings the Outliner to its knees. I've looked
into some improvents and committed a few minor ones already, but it
seems it's really the big sum of elements causing the issue. There
doesn't appear to be a single bottle-neck.
To work around this, "lazy build" children, so that children of
collapsed elements are not actually created. This brings the tree
building down to some tens of miliseconds, and redrawing becomes
rather lag-free again, even with big parts of the tree un-collapsed.
Problem: Searching still needs to build the entire tree, so it's
essentially unusable right now. Should we disallow searching
altogether?
Makes the lazy-building (where children are only built when the parent
isn't collapsed) more generic, so more display modes can use it. So far
this was hardcoded for the "Data API" display mode.
This will be used to work around a big performance issue with the
Library Overrides Hierachies view in a complex production file, see
following commit.
When displaying the Hierarchies view of the Library Overrides display
mode in a specific Heist production file, Blender would become
unresponsive for about 30 seconds and every redraw in the Outliner would
lag noticably. Issue is that the sum of hierarchy elements is multiple
thousands, and that really brings the Outliner to its knees. I've looked
into some improvents and committed a few minor ones already, but it
seems it's really the big sum of elements causing the issue. There
doesn't appear to be a single bottle-neck.
To work around this, "lazy build" children, so that children of
collapsed elements are not actually created. This brings the tree
building down to some tens of miliseconds, and redrawing becomes
rather lag-free again, even with big parts of the tree un-collapsed.
Problem: Searching still needs to build the entire tree, so it's
essentially unusable right now. Should we disallow searching
altogether?
Makes the lazy-building (where children are only built when the parent
isn't collapsed) more generic, so more display modes can use it. So far
this was hardcoded for the "Data API" display mode.
This will be used to work around a big performance issue with the
Library Overrides Hierachies view in a complex production file, see
following commit.
