Not only depend on the camera position but also on the other camera parameters.
This is important because otherwise Geometry Nodes won't be updated when e.g.
the focal length changes which is important when implementing e.g. camera
culling.
This already works when depending on a specific camera directly, but not when
depending on the active camera.
Pull Request: https://projects.blender.org/blender/blender/pulls/140046
To make this work, I had to add a new rna callback to get the default value for
an enum property at run-time. The same exists for other property types like
float and bool already.
Pull Request: https://projects.blender.org/blender/blender/pulls/140050
This fix make it so that the brush cursor is always the same size as
the drawn strokes.
The code logic is modified from `pixel_radius_to_world_space_radius`
in `grease_pencil_utils.cc`
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/139964
This allows to reduce the waiting time caused by
shader compilation on some GPU-driver combo.
A new settings in the User Preferences make it
possible to override the default amount of worker
threads and optionally use subprocesses.
We still use only one worker thread in cases where
there is no benefit with adding more workers
(like AMD pro driver and Intel windows).
It doesn't scale as much as subprocesses for material
shader compilation but that is for other reasons
explained in #139818.
Add some heuristic to avoid too much memory usage
and / or too many stalls.
Also add some heuristic to the default number of subprocess for
the platform that shows scalling.
Historically, multithreaded compilation was prevented by the
need of context per thread inside `DRWShader` module.
Also there was no good scaling at that time. But
nowadays numbers shows different results with
good scaling with reasonable amount of threads on many
platforms.
Even if we are going for vulkan in the next release
most of the legacy hardware will still use OpenGL for
a few other releases. So it is relevant to make this
easy improvement.
See pull request for measurements.
Pull Request: https://projects.blender.org/blender/blender/pulls/139821
Baking and storing simulation state within loops or closures is not supported.
Previously, attempting to use the bake node or simulation zone in such a zone
would just silently fail. Now there is an error on the node and the bake
settings are grayed out.
Pull Request: https://projects.blender.org/blender/blender/pulls/140041
Also unifies the min/default/max width of all group nodes. The minimum width
has been increased from 40 to 60 for Geometry Nodes because there was is
an assert when the node was that thin already. The other group nodes already
used 60 as min width.
From what I know, we don't really have a good way to detect whether a material
index is non-sensical in the right places. That's because the same material
index on a mesh may not make sense on one object but can still make sense on
another. This is the issue we fixed in the first place when the regression was
introduced.
What we can do though is to check which exact material indices a mesh is
actually using (not just the maximum). This allows us to skip a lot of work for
unused material indices. This doesn't help when a mesh has thousands of unique
non-sensical material indices, but it should be an improvement in the majority
of cases.
This patch adds a cache of used material indices to `Mesh`. The drawing code
requests that cache if the maximum material index is above some threshold (16
currently). We don't want to compute it all the time, because it requires
iterating over the mesh (at least once, then it is cached). So it's only worth
the extra cost of the there is at least one large material index. The threshold
also ensure that the large majority of scenes is not affected by this patch
performance wise.
Pull Request: https://projects.blender.org/blender/blender/pulls/139781
After 9e4c26574a, `relations_invalidate_cache()` for sound strips
returns without doing anything, but VSE code relied on this function to
tag scene to update `ID_RECALC_SEQUENCER_STRIPS` which is mostly audio
related. Since the name of this enum value is not very descriptive,
clarifying comment was added.
Pull Request: https://projects.blender.org/blender/blender/pulls/139991
Restore the BM_vert_is_edge_pair(v) check that was present prior to
!134017. In that PR, the edge pair check was moved up, to a previous
iteration pass, that checked the angle thresholds. However, even though
pairs were checked before, the process of performing edge merges might
change a neighboring vert such that it is no longer an edge pair.
Therefore it is necessary to check a second time.
Resolves regression in [0].
[0]: e418f7b1f1
A bug that was introduced in !131645 where the number of verts eligible
for dissolve was reduced, to prevent dissolving unrelated verts.
That PR changed the code to only do the dissolve check on verts at the
ends of selected edges, which solved bug #109765. However, this didn't
properly account for dissolving only one edge in a chain in a face pair.
This could result in cases where one of the vertices should be checked
but wasn't - if it wasn't selected.
Now when an edge is dissolved, each of its verts is checked,
and if it's in a chain, the VERT_MARK tag is moved down the
chain until it finds its natural endpoint.
Ref !139959.
When constant falloff is used, `BKE_brush_calc_curve_factors` doesn't do
any extra filtering of the given distances. The Plane brush previously
didn't filter the distances, leading to incorrect deformations when the
constant falloff was used.
To fix this, this commit makes a number of changes:
* `BKE_brush_calc_curve_factors` no longer sets the factor for an
element to 0 if it is outside of the provided distance. This is
replaced with an assert.
* The Plane brush and Cloth brush have an explicit
`filter_distances_with_radius` added.
Pull Request: https://projects.blender.org/blender/blender/pulls/139851
This has limited use cases since it doesn't
profile the heavy part of the vulkan backend.
Almost 1:1 port of the metal implementation from #139551.
Doesn't cover rendergraph submission nor GPU timings.
Pull Request: https://projects.blender.org/blender/blender/pulls/139899
This commit enables Blender 4.5 to use (to some extent) blendfiles from
Blender 5.0 and later using 'long' ID names (i.e. ID names over 63 bytes).
On a more general perspective, it also introduces safer handling of
potentially corrupted ID names in a blendfile.
This is achieved by carefully checking for non-null terminated ID names
early on in readfile process, and then:
* Truncating and ensuring uniqueness of ID names.
* Doing similar process for action slot and slot users identifiers.
* In linking (and appending) context, such IDs are totally ignored. They are
not listed, and are considered as missing if some other (valid) linked ID
attempt to indirectly link them).
* Informing users through usual reporting ways.
Technically, this mainly changes two areas of the readfile code related to IDs
themselves:
* The utils `blo_bhead_id_name` that returns the ID name of an ID BHead,
without actually reading that ID, now check for a valid null-terminated
string of `MAX_ID_NAME` max size, and returns a `nullptr` on error.
_This essentially prevents listing and linking such IDs, in any way._
* The actual ID reading code (`read_id_struct`) does the same check, and
truncate the ID name to its maximum allowed length.
* Both of above checks also set a new FileData flag
(`FD_FLAGS_HAS_LONG_ID_NAME`), which is used to ensure that ID names (and
related actions slots identifiers) remain unique, and report to info to the
user.
Implements #137608.
Branched out from !137196.
Co-authored-by: michal.krupa <michal.krupa@cdprojektred.com>
Co-authored-by: Campbell Barton <ideasman42@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/139336
Color picking reads 3 values from a texture that is backed by 4
channels. The conversion would also convert the 4th channel.
This is a short term fix. We should reconsider the usage of reading a
different number of elements than backed by the texture. But that
requires work in the color picking and python GPU module.
Pull Request: https://projects.blender.org/blender/blender/pulls/139929
When drawing image scope the vulkan backend raised some asserts. After
checking them the issue was in the calling code, that could lead to
undefined behavior on other platforms as well.
It isn't allowed to have an immediate mode shader bound, when performing
batch drawing. There was also a point batch that didn't use any point
shader resulting in undefined behavior as well.
For 5.0 we should add this as a GPU module check.
Pull Request: https://projects.blender.org/blender/blender/pulls/139926
With this fix strokes with locked materials are not affected any more
by the Grease Pencil weight paint tools. The vertex weights in
material-locked strokes are read-only: they are not changed, but the
weights do count for Average, Blur and Smear.
Pull Request: https://projects.blender.org/blender/blender/pulls/138900
This mainly adds DNA level IDProp storage for system properties, their
handling in data management code, and the forward-versioning code
copying back content from system properties into 'all-in-one' single
IDProperties storage, for data types that will support both in Blender
5.0.
There is no user-facing changes expected here.
Part of #123232.
Pull Request: https://projects.blender.org/blender/blender/pulls/139257
Descriptor sets/pools are known to be troublesome as it doesn't match
how GPUs work, or how application want to work, adding more complexity
than needed. This results is quite an overhead allocating and
deallocating descriptor sets.
This PR will use descriptor buffers when they are available. Most platforms
support descriptor buffers. When not available descriptor pools/sets
will be used.
Although this is a feature I would like to land it in 4.5 due to the API changes.
This makes it easier to fix issues when 4.5 is released.
The feature can easily be disabled by setting the feature to false if it has
to many problems.
Pull Request: https://projects.blender.org/blender/blender/pulls/138266
When proportional editing around individual origins is used, we would
end up with uninitialized TransData center for points in curves which
have nothing selected.
This is more or less harmless since the center is not even used in that
case (instead the center of the closest point found is used, see logic
in #set_prop_dist /#prop_dist_loc_get).
Still nicer to be clear about this, added some code comments which
hopefully make the situation clearer.
Ref. 1d0c11987f
Ref. #139101
Pull Request: https://projects.blender.org/blender/blender/pulls/139849
An unknown --gpu-backend argument would attempt to pass that argument
separately which then attempted to treat is as a blend file,
typically failing to start if the file wasn't found.
New windows with new areas have all their dimensions sized before they
are fully initialized (prior to ED_area_init). No need to check their
minimum size in this state.
Pull Request: https://projects.blender.org/blender/blender/pulls/139908
Main issue was that the handling of catalogs for on-disk libraries
relies on an in memory version of a asset catalog definition file. This
wasn't present for the runtime current file library storage. We can
actually construct this quite easily when converting it from a runtime
to a on-disk library.
Pull Request: https://projects.blender.org/blender/blender/pulls/139881
When taking screenshots above a certain size with the
recently introduced screenshot feature, it rendered incorrectly
when the backend was set to OpenGL. (Vulkan was fine)
The issue was that the image was not downscaled to 256
which seems to be the max supported size
for preview renders (`PREVIEW_RENDER_LARGE_HEIGHT`).
Scaling down the image resolves that issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/139879
When buffers/images are allocated that use larger limits than supported
by the GPU blender would crash. This PR adds some safety mechanism to
allow Blender to recover from allocation errors.
This has been tested on NVIDIA drivers.
Pull Request: https://projects.blender.org/blender/blender/pulls/139876
- Navigation modes has been redefined a bit and introduced in a form of
an enum so that new ones can me implemented in the future.
Additionally switching between modes shouldn't require any additional
configurations like inverting all the axes.
Currently there are only 2 modes implemented,
but 2 more are planned and will be proposed in follow-up PRs.
Implemented modes are:
- Object: works like "Orbit" option.
but has all axes implicitly inverted
- Fly: works the same as "Free".
- "Turntable" option has been turned into "Lock Horizon".
This single option works for both normal navigation and Fly/Walk
modes now.
- Pan and Rotation axes inversion has been removed from default
configuration.
- UI has been simplified following the design from #136880.
- Zoom Invert has been removed since it looks like a duplication of
`NDOF_PANZ_INVERT`.
Ref !139343
This allow for more granular requests reducing the engine
startup time in case sub-process compilation is not enabled
(when it is enabled, gains are not substantial).
This also makes engine startup less blocking.
The batches are only requested if needed.
Some of the batches can only be requested after object sync.
Given we don't have a priority system for the shader compilation
queue, the engine shader ends up compiling after the scene
ones.
The remaining blocking is the texture loading and geometry loading.
The world compilation is still blocking in this patch to avoid making it
more complex. But this can be another optimization we can do later on.
See PR for performance numbers.
Pull Request: https://projects.blender.org/blender/blender/pulls/139454
This PR will remove the filtering when gathering texels for HiZ. The
algorithm that we follow doesn't use it, but had issues when
implementing using textureGather where he mentioned that he needed to
enable filtering.
```
I was experimenting with using texture gather lookups to reduce
the number of texture fetches from 4-to-7 fetches per fragment
down to 1-to-3 fetches per fragment (see the extension
ARB_texture_gather) it seems that texture gather works only if
the image is linearly sampled and to avoid the additional burden
involved by switching filtering state during rendering I stuck
to simple texture lookups as using texture gather lookups did not
show any visible effect on the construction time of the Hi-Z map.
```
https://www.rastergrid.com/blog/2010/10/hierarchical-z-map-based-occlusion-culling/
After testing we got identical results when turning off filtering.
Turning off filtering allows supporting devices that don't support
linear filtering on depth stencil texture (WoA) using the Vulkan
backend.
Pull Request: https://projects.blender.org/blender/blender/pulls/139868
For linked grease pencil data, layer operators are accessible right
now. Grey out them in UI by adjusting poll functions. Also disabled
the individual layer row of tree-view.`
See images in PR description
Pull Request: https://projects.blender.org/blender/blender/pulls/137946
The versioning code for the new `Scale` input (a92b68939a)
always added new versioning nodes connected to the `Scale` input to ensure
that the node behaves as before.
But these versioning nodes are only necessary when a profile curve is connected.
Otherwise, they don't have any effect at all, since the node just outputs
a wire mesh in this case.
This skips adding the versioning nodes in case the profile socket
is unused. The default scale value will be 1.
Pull Request: https://projects.blender.org/blender/blender/pulls/138968
The argument `-a` is used twice (render animation & animation playback).
Parsing logic works since their handled at different passes however
printing help text could return either since passes aren't used
for matching.
Workaround the problem using a deterministic lookup when printing
help text which that skips arguments that have already been handled.
When dissolving an edge merges faces, use an angle threshold before
dissolving vertices from the face which have become chains as reult
of the merge (connected to 2 edges).
Also fix edge-flag handling when dissolving multiple edges
from a chain into a single edge, previously flags from the
resulting edge was effectively random.
Now flags from all edges are merged.
Resolves#100184.
Ref !134017
