| Age | Commit message (Collapse) | Author |
|---|
|
|
|
libdecor (for window decorations) was crashing on exit with the shader
builder, avoid the crash by calling the "background" system creation
function which doesn't initialize window management under Wayland.
|
|
This patch moves the GLSL shaders and their infos to the compositor
module as decided by the EEVEE & Viewport module. This is a non
functional change.
Differential Revision: https://developer.blender.org/D16360
Reviewed By: Clement Foucault
|
|
This patch adds a placeholder for the vulkan backend.
When activated (`WITH_VULKAN_BACKEND=On` and `--gpu-backend vulkan`)
it might open a blender screen, but nothing should be visible as
none of the functions are implemented or otherwise crash on a nullptr.
This is expected as this is just a placeholder. The goal is to add shader compilation
+validation to this backend as one of the next steps so we can validate
changes to existing shaders on OpenGL, Metal and Vulkan at the same time.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D16338
|
|
This is a convenience when one needs to often change the current framebuffer
and avoid the overhead of creating many Main/Simple passes.
|
|
This allows using instancing in other ways, like resources indexing.
|
|
Accidentally added in rB2510bd3a5f35d14f5e0e098c79a776916d273223
|
|
|
|
Adds the possibility of having a little number on top of icons.
At the moment this is used for:
* Outliner
* Node Editor bread-crumb
* Node Group node header
For the outliner there is almost no functional change. It is mostly a refactor
to handle the indicators as part of the icon shader instead of the outliner
draw code. (note that this was already recently changed in a5d3b648e3e2).
The difference is that now we use rounded border rectangle instead of
circles, and we can go up to 999 elements.
So for the outliner this shows the number of collapsed elements of a
certain type (e.g., mesh objects inside a collapsed collection).
For the node editors is being used to show the use count for the data-block.
This is important for the node editor, so users know whether the node-group
they are editing (or are about to edit) is used elsewhere. This is
particularly important when the Node Options are hidden, which is the
default for node groups appended from the asset libraries.
---
Note: This can be easily enabled for ID templates which can then be part
of T84669. It just need to call UI_but_icon_indicator_number_set in the
function template_add_button_search_menu.
---
Special thanks Clément Foucault for the help figuring out the shader,
Julian Eisel for the help navigating the UI code, and Pablo Vazquez for
the collaboration in this design solution.
For images showing the result check the Differential Revision.
Differential Revision: https://developer.blender.org/D16284
|
|
Previously this was using `GPU_SHADER_TEXT` as default value indicating
an "unset" state. This wasn't documented in the definition (and so
D16284 added a new enumerator that broke this). Plus code was assuming
this enumerator would always have the value 0 without specifying this in
the definition either.
In this case it's easy to not rely on the enum value at all, and just
use `std::optional` to add a "unset" state.
Differential Revision: https://developer.blender.org/D16303
|
|
Add command line argument to switch gpu backend. Add `--gpu-backend` option to
override the gpu backend selected by Blender.
Values for this option that will be available in releases for now are:
* opengl: Force blender to select OpenGL backend.
During development and depending on compile options additional values can exist:
* metal: Force Blender to select Metal backend.
When this option isn't provided the internal logic for GPU backend selection will be used.
Note that this is at the time of writing the same as always selecting the opengl backend.
Reviewed By: fclem, brecht, MichaelPW
Differential Revision: https://developer.blender.org/D16297
|
|
MTLBatch and MTLDrawList implementation enables use of Metal Viewport for UI and Workbench. Includes Vertex descriptor caching and SSBO Vertex Fetch mode draw call submission.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D16101
|
|
The attribute node already allows accessing attributes associated
with objects and meshes, which allows changing the behavior of the
same material between different objects or instances. The same idea
can be extended to an even more global level of layers and scenes.
Currently view layers provide an option to replace all materials
with a different one. However, since the same material will be applied
to all objects in the layer, varying the behavior between layers while
preserving distinct materials requires duplicating objects.
Providing access to properties of layers and scenes via the attribute
node enables making materials with built-in switches or settings that
can be controlled globally at the view layer level. This is probably
most useful for complex NPR shading and compositing. Like with objects,
the node can also access built-in scene properties, like render resolution
or FOV of the active camera. Lookup is also attempted in World, similar
to how the Object mode checks the Mesh datablock.
In Cycles this mode is implemented by replacing the attribute node with
the attribute value during sync, allowing constant folding to take the
values into account. This means however that materials that use this
feature have to be re-synced upon any changes to scene, world or camera.
The Eevee version uses a new uniform buffer containing a sorted array
mapping name hashes to values, with binary search lookup. The array
is limited to 512 entries, which is effectively limitless even
considering it is shared by all materials in the scene; it is also
just 16KB of memory so no point trying to optimize further.
The buffer has to be rebuilt when new attributes are detected in a
material, so the draw engine keeps a table of recently seen attribute
names to minimize the chance of extra rebuilds mid-draw.
Differential Revision: https://developer.blender.org/D15941
|
|
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
|
|
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
|
|
This allows the creation of texture arrays from 1D/2D/Cube texture.
This is useful when the shader expect a texture array but the original
texture isn't.
|
|
Currently lookup of Object and Instancer attributes is completely
duplicated between Cycles, Eevee and Eevee Next. This is bad design,
so this patch aims to deduplicate it by introducing a common API
in blenkernel.
In case of Cycles this requires certain hacks, but according to
Brecht it is planned to be rewritten later for more direct access
to internal Blender data anyway.
Differential Revision: https://developer.blender.org/D16117
|
|
|
|
|
|
Rewrite PBVH draw to allocate attributes into individual VBOs.
The old system tried to create a single VBO that could feed
every open viewport. This required uploading every color and
UV attribute to the viewport whether needed or not, often exceeding
the VBO limit.
This new system creates one VBO per attribute. Each attribute layout is
given its own GPU batch which is cached inside the owning PBVH node.
Notes:
* This is a full C++ rewrite. The old code is still there; ripping it out
can happen later.
* PBVH nodes now have a collection of batches, PBVHBatches, that keeps
track of all the batches inside the node.
* Batches are built exclusively from a list of attributes.
* Each attribute has its own VBO.
* Overlays, workbench and EEVEE can all have different attribute
layouts, each of which will get its own batch.
Reviewed by: Clement Foucault
Differential Revision: https://developer.blender.org/D15428
Ref D15428
|
|
|
|
The backend gets used before it is initialized again.
This is just a workaround for now as production schedule needs ir.
|
|
This code slipped through the final review step surely caused by a faulty
merge.
Fixes T101372 Regression: World shader setup crashes Blender in rendered view
Regression introduced by rB697b447c2069bbbbaa9929aab0ea1f66ef8bf4d0
|
|
Use function style casts in C++ headers & source.
|
|
|
|
Some changes missed from f68cfd6bb078482c4a779a6e26a56e2734edb5b8.
|
|
|
|
To use function style cast '(unsigned char)x' can't be replaced by
'unsigned char(x)'.
|
|
|
|
|
|
vertex shader fetch.
These implementations remove dependency on the Geometry pass by instead invoking one vertex shader instance for each expected output vertex, matching what a geometry shader would emit. Each vertex shader instance is then responsible for calculating the same output position based on its vertex_id as the logic would in the geometry shader version.
SSBO Vertex fetch enables full random-access into a vertex buffer by binding it as a read-only SSBO. This enables each instance to read neighbouring vertex data to perform contextual calculations as a geometry shader would, for cases where attribute Multiload is not supported.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D15901
|
|
MTLContext provides functionality for command encoding, binding management and graphics device management. MTLImmediate provides simple draw enablement with dynamically encoded data. These draws utilise temporary scratch buffer memory to provide minimal bandwidth overhead during workload submission.
This patch also contains empty placeholders for MTLBatch and MTLDrawList to enable testing of first pixels on-screen without failure.
The Metal API also requires access to the GHOST_Context to ensure the same pre-initialized Metal GPU device is used by the viewport. Given the explicit nature of Metal, explicit control is also needed over presentation, to ensure correct work scheduling and rendering pipeline state.
Authored by Apple: Michael Parkin-White
Ref T96261
(The diff is based on 043f59cb3b5835ba1a0bbf6f1cbad080b527f7f6)
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D15953
|
|
This allows to reduce the memory footprint of very large framebuffers if
there is no need for any attachment.
|
|
Sun Disc is currently not supported because it'll need special handling - on the one hand, I'm not sure if Eevee would handle a 1e6 coming out of a background shader without issues, and on the other hand it won't actually cast sharp shadows anyways.
I guess we'd want to internally add a sun to the lamps if Sun Disc is enabled, but getting that right is tricky since the user could e.g. swap RGB channels in the node tree and the lamp wouldn't match that.
Anyways, that can be handled later, the sky itself is already a start.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D13522
|
|
Whether faces are hidden and face sets are orthogonal concepts, but
currently sculpt mode stores them together in the face set array.
This means that if anything is hidden, there must be face sets,
and if there are face sets, we have to keep track of what is hidden.
In other words, it adds a bunch of redundant work and state tracking.
On the user level it's nice that face sets and hiding are consistent,
but we don't need to store them together to accomplish that.
This commit uses the `".hide_poly"` attribute from rB2480b55f216c to
read and change hiding in sculpt mode. Face sets don't need to be
negative anymore, and a bunch of "face set <-> hide status" conversion
can be removed. Plus some other benefits:
- We don't need to allocate either array quite as much.
- The hide status can be read from 1/4 the memory as face sets.
- Updates when entering or exiting sculpt mode can be removed.
- More opportunities for early-outs when nothing is hidden.
- Separating concerns makes sculpt code more obvious.
- It will be easier to convert face sets into a generic int attribute.
Differential Revision: https://developer.blender.org/D15950
|
|
This change adds cryptomatte render passes to EEVEE-Next. Due to the upcoming viewport
compositor we also improved cryptomatte so it will be real-time. This also allows viewing
the cryptomatte passes in the viewport directly.
{F13482749}
A surface shader would store any active cryptomatte layer to a texture. Object hash is stored
as R, Asset hash as G and Material hash as B. Hashes are only calculated when the cryptomatte
layer is active to reduce any unneeded work.
During film accumulation the hashes are separated and stored in a texture array that matches
the cryptomatte standard. For the real-time use case sorting is skipped. For final rendering
the samples are sorted and normalized.
NOTE: Eventually we should also do sample normalization in the viewport in order to extract the correct
mask when using the viewport compositor.
Reviewed By: fclem
Maniphest Tasks: T99390
Differential Revision: https://developer.blender.org/D15753
|
|
corresponding data layers and using their values for computations.
Avoiding that should increase performance in many operations that
would otherwise have to read, write, or propagate these values.
It also means decreased memory usage-- not just for sculpt mode
but for any mesh that was in sculpt mode. Previously the mask, face set,
and hide status layers were *always* allocated by sculpt mode.
Here are a few basic tests when masking and face sets are not used:
| Test | Before | After |
| Subsurf Modifier | 148 ms | 126 ms |
| Sculpt Overlay Extraction | 24 ms every redraw | 0 ms |
| Memory usage | 252 MB | 236 MB |
I wouldn't expect any difference when they are used though.
The code changes are mostly just making sculpt features safe for when
the layers aren't stored, and some changes to the conversion to and
from the hide layers. Use of the ".hide_poly" attribute replaces testing
whether face sets are negative in many places.
Differential Revision: https://developer.blender.org/D15937
|
|
Use `verts` instead of `vertices` and `polys` instead of `polygons`
in the API added in 05952aa94d33eeb50. This aligns better with
existing naming where the shorter names are much more common.
|
|
|
|
Added CustomData_get_layer to stub.
|
|
The only difference between `GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR`
and `GPU_SHADER_3D_LINE_DASHED_UNIFORM_COLOR` is that in the vertex
shader the 2D version uses `vec4(pos, 0.0, 1.0)` and the 3D version
uses `vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
|
|
`GPU_SHADER_3D_IMAGE_MODULATE_ALPHA` can be seamlessly replaced by
`GPU_SHADER_3D_IMAGE_COLOR` with no real harm done.
|
|
3D shaders work in both 2D and 3D viewports.
This shader is a good candidate to be exposed in Python.
|
|
The only real difference between `GPU_SHADER_2D_SMOOTH_COLOR` and
`GPU_SHADER_3D_SMOOTH_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_SMOOTH_COLOR' and '3D_SMOOTH_COLOR'
is 'SMOOTH_COLOR', but the old names still work for backward
compatibility.
|
|
The only real difference between `GPU_SHADER_2D_IMAGE` and
`GPU_SHADER_3D_IMAGE` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_IMAGE' and '3D_IMAGE'
is 'IMAGE', but the old names still work for backward
compatibility.
|
|
The only real difference between `GPU_SHADER_2D_FLAT_COLOR` and
`GPU_SHADER_3D_FLAT_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_FLAT_COLOR'' and '3D_FLAT_COLOR'
is 'FLAT_COLOR', but the old names still work for backward
compatibility.
|
|
The only real difference between `GPU_SHADER_2D_UNIFORM_COLOR` and
`GPU_SHADER_3D_UNIFORM_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_UNIFORM_COLOR'' and '3D_UNIFORM_COLOR'
is 'UNIFORM_COLOR', but the old names still work for backward
compatibility.
Differential Revision: https://developer.blender.org/D15836
|
|
For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
|
|
|
