Printing that a library is found every time CMake runs isn't helpful.
Restrict these messages for the first execution so messages are limited
to information developers may need to know such as features being
disabled because of incompatible configurations.
This refactor the lightprobes sample so that we always query
the spherical probe and the volume probe.
Then, given the BSDF type, we reconstruct the incoming radiance
differently depending on the ray probability blending between
the spherical and volume probe depending on ray probability.
Moreover, we implement cubemap normalization using
volume probe spherical harmonic data at spherical probe
position and at the shading point position.
Pull Request: https://projects.blender.org/blender/blender/pulls/113301
`iota` is name that has no meaning, it's not an acronym or initialism.
It's usually very cryptic when I come across it. Replacing it with a
specialized function makes the code more readible.
See cc7da09c1b.
Splitting edges only potentially affects the order of edges and
vertices. Face corner vertex and edge indices are affected, but their
order isn't affected, and faces aren't affected at all. This didn't
cause problems, but correcting it shows users they can rely on
these consistencies after this operation.
This idea is of remapping parameters of lazy-functions is useful
not only for the repeat zone. For example, it could be used for the
for-each zone as well.
Also, moving it to a more general place indicates that there is no
repeat-zone specific stuff in it.
This commit fixes two different issues in
`BLO_update_defaults_startup_blend`:
* No check were done whether a given 'paint mode' tool settings actually
exist or not before trying to 'update' it, leading to hard crash when
some did not.
* Only the first Scene in loaded 'startup' Main would be processed -
nothing prevents a `startup.blend` file to have more than one scene!
This makes it easier to read generated lazy-function graphs, especially when
there are zones or group nodes, because the socket identifiers on those
are some generated internal name.
Instead of using a lambda with a FunctionRef argument, just write the
loops explicitly. This results in a bit more boilerplate code and a bit
more repetition, but the overall design and flow is much simpler. Based
on the results in f10965dcb8, it can improve performance too.
The assert was assuming that the attribute request is properly
initialized and that was not the case: the "special" data layers
like coordinates, normals, masks, and face sets did not initialize
domain in the attribute request.
The domain is now properly initialized. As well as there is an
assert added in other PBVH types for the face sets. It is possible
to add asserts in more places, but it is not directly related to
this CL.
Pull Request: https://projects.blender.org/blender/blender/pulls/113354
The outlines of volume grids in the viewport are noticeable "wobbly"
when they should simply represent grid boxes. This is especially
noticeable on simple regular grids such as the "Volume Cube" geometry
node output.
The reason is that the outlines generated by taking a triangulated mesh
of the grid boxes and then growing it by successively scaling each
triangle. The offset for each vertex grows proportional to its degree
(number of connected edges). The fix is to divide each vertex's offset
by its degree.
The resulting mesh is much more regular and closer to to 1% desired
growth factor.
Old: 
New: 
Pull Request: https://projects.blender.org/blender/blender/pulls/111657
The problem is observed with the "Limit Distance" and "Limit Location"
constraints.
There is an incorrect usage of `td->mtx` and `td->smtx` when converting
`TransData` space from local to global.
In this case, the code is concatenating matrices instead of converting
the location component space.
Also, these matrices only inform the global transformation components
of rotation and scale. They do not include location.
Since the "Limit Distance" and "Limit Location" constraints only require
the location component, it is not necessary to convert the rotation and
scale components.
So, the solution is to convert the location component space instead of
concatenating matrices.
Pull Request: https://projects.blender.org/blender/blender/pulls/112601
The problem is observed with the "Limit Distance" and "Limit Location"
constraints.
There is an incorrect usage of `td->mtx` and `td->smtx` when converting
`TransData` space from local to global.
In this case, the code is concatenating matrices instead of converting
the location component space.
Also, these matrices only inform the global transformation components
of rotation and scale. They do not include location.
Since the "Limit Distance" and "Limit Location" constraints only require
the location component, it is not necessary to convert the rotation and
scale components.
So, the solution is to convert the location component space instead of
concatenating matrices.
Pull Request: https://projects.blender.org/blender/blender/pulls/112601
When using menu-search, only the last part of a search item is highlighted.
When sorting the search results, this should be taken into account and
the highlighted words should be prioritized.
This was already partially implemented in 56e98f8ba6. Now it's also
taken into account with prefix search. For example, `TC` now prefers
`Input > Texture Coordinate` over `Texture > Checker Texture`.
The idea is that accessing recent searches is mostly only useful when actually
searching for something very recent, which means that it would show up at the
top even if the query is empty or extremely short. If the user is typing a longer
query, it likely means that what is at the top is not what is actually desired, so
it's better to not take recent searches into account anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/113338
Two aspects to this change:
- Do not clear face sets when enabling dynamic topology
- Draw face sets in viewport when dynamic topology is enabled
Newly added faces in the dynamic topology will have face
sets properly assigned. It is only edge collapse which can
potentially lead to undesired results w.r.t face set boundaries.
That will be worked on further as follow up development.
Pull Request: https://projects.blender.org/blender/blender/pulls/113348
Optimize Workbench performance so it's on par with the previous
implementation.
Most of these changes are barely noticeable on powerful GPUs,
but can cause a notable performance improvement on old or low-end
hardware.
* Avoid unnecessary texture copies and draw directly to the viewport
textures.
* Optimize-out depth/stencil reads, using stencil testing instead.
* Avoid using `Texture::clear` and use framebuffer clears instead.
* Avoid framebuffer state changes (always use the same attachments).
* Avoid constant variation of acquired `TextureFromPool`s.
Fix#113010
Pull Request: https://projects.blender.org/blender/blender/pulls/113251
Fixed version of #112544 (reverted).
`DRW_drawdata_get` reuses the same `DrawData` for all duplis,
so they all end up using the same `ObjectHandle` and `ObjectKey`,
which breaks motion vectors.
* Don't rely on `DRW_drawdata_get` for storing `ObjectKey`s.
* Simplify `ObjectKey`.
This also solves the issue of objects created "on the fly" always having
the `ID_RECALC_ALL` flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/113252
This PR enables vulkan backend as experimental option.
It will only be available in alpha builds on Linux and Windows.
This option is highly experimental and enabled to get some insight
on supported platforms. Don't expect a fully working Blender
yet. Also don't expect it to have usable performance.
**What is known to not work?**
* OCIO textures are not supported on Intel and AMD GPUs. sRGB/Standard is supported
on those platforms.
* AMD Polaris based GPUs on Linux will generate a crash when drawing the 3d cursor as it
doesn't support the needed vertex format. Comment out `DRW_draw_cursor` in `DRW_draw_region_info`.
* The colors in the node editor and sequencer are of as sRGB viewports aren't detected correctly.
* The image / UV editor isn't working as many texture formats haven't been tested yet. Some
tweaks are also needed to do correct depth testing.
* 3D Viewport is known to be flickering. Sometimes workbench doesn't display anything.
* 3D Viewport wireframe will crash as it uses a framebuffer with gaps between color attachments,
which isn't supported yet. (#113141)
* Rotate the view widget is partially drawn due to incompatible depth clipping.
* GPU Selection isn't working. It is expected to be solved when Overlay-Next will become the
default engine. For now disable GPU depth picking in the preferences.
* Cycles/EEVEE are known to not work with Vulkan yet. Cycles requires Vulkan Pixel Buffer.
Cuda <-> Vulkan interop might require a different approach than OpenGL as Vulkan doesn't allow
importing memory from a Cuda context. EEVEE uses features that aren't available yet in the backend
* Workbench is working, except Workbench shadows.
* EEVEE-Next basics are working. Shadows, lights are known to be not working. Materials/Shading
works in simple scenes. Changes are expected in EEVEE-Next that will break Vulkan compatibility
in the near future.
* Systems with multiple GPUs is not expected to work.
* Wayland support is in development and requires some iterations. You can start Blender, but
the protocols are not aligned yet.
* OpenXR hasn't been modified and is expected to fail.
* The backend is very strict when mis-using the GPU module. In debug builds it may crash
on asserts.
* Older drivers/GPUs might not have all the features that we require. The workarounds
for the missing features still need to be implemented.
**A word about performance**
In the project planning we focus first on stability and platform support. The performance of Vulkan is
around 20% of what we want to achieve. The reason is that each command sent to the
GPU is done one at a time. The implementation even waits until we have feedback that the GPU
is idle again.
Geometry is currently stored in System RAM. The GPU will read and cache the data when
accessing geometry. This slows down when using objects with much geometry.
Some performance features like MDI (Multi-Draw-Indirect) hasn't been implemented and
falls back to Single Draw Indirect.
**Why enable it is an experimental option?**
* Ensures that new features are being tested with Vulkan
* Ensure that building with Vulkan is possible on supported platforms
* Get feedback from developers if Vulkan can run on their system or that
there are special cases that we are not aware of. Main development
environment has been Linux/X11 with occasionally testing using Windows.
* Validate Add-ons that use the `gpu` module.
* Possible to enable GLSL validation on the buildbot. (Needs more work).
* Does it compile on all machines or does it require more changes to cmake
config. We expect it to be able to compile without installing the Vulkan SDK.
The Vulkan SDK is a very powerful tool, but only when actually doing GPU
development. Otherwise it is an overhead which slows down other
activities.
**How can the backend be enabled?**
Currently the Vulkan backend can be enabled per Blender session by starting
using the command line argument `--gpu-backend vulkan`. In the future, when
the backend is more mature, we will add a user preference to switch between
OpenGL and Vulkan.
Pull Request: https://projects.blender.org/blender/blender/pulls/113057
Wayland WSI would crash the system when used. The reason is that the
wayland vulkan WSI doesn't provide windowing support. Vulkan gets full access
to the desktop of the OS and it is the responsibilty of the application to
do the right thing.
For OpenGL Wayland proved basic windowing support using `wayland-egl.h`.
Which essentially is a tiny wrapper that keeps track of the window position and
size.
This PR changes a few things to make the Wayland surface usable:
- Do not load debug extensions when blender isn't started with
`--debug-gpu`.
- Recreate swapchain images when surface size changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/113007
This fixes several issues related to using reflection probes in EEVEE-Next.
- When using a single sample, the reflection probes weren't always updated.
- Composite world background in reflection probes
- Removing reflection probes wasn't working
- Update UBO when world and reflection probes are active in the scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/113347
Custom node trees may not suppor the default NodeSocketFloat socket
type. In case this default type is not supported, search all registered
socket types and pick the first one that is supported by the custom
node tree.
Pull Request: https://projects.blender.org/blender/blender/pulls/113330
Previously the colors were just uploaded as white, the default value.
Even if they aren't interpolated properly, it is still helpful to see
the colors. At worst, the unaffected parts of the mesh will still look
right.
A previous commit made vertex colors interpolate properly, but
face corner colors will still reset to their default value.
As a reminder, only color and byte color attributes are currently
supported for the specialized PBVH drawing.
Pull Request: https://projects.blender.org/blender/blender/pulls/113333
This change makes it so the newly added vertices have properly
interpolated attributes. This includes things like vertex colors.
New vertices are created by splitting edges, so the interpolation
mixes between the edge's two vertices equally.
Co-Authored-By: Hans Goudey <hans@blender.org>
This assert triggers whenever dyntopo is used, even when all the
objects and environment is pristine. The semantic of the assert
is not very clear either.
Avoid having a false-positive trigger which gets in the way of any
development in the area.
Campbell Barton
Clément Foucault
Jacques Lucke
Hans Goudey
Brecht Van Lommel
Bastien Montagne
Alaska
Hans Goudey
Sergey Sharybin
Miguel Pozo
Lukas Tönne
Germano Cavalcante
Jeroen Bakker
Iliya Katueshenock