Previously the VKShaderInterface was constructed twice. This was
due to a limitation of the Shader api. Specialization constants
introduced an Shader::init function which allows to pre-initialize
the shader interface before a shader is finalized.
Pull Request: https://projects.blender.org/blender/blender/pulls/122049
I can't reproduce this on release or debug builds. But from the strack
traces provided in a couple reports, it looks like the runtime pointer
is null. This makes sense because BKE_previewimg_blend_read is not
called here which is what allocates the runtime struct on file read.
To maintain a "valid" PreviewImage in more code and avoid the
complexity of making the runtime pointer optional, just allocate
it in BLO_blendhandle_get_preview_for_id.
There were multiple places in the GPv3 code that assumed that the
frame key is equivalent to the start frame of the frame with that key.
But this is not the case. The `FramesMapKeyT` is either the start frame
*or* the end frame (for frames with fixed duration).
This adds a new function `start_frame_at` that returns the start frame
number of the frame at `frame_number` or -1 if no such frame exists.
One place needed the index into sorted keys (for onion skinning) so
this was replaced with a new function `sorted_keys_index_at`.
With these changes, `Layer::frame_key_at` is now a private method.
Pull Request: https://projects.blender.org/blender/blender/pulls/122045
Because the shapekey editor is trying to have a more fancy UI with
sliders on each "Relative" shapekey value, all other animatible
properties were not drawn.
This patch now makes it possible to easily work with actions that have
non "Relative" keys. Before this was almost impossible as the user could
not see what action they had selected or which non relative keys were in
them as the UI would think that the action was empty.
While working on this I also noticed that there are some other
properties in relative mode that is not in the action editor either
(Range Min/Max). I added a TODO about that in the code as one would
probably want to group those together in a nice way with either
respective shapekey.
Pull Request: https://projects.blender.org/blender/blender/pulls/121829
Other code also uses the suffix `T` to indicate that this is a type.
Note that `FramesMapKeyT` is just an `int` but with a very specific
meaning. Hence the alias to avoid confusions.
Filling an area is typically done with a "Fill"-only material. It should
be possible to fill the same area again (paint "over" the fill stroke)
and get the exact same shape. The draw code for the fill tool, however,
was rendering all strokes with a "Stroke" material, creating a thick
boundary that shrinks the fill area with every iteration.
Image render code for the fill tool now ignores any strokes that don't
have a stroke material.
Pull Request: https://projects.blender.org/blender/blender/pulls/122034
`Weight` & `Threshold` sliders should **not** show in case of `Type` :
`Custom Normal` and **should** show for both `Type` : `Face Area` &
`Type` : `Corner Angle`
In code, it looks like we are gathering `loop_weight` with `val`.
- this is always 1.0 for `EDBM_CLNOR_AVERAGE_LOOP`
- this is taken from `BM_face_calc_area` for
`EDBM_CLNOR_AVERAGE_FACE_AREA`
- this is taken from `BM_loop_calc_face_angle` for
`EDBM_CLNOR_AVERAGE_ANGLE`
Code then compares not equal those values with given threshold, but for
`EDBM_CLNOR_AVERAGE_LOOP` this will never trigger (since all values are
the same), thus `count` is always zero which makes the effective
`n_weight` always 1. So all loop split normals are averaged for a vertex
with the same weight (seems to make sense to me -- at is just plain
average)
Long story short: the condition to show `Weight` & `Threshold` sliders
is just flipped (these only apply for the methods that take neighbor
faces into account).
Pull Request: https://projects.blender.org/blender/blender/pulls/121864
The Sun Beams node produces NaNs when the ray length option is zero.
This is due to zero division in the code, which we avoid by skipping
computation altogether when the ray length is zero.
- Directly check for vertices with two edge neighbors instead of looping
- Use arrays of C++ types as return values
- Use lambda to avoid repetition for each edge vertex
- Use `edge_other_vert` utility
Recently we haven't been adding separate storage structs just to
store a single enum, partially with the hope these will be changed
to sockets in the future, but also because it isn't worth the boilerplate.
Missed in the review of #121333.
This pull request adds an "Active Element" node that exposes the active
vertex, edge, or face index to the geometry node tool context. The
presence of an active element is available as a boolean.
This node enables the creation of "active-to-selected" style operators.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121333
`mesh_final` isn't really the final mesh but the "current" mesh. Adding the
extra word here isn't helpful. This also helps to reduce the size of the diff
in #119968 where the mesh variables have much smaller scopes.
Some nodes like the simulation input have sockets that depend on
other nodes in the tree, via dynamic declarations. The first fix here
is remapping those inter-node references before adding links and
updating declarations. The second is storing link references with
socket identifiers instead of socket pointers. This is necessary
because the new sockets aren't added to the socket map when the
node is copied. Avoiding pointer storage is also less fragile in general.
Pull Request: https://projects.blender.org/blender/blender/pulls/122013
After recent commits, the .cc file is only used for actual object data
evaluation in the depsgraph, and the header is only used for the old
DerivedMesh data structure that's still being phased out.
Mesh object evaluation is unrelated to DerivedMesh nowadays. Change the
name to something similar to the other evaluation functions called in
BKE_object_handle_data_update.
This simplifies zero-initializing `PointerRNA` in structs even when
just `RNA_types.hh` is included. Previously, one had to use
`RNA_access.h` to access it. It's also `constexpr` now which can
have small performance benefits in theory.
This adds PDF computation for eval functions as
well as using PDF for spatial denoising.
This seems to not do have any impact but at least
it seems more sounds than bsdf / pdf. Also
computing pdf is cheaper than whole bsdf.
Pull Request: https://projects.blender.org/blender/blender/pulls/121858
Grouping the legacy DerivedMesh code in the same place helps keep
the actively maintained code clearer and clarifies what we are hoping
to remove in the future.
Move to a file with the more consistent "mesh_legacy" naming, out of the
modifier evaluation code which has nothing to do with this anymore. That
file can be renamed in a separate step.
Using a non-virtual derived struct for polymorphism is error prone,
especially combined with the requirements of DNA. Instead, use a
separately allocated runtime struct as done for many other DNA structs.
In a followup commit, the remaining runtime members of `PreviewImage`
could be moved to the new runtime struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/121509
The Viewport Compositor only operates on part of the render when doing
viewport rendering when in camera view. That's because the code wrongly
assumed camera offset even when doing viewport renders, which do not
exist in that case.
