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.
This container is type safe and contains a few nice optimizations,
although they shouldn't make a big difference here in practice. The
hashing now uses our default hashing method which reduces code
complexity and seems to perform slightly better in my tests.
For a Heist shot with a highly complex library overrides hierarchy in
the Outliner this reduces the tree building time from around 25 to 23.6
seconds here. However the main design change for performance is yet to
come, all this is just general code refactoring (which at least
shouldn't make performance worse).
The realtime compositor crashes when some nodes are unlinked.
This happens for GPU material nodes if it was compiled into its own
shader operation. Since it is unlinked, the shader operation will have
no inputs, a case that the current code didn't consider.
This patch fixes this by skipping code generation for inputs if no
inputs exist for the shader operation.
- Use upper-case for defines.
- Use u-prefix for unsigned types.
- Use snake case for struct members.
- Use const struct for unicode_blocks & arguments.
- Use doxy style comments for struct members.
- Add doxy sections for recently added code.
- Correct code-comments (outdated references).
- Remove 'e' prefix from struct UnicodeBlock/FaceDetails
(normally used for enums).
Use `inline constexpr` instead of `static constexpr` to prevent these
variables from being duplicated in each translation unit that includes
the BLI_any.hh header.
Differential Revision: https://developer.blender.org/D15698
Change `cd_loop_uv_offset` from signed to unsigned, forcing
a crash if passed invalid input.
Differential Revision: https://developer.blender.org/D15722
This function never succeeded as an off by one error checking the last
character always indexed the null byte.
The 'for' loop was broken as of [0] since the unsigned number could wrap
around with some RNA paths causing out of bounds memory access.
This is an example where tests would have caught the problem early on,
RNA path tests are planned as part of D15558.
[0]: 11b4d0a3c3
Gamma correction for glyph coverage values.
See D13376 for details and examples.
Differential Revision: https://developer.blender.org/D13376
Reviewed by Julian Eisel
- Turn storage into an object with "automatic" memory management (RAII)
so freeing is implicit and reliable.
- Turn functions into member functions, to have the data and its
functions close together with controlled access that increases
encapsulation and hiding implementation details.
- Use references to indicate null is not an expected value.
- Related minor cleanup (comments, use const etc.)
Couldn't spot any changes in performance.
This way you can benchmark the tree rebuilding by simply commenting out
a single line. Not that it was difficult before, but this makes it as
easy as it gets, with basically no knowledge of existing benchmarking
tools required.
Simplifies code quite a bit, since this was doing the typical work of
such a container. I may remove this vector entirely as I'm working on
performance fixes, not sure, but simplifying this helps reason about the
design.
Couldn't spot performance differences in some benchmarks, and I wouldn't
expect any. Maybe some minor onces thanks to the small buffer
optimization of `blender::Vector`.
