This reverts part of commit b7eba20236. Polling
is causing issues in scripts, and the minor usability improvements are not worth
the extra work this may cause at this point in the release cycle.
Fixes T65149
Code for extending sharp edges assumes ADJ pattern and this
example uses TRI_FAN pattern. This change doesn't fix TRI_FAN
mark sharp bug at least won't infinite loop any more.
This patch makes BLI_task_scheduler_create wait for all worker threads to have started before
returning to caller. For very short workloads (BLI_taks_test) there is the chance that the
worker threads have not fully started yet, and the main thread is calling pthread_join at
the same time as pthread_setspecific is being called on the worker threads which causes a
deadlock on pthreads4w.
Differential Revision: https://developer.blender.org/D4936
Reviewed By: mont29, sergey, brecht
The declaration and implementation of BLI_path_name_at_index were
out of sync leading to build warning
C4028: formal parameter 1/3/4 different from declaration
Caused by 5adfc51a0f, sharing keymaps caused changing tools to
unregister gizmos and remove their keymaps.
Workaround for now by not removing the keymap.
This mode was supposed to be the new default since 2 years already.
But apparently, it was tackled only for doversion, but not for new
outliners (see 7f596d39df).
Loading factory preferences from the preferences window and triggering a
redraw then would cause the failing assert.
We shouldn't mess with window-manager data when loading preferences
only.
- Make edges darker in vert & face select mode (making more
contrast to not loose the topology). Downside is less select
edges visibility in vertex mode. But I'm confident that it's not
as painfull as it seems.
- Make select faces less saturated to have more color contrast
between select faces and edges.
- Make unselected faces white to increase contrast with faces and
edges. The brightening is negligeable for bright surfaces and
help readability on darker surfaces. Reminder that if the faces
overlays are too distracting (i.e: uv mapping, or texturing) they
can be toggled off in the overlay panel.
Reviewers: billreynish, campbellbarton, brecht
Reviewed By: billreynish, campbellbarton, brecht
Subscribers: brecht
Differential Revision: https://developer.blender.org/D4941
When viewport samples are set to 1 simple scenes with volumetrics crash.
EEVEE volumetrics needs to init the post processing buffers. With recent
changes the need for post processing buffers are known after the cache
init. But they are constructed before the cache init. This lead to null
pointers.
Reviewed By: fclem
Maniphest Tasks: T64922
Differential Revision: https://developer.blender.org/D4942
Explicitly disable particles in edit for now.
Those were not rendered already, but were attempted to be converted
to Cycles structures (if UVs were not needed for hair nothing was
rendered, but if UVs are needed then crash happened).
Would be nice to bring hair in edit mode back, but this is a bit
more involved change, which will be done later.
It's closer to the default matcap now, but slightly less metallic and dark. The
reason to use studio lights as default is because the roughness and metallic
parameters of the material then have an effect, and because Texture color mode
does not work for matcaps.
- Need to assign current scene in the builder: it is used to
route relations for object's customdata.
- Tweak relation from scene to object for the customdaat: this
didn't work before because the render pipeline scene has no
view layer component.
Fixes T65044: Crash when Rendering (F12)
Evaluation must never go to original objects and query them:
this is a huge violation of the entire idea of separating
state across viewports and render engines.
Allowed this to only happen for active dependency graph, where
we at least know order of dependency graph update and user
input.
While support for gizmo specific keymaps remains, this should only
be used if a gizmo-group is doing something that requires one.
There was also a hidden limitation that meant only the last registered
tweak keymap would ever be used.
For now leave this using the generic keymap since all
tweak modal keymaps were using the same template anyway.
While internally these are separate gizmos,
there is no reason to have a keymaps for each.
Also prefix the gizmo with "3D View"
since there are other kinds of transform gizmos.
This is too generic flag, and it might be used by anything, starting from
changes in transform ending with changes in ID properties.
The check here is to be as specific as possible. If that is not possible
the decision must be documented.
Related on T63111.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4923
Tagging original ID introduces a conflict of interest when a separate
graph is created and is tagging objects to be re-evaluated with its
context.
This is part of the problem in T63111: tags within a temporary dependency
graph affects viewport and vice versa, which makes logic to wrongly
consider that something did change in the scene and that baking is to
be redone.
This effectively reverts db3bfd0, but this time everything seems to
be updating fine in the viewport.
When using texture drawing the material alpha was not set correctly, It
used the `shading.xray_alpha` as this was the default set in the forward
renderer.
This change makes it so a minimal dependency graph which only includes
compositor and sequencer is built for the render pipeline purposes.
Tricky part here is that it's only compositor itself and sequencer who
to use this dependency graph and IDs from it. Render engines are still
to be provided original IDs because:
- They will create dependency graph for the given scene, and currently
it is not possible to create dependency graph from CoW scene.
- IDs from the compositor/sequencer dependency graph are "stripped",
as in, they wouldn't have all view layers, collections or objects
required for proper final render.
This creates annoying mess of mixing evaluated and original scene
access in various parts of the pipeline.
Fixes T63927: Compositing nodes - drivers don't really work
Reviewers: brecht
Maniphest Tasks: T63927
Differential Revision: https://developer.blender.org/D4911
This is used by driers and this is a first step towards support of
scenes used for only compositor or sequencer.
Fixes T61014: Assert adding a driver that uses a single property of a scene ID
