Before this happened as two steps: first allocating the PBVH with a type,
then calculating the BVH and filling it with data. This just confused things,
so change to allocating the struct when building it. Also move the functions
to the C++ namespace, and fix some cases of requiring the PBVH to be set
when it wasn't yet.
The term `looptri` was used ambiguously for both single & arrays.
The term `tri` was also used, causing `tri->tri`.
Use terms:
- `looptris` for an array or when dealing with multiple items.
- `looptri` is used when dealing with a single item.
- `lt` for a single MLoopTri variables & arguments.
This was already a convention but not followed closely.
The Realtime compositor currently relies on the GPU cache in image IDs.
That cache only supports single layer images, so multi-layer images will
be acquired without a cache, introducing significant IO bottlenecks for
the GPU compositor.
This patch ignores the image GPU cache and stores the images in the
static cache manager of the compositor. Draw data was introduced to the
image ID for proper cache invalidation, like other IDs such as masks.
The downside is that the cache will no longer be shared between EEVEE
and the compositor. But realistically, images are not typically shared
between materials and compositors.
This is just a temporary solution until we have proper GPU storage
support for image buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/115511
This was caused by #113257 which removed the
simple ltc evaluation usage. This in turn
caused a precision issue for the cases where
V == N and surfel lighting was one of them.
Adding a special case fixes the issue.
This adds support for Translucent BSDF.
This also fixes a bug to allow correct
shadowing.
The input normal had to be set back to
non-inverted in the node function to allow
for correct interpretation of the Normal
by Screen Space Reflections.
This add the necessary optimization
and code deduplication to hybrid deferred
and forward pipeline.
Pull Request: https://projects.blender.org/blender/blender/pulls/116070
This was caused by the fix to #65771 which biased the extinction.
The fix uses an exact method by taking the limit of the ill defined
computation and replacing the result by the simplified formula.
This gives better asserts in debug builds through use of Span, more
safety when name convention attributes happen to have different types
or domains, and simpler code in some cases. But the main reasoning is to
avoid relying on the specifics of CustomData more to allow us to replace
it in the future.
See c4446d7924
When the "fully flat" state comes from "sharp_edge" and "sharp_face"
doesn't exist, we need to check for that for every face when extracting
normals. Eventually these loops should be unrolled so we don't have a
function call per face. That would remove the cost of this check.
The build scripts are still referring to gpu tests as being opengl.
Although they can also use Metal or Vulkan. This PR only replaces
the work `opengl` with `gpu` for build options.
Special note is that the windows argument `with_opengl_tests` is
also replaced with `with_gpu_tests` for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/116030
This patch adds an alternative path for devices/OSs
which do not support native texture atomics in Metal.
Support is encapsulated within the backend, ensuring
any allocated texture with the USAGE_ATOMIC flag is
allocated with a backing buffer, upon which atomic
operations happen.
The shader generation is also changed for the atomic
case, which instructs the backend to insert additional
buffer bind-points for the buffer resource. As Metal
also only supports buffer-backed textures for
textureBuffers or 2D textures, TextureArrays and
3D textures are emulated within a 2D texture, with
sample locations being indirected.
All usage of atomic textures MUST now utilise the
correct atomic texture types in the high level shader
and GPUShaderCreateInfo declarations.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/115956
This adds a new hybrid mode where the light and lightprobe
textures are bound to the gbuffer pass and used by
shaders that use ShaderToRGBA.
The counterpart is that these shaders have less texture
slots available but still two more than the Blended
materials.
These materials will correctly write to the AOVs and
render passes.
This is not too invasive in terms of implementation. The
only quirk was that we needed another fragment shader to
simplify the dependencies on the resources. But if we ever
get pre-processor support in our include / require system
this could be cleaned up.
This fixes a case where the source was set but the
internal pointers for binding were not updated.
This also tag for update internally.
Cleanup and remove the redundant tagging.
This also use the planar depth buffer as layer view.
All the relevant code is C++ now, so we don't need to complicate things
with the trip through C anymore. We will still need some wrappers, since
opensubdiv is an optional dependency though. The goal is to make it
simpler to remove the unnecessary/costly abstraction levels between
Blender mesh data and the opensubdiv code.
This de-duplicate some passes in the raytracing
pipeline and make it more ready for adoption
of arbitrary closure evaluation. This last part
means the removal of some per closure type
options.
The put in common the tile classification step
that is now done only once for all 3 closure
type. Also add some speedup to the tile
compaction phase that is now only twice
faster.
The horizon-scan setup was also de-duplicated
and run only if needed, which can save up to
0.5ms is complex scenes.
However, this moves the max-roughness and and
resolution scaling to a common parameter.
This is to be able to support arbitrary closure
evaluation where multiple closure with conflicting
parameters could be evaluated in one tracing pass.
Pull Request: https://projects.blender.org/blender/blender/pulls/116009
"mesh" reads much better than "me" since "me" is a different word.
There's no reason to avoid using two more characters here. Replacing
all of these at once is better than encountering it repeatedly and
doing the same change bit by bit.
Due to changes in the build environment shader_builder wasn't able to
compile on macOs. This patch reverts several recent changes to CMake files.
* dbb2844ed9
* 94817f64b9
* 1b6cd937ff
The idea is that in the near future shader_builder will run on the buildbot as
part of any regular build to ensure that changes to the CMake doesn't break
shader_builder and we only detect it after a few days.
Pull Request: https://projects.blender.org/blender/blender/pulls/115929
