Since the code was added, it used the active indices of the input and
output custom data layers incorrectly. 82b88f130a exposed that
by actually modifying the active indices of the ouput custom data
correctly, but it didn't update a couple other places to take that into
account.
One copy_v4_v4 call was used to initialize both camera_uv_scale &
camera_uv_bias, replace this with 2x copy calls since passing in
smaller buffers to copy functions is typically an error.
Large int64_t values were calculated and assigned int however the
calculation was performed on integer types which would truncate the
result before casting to an in64_t.
This act in multiple phases:
- A shader scan the whole clipmap after tilemap finalize to gather
where valid tiles from lower LODs are available and write the page
location and LOD offset at invalid tiles location.
- At sampling time we add the LOD offset before the pixel page
modulo operation. This offset is equal to the amount of pages of
the **sampling** LOD needed to have the same modulo result as the
**sampled** LOD.
The whole thing being very tricky, I added a lot of unit testing.
This has no use for now but the system is needed to implement:
- Shadows from Volumetrics at lower cost & memory footprint.
- Fixing soft shadows artifacts.
These will be implemented in separate PRs.
Pull Request: https://projects.blender.org/blender/blender/pulls/120031
Also access the evaluated deform mesh with a function rather than
directly from object runtime data. The goal is to make it easier to use
implicit sharing for these meshes and to improve overall const
correctness.
See b99c1abc3a for more information about how using fewer
threads for just copying data can improve performance. In my simple
test file with mesh data re-uploaded every frame, this improved
performance from 23.5 FPS to 25.5 FPS (almost 9%).
After bace4c9a29, the vertex position and vertex normal VBOs
are split. The `overlay_paint_point` shader depends on the normals VBO
because the selection is stored in the `.w` component of the vector.
This PR implements the background blurring for studiolight/lookdev HDRIs.
The visual appearance matches EEVEE-Classic closely.
**Technical details**
- LOD0 is skipped as the regular background color can be used. The
regular background color is blended towards LOD1.
- Volume probe is mixed in to remove baked in artifacts in the higher LODs.
Pull Request: https://projects.blender.org/blender/blender/pulls/119872
When no shadow views are needed Blender could signal a division by
zero. This change fixes this by safe guarding the division by zero
ensuring the there is always a view to update.
This limits the number of tilemaps per LOD that can be fed to avoid the
easy to hit "Too many shadow updates" (#119757).
This allows for a max 64 tilemaps to be updated at once at their lowest
requested LOD (so ~10.6667 point lights if every faces of the punctual
shadow map is needed, but likely more in practice).
Unfortunately this is still quite low and will surely be hit quite soon
with directional shadow added to it. One idea to workaround this would
be to time slice the update of some lights, but this opens a whole can
of worms that I'm not ready to open for now so I created #119890 for
future reference.
Some notes, most lights seems to request around 3 LODs. It might help
to allow requesting at least 2 LODs if we are rendering since volumes
might want lower LOD available for volumes.
I added a very simplistic heuristic that also lowers the max tilemaps
when transforming, animation playback or navigating the 3D view to
improve the responsiveness of the engine. Note that this doesn't
only lowers the resolution to the minimum requested one. So it should
be good enough in most cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/119889
This patch refactors the backdrop offset to be stored as a float instead
of an int and to be stored in the image runtime structure instead of the
image itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/119877
Now that all relevant code is C++, the indirection from the C struct
`GPUVertBuf` to the C++ `blender::gpu::VertBuf` class just adds
complexity and necessitates a wrapper API, making more cleanups like
use of RAII or other C++ types more difficult.
This commit replaces the C wrapper structs with direct use of the
vertex and index buffer base classes. In C++ we can choose which parts
of a class are private, so we don't risk exposing too many
implementation details here.
Pull Request: https://projects.blender.org/blender/blender/pulls/119825
Currently we have a cache for all combinations of "strand/strip" and
the four subdivision levels. Recomputing this data should be very fast
and doesn't require re-uploading data from the CPU. Because they are
scene settings, they will be the same for all render engines too, so we
won't have a case where we're constantly requesting different values.
The extra caches just complicate code, so better to remove them. Now
the final evaluated cache remembers the settings it was created with,
and it's cleared if they are changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/119804
This allows to use unions on the C++ side and safe type
casting on the GPU side.
The type casting functions are statically verified at
compile time in C++.
This PR doesn't change the size of the light struct
but removes the need of packing floats in the `object_mat`.
The matrix will be changed to a `float4x3` in another PR
and will reduce the struct by 16 bytes.
This remove the need for the light parameters macros and
reveals the padding members that could be used for future
features for each type.
After this, all accesses to light type dependent data in
the shaders should be done using:
- `LightLocalData light_local_data_get(LightData light)`
- `LightSpotData light_spot_data_get(LightData light)`
- `LightAreaData light_area_data_get(LightData light)`
- `LightSunData light_sun_data_get(LightData light)`
Note that these functions are simple passthrough for Metal
since it supports `union` (but enforce for error checking
if option is enabled).
The error check on GPU is a bit costly so it is disabled
by default.
Pull Request: https://projects.blender.org/blender/blender/pulls/119713
- Avoid unnecessary redundancy in function and variable names
- Use more consistent variable names in some places
- Avoid duplicate null checks and incorrect "ensure" naming
- Use const in a few places
- Pass more specific arguments besides just the curves
- Remove unnecessary namespace specification
Caused by 1cca960677.
That commit stated that creating the final subdivided attribute didn't
free the "proc" attribute buffer that contains the data from the Curves
control points. However that wasn't the case, given the call to
`GPU_VERTBUF_DISCARD_SAFE` in that function. That caused a crash when
the overlay engine and EEVEE both wanted to access the VBO and it was
discarded the second time. To fix that, only regenerate the
`proc_attributes_buf` when it doesn't already exist.
This matches the "ensure" behavior that already exists for the
`cache.final[subdiv].attributes_buf` buffer, so conceptually it
seems fine.
Pull Request: https://projects.blender.org/blender/blender/pulls/119795
This is implements the system texture coordinates for GPv3.
This pull request adds:
- System for storing and viewing texture coordinates.
- Texture coordinates are convert when covering from legacy to GPv3,
(Tested with object and layer transformation)
- Textures are set to the drawing plane.
Pull Request: https://projects.blender.org/blender/blender/pulls/119303