This is because some drivers / GPU actually still do double buffer swapping
but others don't. Adding this do ensure the background color of the first
redraw.
Note that this fix was not tested on the problematic hardware and might not
solve the issue.
This was because the alpha clip thresholding was previously done in the
material nodes codegen. Now it is the responsibility of the engine to
implement it.
This adds a loose uniform that is set by EEVEE itself to control the clip
behavior.
Makes the File Browser filter by .obj and .mtl files by default again. Note
that this commit focuses on fixing this specific bug, further
refactors/tweaks/fixes are planned (see D14863).
Differential Revision: https://developer.blender.org/D14862
Reviewed by: Aras Pranckevicius
When resizing a viewport all engine instance data was cleared.
This wasn't the intended design and lead to performance regressions
in the image engine.
This patch makes sure that the instance data isn't cleared when
the viewport size changes. When using instance data, draw engines
are responsible to update the textures accordingly.
This could also reduce flickering/stalling when resizing the viewport
in eevee-next.
Fixes T95428.
Reviewed By: fclem
Maniphest Tasks: T95428
Differential Revision: https://developer.blender.org/D14874
This patch implements T97613, switching viewport shading when using Color Filter and Mask By Color
ALSO, this patch makes it so viewport shading color switches only when SOLID mode is chosen, to prevent color switching when using other shading modes, without user noticing it.
{F13049889}
Reviewed By: JulienKaspar, joeedh, jbakker
Maniphest Tasks: T97613
Differential Revision: https://developer.blender.org/D14765
Related to T95616, the relationship between Image ID and ImBuf 'cached'
buffers can be fairly confusing when using the RNA API.
Reviewed By: campbellbarton, jbakker
Differential Revision: https://developer.blender.org/D14833
Regression caused by [0] which flushed selection from vertices -> edges,
causing additional edges to be selected. Now selected is flushed based
on the mode, instead of all elements. Note that these function names
could be improved to make it clearer how these flushing functions are
different.
Also skip flushing unless selection is performed.
[0]: 55c82d8380
Regression in [0] which is useful when applying modifiers as a shape-key
but not when applying modifiers which keeps the existing shape-keys.
[0]: 65c5ebf577
The root of the issue is that compositor is using refresh mechanism
to handle recalc.
The safest fix which does not require deep refactor is to check to
whether node space was tagged for refresh from listener (currently
it is listeners which are responsible for tackling compositor tree
recalc).
Differential Revision: https://developer.blender.org/D14856
While possible extra whitespace after all OBJ/MTL keywords was properly
skipped, it was not done for the "f" (face definition) keyword.
While at it, also support indented keywords, i.e. extra whitespace at
the beginning of the line.
There's a tiny bit of performance drop while importing (e.g. importing
blender 3.0 splash scene: 53.38sec -> 54.21sec on my machine). But
correctness is more important.
Reviewed By: Howard Trickey
Differential Revision: https://developer.blender.org/D14854
Support merging UV's that share the same vertex and are very close when
applying modifiers.
This is needed to prevent UV's becoming "detached" which can happen when
applying the subdivision surface modifier.
This regression was caused by [0] which removed selection threshold for
nearby coordinates. While restoring the UV selection threshold could be
done - some selection operations that walk around connected UV fans
wouldn't behave in a deterministic way (such as select shortest path).
There are also other cases where UV's may be compared without a
threshold such as tangent calculation and exporters which have their own
logic to handling UV's.
Also resolves T86896, T89903.
[0]: b88dd3b8e7
Reviewed By: sergey
Ref D14841
Recently `gpu_shader_3D_smooth_color_frag.glsl` had the uniform declarations removed.
For shaders without `ShaderCreateInfo` that require this source this results in the error:
```
ERROR (gpu.shader): hair_refine_shader_transform_feedback_workaround_create FragShader:
|
54 | fragColor = finalColor;
|
| gpu_shader_3D_smooth_color_frag.glsl:5:0: Error: Use of undeclared identifier 'fragColor'
| gpu_shader_3D_smooth_color_frag.glsl:5:0: Error: Use of undeclared identifier 'finalColor'
|
55 | fragColor = blender_srgb_to_framebuffer_space(fragColor);
|
| gpu_shader_3D_smooth_color_frag.glsl:6:0: Error: Use of undeclared identifier 'fragColor'
| gpu_shader_3D_smooth_color_frag.glsl:6:0: Error: Use of undeclared identifier 'fragColor'
```
So port that shader to use `ShaderCreateInfo`.
The coarse polygon count was set to the one of the BMesh instead of
the the one of the mesh used for subdivision, which caused the
compute shaders to output wrong data.
Similar issue/solution as in rB5188c14718c5 from this Monday actually,
there may be more of those still lurking around... Quite surprising they
all get reported now, this behavior has been in Blender since years.
The problem was the layer transformation was already applied in the layer and if we apply in the bake, we are doing double transformation.
Differential Revision: https://developer.blender.org/D14844
The issue was that the `NodeTreeRef` acceleration data structure was
rebuild much more often than necessary. That happened because the
Map Range node accidentally tagged the node tree for change even
though it did not actually change.
Differential Revision: https://developer.blender.org/D14842
Fixes T97794 (which is a reintroduction of an older issue T67266 that
has been fixed in the python importer, but the fix was not in the C++
one). Some software produces OBJ files with mtllib statements like
mtllib "file name in quotes.mtl", and the new importer was not stripping
the quotes away.
While at it, I noticed that MTLParser constructor was taking a StringRef
and treating it as a zero-terminated string, which is not necessarily
the case. Fixed that by explicitly using a StringRefNull type.
Reviewed By: Howard Trickey
Differential Revision: https://developer.blender.org/D14838
Fix regression described in T97799.
Apply layer transform and layer parenting to all visible frames, i.e. active frame + onion skinning frames.
Reviewed By: #grease_pencil, antoniov
Maniphest Tasks: T97799
Differential Revision: https://developer.blender.org/D14829
When the profile only has one control point, its segment count was
determined incorrectly. There needs to be a special case for a single
control point, when there are no segments even if the curve is cyclic.
Recalc selection count at the end of the circle selection.
This was removed from circle selection as it became a performance
bottleneck, helas some operators rely on it.
These kinds of depsgraph evaluations should not be marked as low priority as
this could negatively affect playback performance. Low priority should mainly
be used for background tasks.
Isolate frame writing task so that multithreaded image operations don't cause
the thread to start writing another frame. If that happens we may reach the
MAX_SCHEDULED_FRAMES limit, and cause the render thread and writing threads to
deadlock waiting for each other.
Additionally, don't set task priority to low because this may cause the task
scheduler to be slow in scheduling the write and color management tasks.
Overwriting UV map or vertex color data in Geometry nodes will move the
layers to another CustomData channel, and as such, will make attribute
lookup fail from the UVMap and Vertex Color nodes in EEVEE as the
CustomDataType will also be modified (i.e. no longer `CD_MTFACE` or
`CD_MCOL`).
As discussed in T93179, the solution is to use `CD_PROP_AUTO_FROM_NAME`
so that the render engine is able to find the attributes. This also makes
EEVEE emulate Cycles behaviour in this regard. `attr_load_uv` and
`attr_load_color` are also removed in favor of the generic attribute
API in the various GLSL shaders.
Although `CD_PROP_AUTO_FROM_NAME` is now used even for UV maps, the
active UV map is still used in case the attribute name is empty, to
preserve the old behavior.
Differential Revision: https://developer.blender.org/D13730
The crash is caused as the data for the UV editor is requested before
the data for the mesh as a separate draw update. Since building the UV
stretch angle buffer requires the position buffer, the latter is not
created yet in this case.
To fix this, create a local position buffer from the subdivision data. An
alternate fix was considered to remove the dependency on the position
buffer by interpolating on the GPU the coarse stretch angle buffer but
this did work. Maybe this will be revisited.
- Fix T97793: when a UV coordinate after vt is missing, use zero. While
at it, also use zeroes for positions & normals, since "maximum
possible float" is very likely to cause issues in imported meshes.
- Fix T97795: use 1.0 default if -bm value is missing, instead of zero.
Reviewed By: Howard Trickey
Differential Revision: https://developer.blender.org/D14826
Fix several correctness issues where the new OBJ/MTL importer was not
producing the same results as the old one, mostly because the code for
some reason had slightly different logic. Fixes T97757:
- When .obj file tries to use a material that does not exist, the code
was continuing to use the previous material, instead of creating new
default one, as the previous importer did.
- Previous importer was always searching/parsing "foo.mtl" for a
"foo.obj" file, even if the file itself does not contain
"mtllib foo.mtl" statement. One file from T97757 repros happens to
depend on that, so resurrect that behavior.
- When IOR (Ni) or Alpha (d) are not specified in .mtl file, do not
wrongly set -1 values to the blender material.
- When base (Kd) or emissive (Ke) colors are not specified in the .mtl
file, do not set them on the blender material.
- Roughness and metallic values used by viewport shading were not set
onto blender material.
- The logic for when metallic was set to zero was incorrect; it should
be set to zero when "not using reflection", not when "mtl file does
not contain metallic".
- Do not produce a warning when illum value is not spelled out in .mtl
file, treat as default (1).
- Parse illum as a float just like python importer does, as to not
reintroduce part of T60135.
Reviewed By: Howard Trickey
Differential Revision: https://developer.blender.org/D14822
Regression from rB1a7757b0bc69/rBa0acb9bd0cc0. Special handling
(averaging) of weights on merged center vertices also requires to be
'reversed' when new correct merge order is used, compared to previous
behavior.
Regression caused by [0] that caused the error message to be
created based on a normalized exception (which hid line numbers).
PyC_ExceptionBuffer{_Simple} & BPy_errors_to_report
no longer clears the exception.
This could have been resolved by changing python_script_error_jump
however that would involve changes to reference counting that are more
risky (noted in code-comment).
[0]: 2d2baeaf04
Leak was caused because output image buffer was initialized twice. Once
in speed effect strip and then by cross effect strip used for
interpolation feature.
This was reported explicitly for originally being in face selectmode,
but could also crash when in vertex selectmode (when doing multiple
cuts).
The reason here is that `MESH_OT_loopcut` switches to edge select mode
(needed for `TRANSFORM_OT_edge_slide`, done in `ringsel_finish`), but was
only doing this on the active object's editmesh, all other participating
meshes would keep their selectmode which would now be out of sync with
both the active object's editmesh and scene settings for these.
This causes problems later in 'Select Linked'. Here, a mixture of
objects are used. First the viewcontext is set up with the active
object, then all participating objects are iterated (changing the
viewcontext to another object), then `unified_findnearest` would use that
changed viewcontext which would now contain the last object iterated. To
repeat: this could now have a different selectmode than the active
object which is later **again** used to get the nearest `BMElem` from in
`EDBM_elem_from_selectmode`. So in the failing case, we could get an
edge (but no face because of edge selectmode) from `unified_findnearest`,
`EDBM_elem_from_selectmode` would return NULL though (edge provided, but
in face selectmode), leading to the crash.
To solve this I assume it is best to change selectmode on all
participating meshes in multi-object editmode loopcut if necessary so
these are always in sync for following operations.
Alternatively, `Select Linked` (and probably lots more operators) would
have to be tweaked to pay closer attention which object is really used
to get selectmode from.
Note the selectmode is actually set back from edge selectmode in certain
cases (see `USE_LOOPSLIDE_HACK`), this patch changes that as well to act
on all participating meshes.
Maniphest Tasks: T95752
Differential Revision: https://developer.blender.org/D14791
This commit implements copying of materials and material indices from
all of the boolean node's input meshes. The materials are added to the
final mesh in the order that they appear when looking through the
materials of the input meshes in the same order of the multi-socket
input node.
All material remapping is done with mesh-level materials. Object-level
materials are not considered, since the meshes don't come from objects.
Merging all materials rather than just the materials on the first mesh
requires a change to the boolean-mesh conversion. This subtly changes
the behavior for object linked materials, but in a good way I think;
now the material remap arrays are respected no matter the number
of materials on the first mesh input.
Differential Revision: https://developer.blender.org/D14788
