Z, Index, normal, UV and vector passes are only affected by surfaces with alpha
transparency equal to or higher than this threshold. With value 0.0 the first
surface hit will always write to these passes, regardless of transparency. With
higher values surfaces that are mostly transparent can be skipped until an opaque
surface is encountered.
This fixes the first case mentioned in the report. Has to do some ugly
DNA access to SpaceNode, unless we'd allow a bad level call there to do
it in ED_node ...
The second case has been fixed by @sergey in D274:
https://developer.blender.org/D274?vs=838&id=879#toc
So actually asan just did its job here, good to know!
As discussed in T38340 the solution is to use the current scene from
context whenever feasible.
Composite does not use node->id at all now, the scene which owns the
compositing node tree is retrieved from context instead.
Defocus node->id is made editable by the user. By default it is not set,
which also will make it use the contextual scene and camera info.
The node->id pointer in Defocus is **not** cleared in older blend files.
This is done for backward compatibility: the node will then behave as
before in untouched scenes.
File Output nodes also don't store scene in node->id. This is only needed
when creating a new node for initializing the file format.
Reviewers: brecht, jbakker, mdewanchand
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D290
This was storing the original object matrix, which builds on the
assumption that obmat is modified during dupli construction, which is a
bad hack.
Now the obmats are still modified, but this only happens outside of the
dupli system itself and the original ("omat") is stored as local
variables in the same place where the obmat manipulation takes place.
This is easier to follow and avoids hidden hacks as much as possible.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D254
It was an issue with early object update check which was
screwing up for second scene because of first one reset
ID recalc flags.
From the comment in the code about this:
We need to check all visible scenes, otherwise resetting
OB_ID changed flag will only work fine for first scene of
multiple visible and all the rest will skip update.
This could also lead to wrong behavior scene update handlers
because of missing ID datablock changed flags.
This is a bit of a bummer to allocate list here, but likely
it wouldn't become too much bad because it only happens when
objects were actually changed.
Issue was caused by some objects being in bMain and tagged
for update but not being in the DAG. This means objects
wouldn't be updated and their recalc flag remains untouched
triggering threaded for the next frame.
Solved by tweaking POST_UPDATE_HANDLER_WORKAROUND in the way
that it checks objects' recalc flags from the DAG, not from
the bMain. This will work a bit longer since DAG stored more
nodes than objects in the scene, but this code only runs in
cases when there're some objects tagged for update, which
keeps overall CPU usage on such a workaround pretty low.
Now CPU usage on 11a_comp scene from project Pampa went down
from ~15% down to ~5% (2,69 release uses ~%7).
Pointed by Thomas Dinges in IRC.
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
It was a missing fcurve evaluation in scene update function which lead to
materials only being updated on frame change.
Added the same exception as we've got for the scene animation. It only
runs when there're materials tagged for the update, so wouldn't expect
speed regressions or so.
Graph traversal which is based on counting parents which are still
to be updated fails in cases there are cycles in the graph.
If there are cyclic dependencies in the scene all the objects from
the cycles will be updated in a single thread now one by one. This
makes blender behave the same way as it was before multi-threaded
DAG landed to master.
This needed to tweak depsgraph a bit so now dag_check_cycle() sets
is_acyclic field of DAG forest if there are cycles in the graph.
TODO: It might be possible to save some time on evaluation when
all the tagged objects were updated in multi-threaded DAG
traversal.
This is a regression since threaded dependency graph landed to master.
Root of the issue goes to the loads of graph preparation being done
even if there's nothing to be updated.
The idea of this change is to use ID type recalc bits to determine
whether there're objects to be updated. Generally speaking, we now
check object and object data datablocks with DAG_id_type_tagged()
and if there's no such IDs tagged we skip the whole task pool creation
and so,
The only difficult aspect was that in some circumstances it was possible
that there are tagged objects but nothing in ID recalc bit fields.
There were several different circumstances when it was possible:
* When one assigns object->recalc flag directly DAG flush didn't
set corresponding bits to ID recalc bits. Partially it is fixed
by making it so flush will set bitfield, but also for object
types there's no reason to assign recalc flag directly. Using
generic DAG_id_type_tag works almost the same fast as direct
assignment, ensures all the bitflags are set properly and for the
long run it seems it's what we would actually want to.
* DAG_on_visible_update() didn't set recalc bits at all.
* Some areas were checking for object->recalc != 0, however it is was
possible that object recalc flag contains PSYS_RECALC_CHILD which
was never cleaned from there.
No idea why would we need to assign such a flag when enabling
scene simplification, this is to be investigated separately.
* It is possible that scene_update_post and frame_update_post handlers
will modify objects. The issue is that DAG_ids_clear_recalc is called
just after callbacks, which leaves objects with recalc flags but no
corresponding bit in ID recalc bitfield. This leads to some kind of
regression when using ID type tag fields to check whether there objects
to be updated internally comparing threaded DAG with legacy one.
For now let's have a workaround which will preserve tag for ID_OB
if there're objects with OB_RECALC_ALL bits. This keeps behavior
unchanged comparing with 2.69 release.
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
- Made tooltip for compression a bit more clear.
- Use default compression of 15%. Gives around
two times boost on export movie file here in
test with only 10% increased file size.
Reviewers: Jonathan Williamson
* Remove "Edge" post processing effect and the corresponding render layer.
Since we have freestyle, this is not needed anymore and was a very simple effect anyway (Zbuffer filter effect, could be added to the compositor if really needed again).
Reviewed By: brecht, ton
Differential Revision: http://developer.blender.org/D14
confusion, grid snap is now the default as it seems to be the most wanted and easy to use mode.
Absolute grid snapping happens in a somewhat generic function 'applyGridAbsolute', which could also be used for objects and other transforms later on. It is conceptually similar to the 'project' snapping
option, in that it calculates a delta vector for each element on top of the overall transform, which places each node on the grid.
Node transform now uses the top-left node corner for TransformData->loc. The transform center is still the average of node centers, so that scaling and rotation works nicely.
snapGrid*** functions have been renamed to snapGridIncrement*** to distinguish better between incremental and absolute grid snapping.
The issue was caused by uncertainty of current camera when
there're no markers to the left of current frame.
Now in this case camera from the top-left marker will be used.
forgetting to change it from RGB when painting images or saving renders.
This makes more sense in the new alpha pipeline, renders no longer contain an
alpha channel that does not match the RGB channels, so saving files as RGBA
should give the expected results when opening them in other applications.
This was in fact really nasty bug, caused by multitex_nodes
function using global variable R (which is a copy of current
renderer). this variable is not initialized to anything
meaningful for until first rendering (preview or final)
happened.
Since multitex_nodes might be used outside of render pipeline,
made it so whether CM is on or off as an argument to functions
multitex_ext_safe and multitex_ext. Now multitex_nodes() is
only shall be used for stuff happening from render pipeline!
Also needed to make some changes to other places, so all the
usages of texture sampling knows for the fact whether CM is
on or off.
And one more change is related on behavior of dispalcement,
wave, warp, weightvg modifiers and smoke. They'll be always
using CM off since texture is used for influence, not for
color.
It's rather bigger patch, but it's mostly straightforward
changes, which we really need to be done.
Reviewed by Brecht, thanks!
There's one thing we didn't foresee from the beginning,
which is apparently TLS is only available in OSX starting
from version 10.7, and we still do support of 10.6.
After recent Brecht's changes about locked viewport
while initializing BI render this TLS is not needed
in trunk anymore. So reverting this chunk of base
iteration to use static variable. But leaving all the
other static variables warped into context still, it
should help a bit in the future refactor.
Real fix would be to have some kind of graph context
evaluation structure which would be passing to update
routines (which will solve threaded mballs update) and
making depsgraph responsible for getting a motherball.
But this is all for GSoC project.
This time issue was caused by static variables used in
BKE_scene_base_iter_next function.
Change is not so much ultimate actually, but didn't
find more clear solution for now. So the changes are:
- Wrap almost all the static variables into own context-
like structure, which is owned by the callee function
and getting passed to the iteration function.
- Recursion detection wasn't possible with such approach,
so recursion detection still uses static in_next_object
variable, but which is now stored in thread local
storage (TLS, or thread variable if this names are more
clear for you).
This makes code thread-safe, but for sure final solution
shall be completely different. Ideally, dependency graph
shall be possible to answer on question "which object is
a motherball for this metaball". This will avoid iterating
via all the bases, objects and duplis just to get needed
motherball.
Further, metaball evaluation ideally will use the same
kind of depsgraph filtering, which will get result for
question like "which objects belongs to this group of
metaballs".
But this ideal things are to be solved in Joshua's and
mind GSoC projects.
Tested on linux (gcc and clang) and windows (msvc2008),
hopefully no compilation error will happen.
Thanks to Brecht for reviewing the change and getting
feedback for other possible ways we've dicussed!
- BKE_mask_update_scene was only used with do_newframe=FALSE,
removed this argument.
- Made it so BKE_mask_update_scene is able to handle LIB_ID_RECALC_DATA
case. Namely, if mask ID is tagged for data update it means shapekeys
will be re-evaluated (as if do_newframe=true).
If mask id only tagged for LIB_ID_RECALC, then no shapekey evaluation
happens (same as it used to behave before).
This means, doing DAG_id_tag_update(&mask->id, OB_RECALC_DATA) will
lead to shapekeys re-evaluation which is really needed in such
operators as clearing shapekeys (and cleaning shapekeys which is
in tomato branch yet).
This is a bit silly to use OB_RECALC_DATA sine mask is not an OB,
but could not see better way to do it now.
This fixes missing mask re-evaluation after clearing shapekey,
would expect no other functional changes.
were no properly updating when rendering animations.
The render engine was only updating the image user current frame on images used
by material textures. Now moved the function that updates all from the editors
to blenkernel level and do it on all frame changes.
Now copying a scene will also duplicate groups that consist entirely of objects
that are duplicated with the scene. The rigid body world will then also pointers
to these new groups.
