This patch implements the Texture node for the realtime compositor. The
evaluation of the texture is not GPU accelerated, but is cached as a
form of temporary implementation since the Texture node is deprecated
and will be removed in the future. Furthermore, texture node evaluation
is not supported for now.
This patch also introduces the concept of an ID static cache, which
uses the DrawDataList mechanism to invalidate the cache as needed,
consequently, a DrawDataList was added to the Tex ID structure.
An improvement that should be implemented outside of this patch is to
implement support for proxy textures in results to avoid redundant
copies in the execute method of the texture node. This should be
straightforward bit will be implemented in a separate patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/107291
Similar to the cache of loose edges added in 1ea169d90e,
cache the number of loose vertices and which are loose in a bit map.
This can save significant time when drawing large meshes in the
viewport, because recalculations can be avoided when the data doesn't
change, and because many geometry nodes set the loose geometry
caches eagerly when the meshes contain no loose elements.
There are two types of loose vertices:
1. Vertices not used by any edges or faces
`Mesh.loose_verts()`
2. Vertices not used by any faces (may be used by loose edges)
`Mesh.verts_no_face()`
Because both are used by Blender in various places, because the cost
is only a bit per vertex (or constant at best) and for design consistency,
we cache both types of loose elements. The bit maps will only be
allocated when they're actually used, but they are already accessed
in a few important places:
- Attribute domain interpolation
- Subdivision surface modifier
- Viewport drawing
Just skipping viewport drawing calculation after certain geometry
nodes setups can have a large impact. Here is the time taken by
viewport loose geometry extraction before and after the change:
- 4 million vertex grid node: 28 ms to 0 ms
- Large molecular nodes setup (curve to mesh node): 104 ms to 0 ms
- Realize instances with 1 million cubes: 131 ms to 0 ms
Pull Request: https://projects.blender.org/blender/blender/pulls/105567
When EEVEE is rendering multiple samples via
eevee_draw_scene, the command submission and in-flight
memory pressure would grow until all samples completed,
due to lack of intermediate flushing of GPU work and memory.
This patch adds a command flush and memory clear for this case
which occurs with high TAA sample counts during saving, similar
to the process in EEVEE_render_draw.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/107221
Patch prefers usage of Transform Feedback for hair refinement
as opposed to compute, as vertex work can be pipelined with
existing rendering work which is in-flight.
This approach is ~20% faster depending on the scene. Note that
the current implementation only uses TF, as storage buffer support
is disabled. Though once storage buffer support is added, we should
still use the TF path.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/107166
Add texture usage flags for textures which are used as texture views
or require texture views for backing implementation.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/107163
Apply compilation fixes for Metal compatibility.
This includes explicit type casts, packed data types
where vec3 alignment is inconsistent, constructor replacement
with factory function.
The Metal shader generator also needs knowledge of when bound
resources are fundamental data types, so
SHADOWS_TILE_DATA_PACKED must be described as uint in
ShaderCreateInfo.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/107178
Shader source requires explicit conversions and shader address
space qualifers in certain places in order to compile for Metal.
We also require constructors for a number of default struct types.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/106219
Add the ability to retrieve implicit sharing info directly from the
C++ attribute API, which simplifies memory usage and performance
optimizations making use of it. This commit uses the additions to
the API to avoid copies in a few places:
- The "rest_position" attribute in the mesh modifier stack
- Instance on Points node
- Instances to points node
- Mesh to points node
- Points to vertices node
Many files are affected because in order to include the new information
in the API's returned data, I had to switch a bunch of types from
`VArray` to `AttributeReader`. This generally makes sense anyway, since
it allows retrieving the domain, which wasn't possible before in some
cases. I overloaded the `*` deference operator for some syntactic sugar
to avoid the (very ugly) `.varray` that would be necessary otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/107059
Use the attribute API for domain and type interpolation instead of doing
it manually. I observed a 3.8x improvement in curve selection mode and
an 18x improvement in point selection mode.
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
This type will be used to store mesh edges in #106638, but it could
be used for anything else too. This commit adds support for:
- The new type in the Python API
- Editing the type in the edit mode "Attribute Set" operator
- Rendering the type in EEVEE and Cycles for all geometry types
- Geometry nodes attribute interpolation and mixing
- Viewing the type in the spreadsheet and using row filters
The attribute uses the `blender::int2` type in most code, and
the `vec2i` DNA type in C code when necessary. The enum names
are based on `INT32_2D` for consistency with `INT8` and `INT32`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106677
The position attribute has special meaning for point clouds, and
meshes and curves have access methods for the attribute as well.
This saves boilerplate and gives more consistency between types.
This function was not exposed outside of internal GPU module.
Renaming `draw::Texture::depth()` to `is_depth` for consistency
and removing the ambiguity.
Blender 3.5 has a performance regression in the image engine
that made the image engine 3-4x slower then 3.4. The cause of
this was the new way how panning was implemented.
This PR disables the new panning for now as a short term fix.
In the future the panning and improvements we did ensured
better performance when dealing with higher resolution images.
But the regression for regular images weren't acceptable.
This fix might introduce other performance regressions on
lower end systems.
In the future we still want to improve the performance to
get back to Blender 3.0 performance, but that requires more
work and has a different priority.
Pull Request: https://projects.blender.org/blender/blender/pulls/106803
Legacy drivers don't support auto type casting in comparisons.
This PR fixes some comparisons cast.
Thanks to Johannes J. for working/thinking along with the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/106789
The shader was compiled without the right define, disabling the world
volume lighting.
This had nothing to do with the light path node as the lighting
was totally disabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/106787
#### Summary
Occlude edit mode selection behind objects in object mode.
#### Problem
When doing retopology, you want to be able to select your edit mesh,
but only when you can see it.
Being able to select geometry behind reference objects is not
desirable.
#### Solution
Make it so reference objects occlude selection, while the edit mesh is
pushed towards the view using retopology offset.
#### Limitations
Poly Build is not supported, because it doesn't use the depth buffer.
It behaves the same as normal, unoccluded by reference meshes.
#### Notes
Selection occlusion is not used when xray is enabled. This is
intentional.
Pull Request: https://projects.blender.org/blender/blender/pulls/105498
Since e3801a2bd4, we would always respect
hiding for vertex paint and weight paint (drawing code and stroke based
painting), leaving an inconsistency between the different paintmodes.
To rectify this, now also always respect edit mode hiding for projection
painting as well.
Some feedback was gathered in #sculpt-paint-texture-module to ensure
this is desired behavior.
Note: this does not change the (experimental) texture painting in
sculptmode [this already respects hiding via PBVH, albeit in a manner
that bleeds into hidden faces if the brush center is over visible faces]
ref #106354
Pull Request: https://projects.blender.org/blender/blender/pulls/106544
After investigating the crash logs it looked like the macro
unrolling wasn't working on Windows systems with these GPUs.
Macro unrolling was changed in order to cross compile to Metal and
in the future to Vulkan. The macro unrolling in OpenGL can be removed
by using a different naming scema.
This PR removes the macro unrolling by changing the generated GLSL
code:
**Before**
```
layout(std140) uniform _probe_block
{
ProbeBlock probe_block;
};
```
**After**
```
layout(std140) uniform probe_block
{
ProbeBlock _probe_block;
};
```
Some tweaks had to be done to the Eevee-shaders to make sure that
the macro unrolling is done correctly and could be compiled using
legacy opengl drivers.
Fix: #106278Fix: #106555
(and others)
Pull Request: https://projects.blender.org/blender/blender/pulls/106535
Implements #95967.
Currently the `MPoly` struct is 12 bytes, and stores the index of a
face's first corner and the number of corners/verts/edges. Polygons
and corners are always created in order by Blender, meaning each
face's corners will be after the previous face's corners. We can take
advantage of this fact and eliminate the redundancy in mesh face
storage by only storing a single integer corner offset for each face.
The size of the face is then encoded by the offset of the next face.
The size of a single integer is 4 bytes, so this reduces memory
usage by 3 times.
The same method is used for `CurvesGeometry`, so Blender already has
an abstraction to simplify using these offsets called `OffsetIndices`.
This class is used to easily retrieve a range of corner indices for
each face. This also gives the opportunity for sharing some logic with
curves.
Another benefit of the change is that the offsets and sizes stored in
`MPoly` can no longer disagree with each other. Storing faces in the
order of their corners can simplify some code too.
Face/polygon variables now use the `IndexRange` type, which comes with
quite a few utilities that can simplify code.
Some:
- The offset integer array has to be one longer than the face count to
avoid a branch for every face, which means the data is no longer part
of the mesh's `CustomData`.
- We lose the ability to "reference" an original mesh's offset array
until more reusable CoW from #104478 is committed. That will be added
in a separate commit.
- Since they aren't part of `CustomData`, poly offsets often have to be
copied manually.
- To simplify using `OffsetIndices` in many places, some functions and
structs in headers were moved to only compile in C++.
- All meshes created by Blender use the same order for faces and face
corners, but just in case, meshes with mismatched order are fixed by
versioning code.
- `MeshPolygon.totloop` is no longer editable in RNA. This API break is
necessary here unfortunately. It should be worth it in 3.6, since
that's the best way to allow loading meshes from 4.0, which is
important for an LTS version.
Pull Request: https://projects.blender.org/blender/blender/pulls/105938
This patch refactors the texture samples code by mainly splitting the
eGPUSamplerState enum into multiple smaller enums and packing them
inside a GPUSamplerState struct. This was done because many members of
the enum were mutually exclusive, which was worked around during setting
up the samplers in the various backends, and additionally made the API
confusing, like the GPU_texture_wrap_mode function, which had two
mutually exclusive parameters.
The new structure also improved and clarified the backend sampler cache,
reducing the cache size from 514 samplers to just 130 samplers, which
also slightly improved the initialization time. Further, the
GPU_SAMPLER_MAX signal value was naturally incorporated into the
structure using the GPU_SAMPLER_STATE_TYPE_INTERNAL type.
The only expected functional change is in the realtime compositor, which
now supports per-axis repetition control, utilizing new API functions
for that purpose.
This patch is loosely based on an older patch D14366 by Ethan Hall.
Pull Request: https://projects.blender.org/blender/blender/pulls/105642
Use the dot product of the normal of the two polygons connected to the
edge to calculate the edge factor.
This fixes#90641 and #102545 and ensures more predictable results for
boundary and non-manifold edges.
Co-authored-by: Germano Cavalcante <mano-wii>
Pull Request: https://projects.blender.org/blender/blender/pulls/105352
No functional changes.
Edges hidden by Optimal Display are hidden by edge factor Shader.
But there is not much advantage in doing this, as the number of edges
hidden by the Optimal Display is usually much higher than the number of
visible edges.
And the lines extractor does not include invisible edges due to other
factors.
So this change makes:
- Visibility test more consistent with what is actually seen.
- Smaller buffer for IBO sent to GPU
- consistency with GPU Subdivision that already considers Optimal Display
- Allows possible improvement in the "Edge Factor" extraction by making
it unnecessary to check the Optimal Display (except for optimization).
Co-authored-by: Germano Cavalcante <mano-wii>
Pull Request: https://projects.blender.org/blender/blender/pulls/106402
Reduce register spill to global memory in raytrace_resolve
function. Results in a 20% uplift for this particular shader on
Apple Silicon GPUs. Contributing to 3-5% uplift for scenes
which have SSR enabled. This is achieved via reducing
memory pressure using a packed data type for the sampling
kernel.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/106231
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
