No functional change, just cleaning up the shader code a bit.
Part of this is removing dead code (the discard was never called), and
part is shuffling mix/max around based on feedback by Sybren Stüvel.
This is a necessary step for EEVEE's new arch. This moves more data
to the draw manager. This makes it easier to have the render or draw
engines manage their own data.
This makes more sense and cleans-up what the GPUViewport holds
Also rewrites the Texture pool manager to be in C++.
This also move the DefaultFramebuffer/TextureList and the engine related
data to a new `DRWViewData` struct. This struct manages the per view
(as in stereo view) engine data.
There is a bit of cleanup in the way the draw manager is setup.
We now use a temporary DRWData instead of creating a dummy viewport.
Development: fclem, jbakker
Differential Revision: https://developer.blender.org/D11966
This fixes T91828.
The current value of `GL_PACK_ALIGNMENT` may result in crash in the `gpu` module if the buffer is not aligned.
Differential Revision: https://developer.blender.org/D12720
Use dashes to represent the function flow (while keeping continuous
lines for the data-flow).
It is important to tell both flows apart (the data and the function
flow). The sockets help with that, the noodles help this further.
The "data flow" is evaluated at every single node. A user can inspect
the output sockets of those nodes and have a glimpse at their values.
The "function flow" (nodes) however is only evaluated in the geometry
nodes. The noodles are not transporting data in the same sense of the
"data flow". All that can be inspected are the attributes the functions
depend on.
Having this clearly communicated should help users to inspect the
nodetrees, read and understand the different flows in the same tree.
---
Known limitations:
At the moment the dash lines are not equidistant:
* It would be nice to get the "uv.x" to be resampled for the bezier curve
so the dashes are equally distributed in the curve.
* Using distance between the P3 and P0 instead of the real bezier curve
length seems to be fine.
---
Full disclaimer:
Changes with that much of a visual impact tend to be controversial. So
far the main feedback is that dashed lines can be associated to broken
link, and that there are better ways to represent the flows (or
different information that should be visually represented).
I'm fully aware of that. However dashed lines are already used in the
viewport and outliner to indicate (hierarchical) relation. Besides,
other approaches (double-lines, having the data flow to be more
distinct, ...) didn't pan out in the end (or didn't look as good as
this).
---
Impact in other editors:
The compositor uses mostly a "data flow" nodetree, so no change is
expected there.
The shader nodetree is one that could but doesn't have to change its
visual language.
The shader nodetree uses mostly "function flow" with some "data flow" nodes.
One can argue that it should be adapted to follow the
same pattern as geometry nodes (with the new noodles and the diamond
sockets). Oh the other hand, a shader nodetree has a single context.
When a node depends on the "UV", there is only one UV at a time for the
entire nodetree. So it can also be treated as a psedo "data flow"
nodetree if we want to avoid too many changes in other parts of Blender.
Differential Revision: https://developer.blender.org/D12602
This makes it easier to spot which links contain fields and which
contain data. Actually, the patch makes all other links a bit thicker.
However, with soon-to-be-implemented theme changes, the
perceived thickness will be the same as before.
This is part of T91563.
Differential Revision: https://developer.blender.org/D12646
Goal is to add the length attribute to the Hair Info node, for better control over color gradients or similar along the hair.
Reviewed By: #eevee_viewport, brecht
Differential Revision: https://developer.blender.org/D10481
No functional change.
The shader is complicated by itself, having hardcoded values makes it
even more cryptic.
I also renamed the shader because the shader is not for the keyfarme diamond only,
but for all the keyframe shapes.
Differential Revision: https://developer.blender.org/D12615
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycleshttps://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
Some GPU's have support for compute shaders, but don't support
GLSL 4.3. This resulted in compiler errors and crashes.
This issue could have been solved by supporting older GLSL languages but
that would have been a hassle to get it right. We already have a
fallback in place for GPU's that don't support compute shaders at all.
This addresses reduced visibility of scenes (as displayed in the VR
headset) that can result from the 8-bit color depth format currently
used for XR swapchain images.
By switching to a swapchain format with higher color depth (RGB10_A2,
RGBA16, RGBA16F) for supported runtimes, visibility in VR should be
noticeably improved.
However, current limitations are lack of support for these higher
color depth formats by some XR runtimes, especially for OpenGL.
Also important to note that GPU_offscreen_create() now explicitly
takes in the texture format (eGPUTextureFormat) instead of a
"high_bitdepth" boolean.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D9842
While trying to get Blender 2.93.x LTS to build fine on all release architectures in Debian, I noticed that the misleading use of "mips" as integer variable caused problems when compiling on mips64el. The patch should fix the issue.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D12194
ID data-blocks that could be accessed from Python and weren't freed
using BKE_id_free_ex did not release the Python reference count.
Add BKE_libblock_free_data_py function to clear the Python reference
in this case.
Add asserts to ensure no Python reference is held in situations
when ID's are copied for internal use (not exposed through the RNA API),
to ensure these kinds of leaks don't go by unnoticed again.
rBfb87d236edb7 made the values returned by `projmat_dimensions` more
standardized following the documentations. But the functions in Blender
that called `projmat_dimensions` followed a proposal that these values
corresponded to a distance of 1m of clip.
Adjust these functions to follow the new algorithm.
This patch fixes an issue with missing faces when assigning a material slot other than the first to faces on AMD TAHITI cards. Refer to T78390 and T74024 for a description of this issue.
This patch also incorporates fix from T78390 for KAVERI.
{F9029258}
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D9305
The crash happens because `GPU_offscreen_create` is called with `err_out` `NULL`.
This patch proposes a solution within the `GPU_offscreen_create` itself
and raises an error report in the interface if a menu is called with
dimensions beyond what is supported.
Ref T89782
Maniphest Tasks: T89782
Differential Revision: https://developer.blender.org/D11927
This makes node trees with long links that cross other nodes easier to work with.
Dimmed links will be ignored by various modal operators like cut and reroute insertion.
Differential Revision: https://developer.blender.org/D11813
During initialization of the platform a debug message is generated and
interpreted by de callback. Here the platform is checked what requires
an initialized platform.
Fixed by giving the platform check less priority in the check.
