Fix T39286: Display percentage ignored in Cycles viewport.
The threaded depsgraph update changes included a cleanup of the global
is_rendering flag, which was replaced by a general EvalContext being
passed to dupli functions.
Problem is that the global flag was true for viewport duplis before
(ugly hack), which was used as a check for generating dupli orco/UV from
mesh data layers. The new flag is stricter and only true for actual
renders, which disables these attributes and breaks the Cycles
Texture Coordinates and UVMap nodes.
The solution is to extend the simple for_render boolean to an enum:
* VIEWPORT: OpenGL viewport drawing (dupli tex coords omitted)
* PREVIEW: Viewport preview render (simplified modifiers)
* RENDER: Full render with all details and attributes
There are still some areas that need to be examined, in particular
modifiers seem to totally ignore the EvaluationContext!
Instead they generally execute without render params from the depsgraph
(BKE_object_handle_update_ex) and are built with render settings
explicitly.
Differential Revision: https://developer.blender.org/D613
Skip doing particle update in object_handle_update if object is in
edit mode.
Object will be re-evaluated on exit from edit mode anyway, so it's
_expected_ to be a safe change.
The helper function `make_freestyle_edge_mark_hash()` was referring to the
original mesh to determine Freestyle edge marks for individual derived mesh edges.
This is no longer necessary now that derived meshes deliver CD_FREESTYLE_EDGE
and CD_FREESTYLE_FACE layers of their own. The reference of the original mesh
was also inappropriate since the edges coming from one of the operands of a boolean
modifier don't have proper CD_ORIGINDEX values but ORIGINDEX_NONE's.
Many thanks to Sergey Sharybin for patch contributions and discussions.
Issue is a regression since threaded objetc update and caused
by the fact that some objects might share the same proxy object.
It's all fine but object_handle_update() will call update for
a proxy object which screws up threaded update.
The thing is, proxy object is marked as depending on a scene
object and such a call makes it so the children objetc is
being updated.
This is really bad and depsgraph is to take all responsibility
on updating the proxy objects.
So for now used a simple solution (which is safe to backport
to 'a') which is skipping proxy update if the scene update is
threaded and based on the DAG traversal.
There are some still areas which calls object update directly
and for that cases proxy object is still being updated from
object_handle_update().
This is a failure of viewport direct displist creation
caused by existing curve_cache pointer which empty content.
Made it so if the curve isn't evaluated it's curve_cache is NULL.
This is just-another-regression to be ported to the release.
Fluid particles use the particle system's bvhtree structure, which is a
runtime BVH tree. This was not reset properly on copying objects/psys,
which lead to concurrent access in threaded depsgraph updates and memory
corruption.
in threaded depgraph updates and effector list construction.
Gathering effectors during depgraph updates will call the
psys_check_enabled function. This in turn contained a DNA alloc call
for the psys->frand RNG arrays, which is really bad because data must be
immutable during these effector constructions.
To avoid such allocs the frand array is now global for all particle
systems. To avoid correlation of pseudo-random numbers the psys->seed
value is complemented with random offset and multiplier for the actual
float array. This is not ideal, but work sufficiently well (given that
random numbers were already really limited and show repetition quite
easily for particle counts > PSYS_FRAND_COUNT).
It was intended to work actually using particle cache's stack index
but this index might have been calculated incorrect in special case:
* With default cube scene, add particle system to the cube
* Add disk cache to the particle system
* Save file and reload it
* Add another particle system and enable disk cache
This would lead to two point caches with the same stack index of zero.
This happened because point cache indices list wasn't stored in the
.blend file so once you've reload your file blender doesn't know anything
about number or point caches used.
And what was even more confusing is that point cache indices list was
trying to be load from the file, but this failed because it wasn't in the
file.
This commit solves the root of the issue which is ability of producing
.blend file with two point caches using the same disk cache. This is
done by making it sure that point cache indices list is stored in the
.blend file. And also made it so disabling disk cache will tag it to
recalculate stack index.
Old broken files wouldn't magically start working, but fixing them is
rather simple manually by toggling Disk Cache option.
Reviewers: lukastoenne, brecht
CC: sergof
Differential Revision: https://developer.blender.org/D286
Issue partially caused by own errors (glicth in new BKE_boundbox_ray_hit_check() code causing segfault in volume snapping,
and we have to treat ortho and persp differently in case of face snapping, because in persp our ray_start might very well
already be *inside* the boundbox of the checked object), and partly due to the fact that ED_view3d_win_to_vector()
was returning wrong vector (negated one) for ortho views (see previous commit).
Issue is caused by start point of ray used to detect faces under the mouse is set rather far away in ortho 3dviews.
The loss of precision on the ray location induced by this can lead to face snapping failures.
Solution is to do the raycasting with a temp start point, much closer to the object we check, and add back
to the found distance the diff to the real start point once detection is done (as we need all hit distances
from all tested objects to be relative to a common point!).
Note this commit only addresses the "face snapping on mesh" case, other kind of snapping do not seem to suffer
from this issue.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D268
Previously this only worked for some datablocks relevant to rendering, now it
can be used to detect if any type of datablock was added or removed (but not
yet to detect if it was modified, we need many more depsgraph tags for that).
Most of the changes are some function parameter changes, the important parts
are the DAG_id_type_tag calls.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D195
This adds an ImageUser to such empties with all the typical settings.
Reviewed By: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D108
Issue is causes by vertex parent modifies original BMesh from
a multiple threads. Ideally this is to be done as a separate
update callback for mesh datablock, but it's not so much simple
now (would need to do some re-arranges to DAG which might conflict
with the work from Ali or will double amount of work we did).
So for now use simple solution with mutex lock.
Based on the patch from Campbell Barton with some fixes to make
changes really thread-safe.
Differential Revision: https://developer.blender.org/D168
