Previously tagging particle settings for update will iterate over all objects and
all their particle system to see whether something needs an update or not. Now we
put ParticleSettings as an ID to the dependency graph, so tagging it for update
will nicely flush updates to all dependent particle systems.
Current downside of this is that due to limitation of flush routines it will cause
some extra particle system re-evaluation when it technically not needed, and what's
more annoying currently it will discard point caches more often.
However, this is a good and simple demonstration case to improve tagging/flushing
system to accommodate for such cases (similar issues happens with CoW and shading
components). So let's try to find some generic solution to the problem!
For users that means you can tweak shaders in the nodetree and things
are way faster. This is a huge improvement, particularly in
systems that have no shader cache.
From the code perspective it means we are no longer re-compiling the
shader every time a value is tweaked in the UI. We are using uniforms
for those values.
It would be slow to add that many uniforms for all the shaders. So
instead we are using UBO (Uniform Buffer Objects).
This fixes the main issue of T51467. However GWN_shaderinterface_create() still
needs to be improvedi. When opening a .blend all shaders are compiled once, so
optimizing it will bring a measurable impact.
========================================================================
NOTE: This breaks update of Cycles material upon nodetree nodes
tweaking. It will be fixed separately by depsgraph, once tackling T51925
(Animated Eevee values slowdown).
The idea is to make Depsgraph update more granular. The XXX TODO in
rna_nodetree.c will be tackled at that time as well.
========================================================================
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D2739
This commit effectively makes workspace switching useless as far as the
active scene layer goes.
The functions from the scene layer API to get the correct scene layer
from "context" were a placeholder to be addressed by the workspace
commit.
When workspace was merged, however G.main was used as a replacement to pass the
correct argument for the functions. As it turned out (surprise!) this
leads to crash on render preview.
We need to get rid of:
* BKE_scene_layer_context_active_ex_PLACEHOLDER
* BKE_scene_layer_context_active_PLACEHOLDER
And either use SceneLayer explicitly or replace it by:
* BKE_scene_layer_from_workspace_get
This is a first step towards proper depsgraph "ownership", where
we would allow scene to be in multiple states dependent on active
workspace or scene layer.
This commit introduces a basic API to get proper dependency graph
for a given scene layer. It also renames scene->depsgraph to
depsgraph_legacy, so it's easier to search0-n-replace in the future.
This makes sense when we want to avoid float precision error
for near co-linear edges. OTOH, this is an arbitrary decision,
so keep functions separate.
Hashed Alpha transparency offers a noisy output but has the benefit of being correctly ordered. Noise can be attenuated with Multisampling / AntiAliasing.
The issue was caused by combination of following factors:
- Clipboard cleanup function will pass node tree as NULL to node free
function.
This is fine on it's own, we don't have tree in clipboard.
- Node free function will call node storage cleanup only when there is
a non-NULL node tree.
This is somewhat weird, because storage cleanup does not take node
tree as argument.
So the solution here: move node storage cleanup outside of check that
node tree is not NULL.
imapaint's clone and canvas are refcounting Image usages.
And particle's editsettings' object and scene seem to be pure runtime
data (they are reset to NULL in readcode), so resetting them to NULL
here as well.
Really, really, really need to get rid of this usercount handling
everywhere, hopefully incomming ID copying rewrite will help sanitize
that mess. But fix was needed for 2.79 release!
UVs need specific data in the VBO, which is not computed unless the
shaders assigned to the mesh actually use UVs. When adding UVs to the
shader, the VBOs were not being recomputed to include the required data.
This adds a DEG relation between the shader and the mesh, and recomputes
the required data if the shader changed.
Thanks Sergey, for all the DEG stuff...
The issue was caused by combination of following factors:
- Blender Internal viewport render can not distinguish between which parts of
main database changed, so it does full database re-sync when anything is
tagged for an update.
This way, if any NodeTree (including compositor) is changed, Blender Internal
viewport is tagged for full render database update.
- With old dependency graph, scene-level drivers are evaluated on every
iteration of scene_update_tagged, even if nothing is tagged for an update.
This causes compositor drivers be evaluated quite often.
- Driver evaluation checks whether value was changed, and if so it tags
corresponding ID type as updated (this is what was telling viewport to do
render database update).
This check was quite stupid: current property value was checked against the
one coming from driver expression. This means, if driver value is outside
of the hard limit range of the property, the property will always be
considered updated.
The fix is to compare current property value against clamped value from the
driver.
The issue was caused by updates being flushed for all scenes, while actual update
was only called for an active one.
Not sure why do we need to flush updates for all scenes, so now we only flush
scenes which are updated.
Using an arbitrary face as the source of the UV data is mostly fine, as
vertices on seams will generally map to different parts of the texture
that have the same color.
This is regarding fed853ea78
Last fix only accounted for direct changes to the RB settings, but
failed for, say, object transformations. This fix accounts for any
change that might invalidate the RB cache.
Fix 9cd6b03187 introduced a bug that
prevented simulation after a cache invalidation (for instance when
changing a setting after simulating). This fixes that.
