It doesn't make any sense anymore with the current depsgraph and probably was
not useful for a long time, just a leftover from the pre 2.04 game engine.
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
Summary:
Issue was caused by access to pchan->custom object from channel free
function when freeing all objects from main. Order of objects free
is not defined and such an access might easily end up with access
to freed memory.
We don't need to do user counter stuff when freeing main, so added
an _ex functions with do_id_user flag which is used when freeing main.
We had the same issue with other datablocks, so now it should be
easier to support relevant user counter.
This issue was caused by the fix for T36391, so perhaps that's indeed
high time to do real user counter.
Reviewers: brecht, campbellbarton
Reviewed By: campbellbarton
Maniphest Tasks: T37709
Differential Revision: https://developer.blender.org/D137
Levels of detail can be added and modified in the object panel. The object
panel also contains new tools for generating levels of detail, setting up
levels of detail based on object names (useful for importing), and
clearing an object's level of detail settings. This is meant as a game
engine feature, though the level of details settings can be previewed in
the viewport.
Reviewed By: moguri, nexyon, brecht
Differential Revision: http://developer.blender.org/D109
There were several issues with how bounding box and texture space
are calculated:
- This was done at the same time as applying modifiers, meaning if
several objects are sharing the same curve datablock, bounding
box and texture space will be calculated multiple times.
Further, allocating bounding box wasn't safe for threading.
- Bounding box and texture space were evaluated after pre-tessellation
modifiers are applied. This means Curve-level data is actually
depends on object data, and it's really bad because different
objects could have different modifiers and this leads to
conflicts (curve's data depends on object evaluation order)
and doesn't behave in a predictable way.
This commit moves bounding box and texture space evaluation from
modifier stack to own utility functions, just like it's was done
for meshes.
This makes curve objects update thread-safe, but gives some
limitations as well. Namely, with such approach it's not so
clear how to preserve the same behavior of texture space:
before this change texture space and bounding box would match
beveled curve as accurate as possible.
Old behavior was nice for quick texturing -- in most cases you
didn't need to modify texture space at all. But texture space
was depending on render/preview settings which could easily lead
to situations, when final result would be far different from
preview one.
Now we're using CV points coordinates and their radius to approximate
the bounding box. This doesn't give the same exact texture space,
but it helps a lot keeping texture space in a nice predictable way.
We could make approximation smarter in the future, but fir now
added operator to match texture space to fully tessellated curve
called "Match Texture Space".
Review link:
https://codereview.appspot.com/15410043/
Brief description:
http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2013/Results#Curve_Texture_Space
Patch by Martin Felke, many thanks.
When copying that modifier across objects, we also have to ensure that a skin CDLayer is present in dest objects (just as when adding it).
Otherwise some invalid pointers will be left
which could be harmless if real object stays
local, but crashes when linking them to
another files.
Was discovered here in the studio during
Project Pampa, and the steps to reproduce are:
- Create lib.blend, put armature and cube to it.
Create a group with them.
- Create scene.blend and link group from lib.blend.
- Make a proxy from armature.
- Make group real.
- Add real objects to a group.
- Create comp.blend and link group from scene.blend.
This step will creah.
curve children of a triangle vertex parent would only display their relationship line to the first vertex. (confusing)
also added OB_TYPE_SUPPORT_PARVERT macro.
previously this had to be done one by one.
both single and triagle vertex parents can be made, selected based on distance to the verts.
Developer notes:
- looks like this was old TODO, enums existed but weren't used.
- only meshes currently support using.
- added BKE_object_as_kdtree(), may come in handy for similar cases.
That ended up in tricky code trying to mimic depsgraph
branch behavior API-wise preserving texspace and bound
box calculation compatible with previous releases.
So for now bring cu->disp back to the trunk but keep
texpsace and boundbox APIs the same as in the branch.
This keeps texpsapce and boundbox behavior fully compatible
with previous releases and still makes API the same as
for meshes.
Object update used to free object-data level bounding box to trigger
it's re-calculation in the future. Such a freeing performed from
object update isn't thread-safe because mesh could be shared between
multiple objects.
Rather than freeing bounding box, tag it's as invalid, this is safe
from threading point of view and also prevents unnecessary memory
re-allocation.
Object-level bounding box is still reallocating, but think we could
change this easily in the future as well.
--
svn merge -r58154:58156 -r59258:59259 ^/branches/soc-2013-depsgraph_mt
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
Move static variables to context filling in by this fcuntion
and owned by a callee function. This ensures no conflicts
between threads happens because of static variables used in
this function.
Also moved modifier types and virtual modifiers data to a
function called from creator. This is needed to be sure all
the information is properly initialied to the time when
threads starts to use this data.
--
svn merge -r57899:57900 ^/branches/soc-2013-depsgraph_mt
- performance of outliner was low because of unoptimal data structures.
- now it uses BLI_mempool instead of custom mempool and GHash to make searches for duplicates faster.
- also fix undesired behaviour of BLI_mempool_as_arrayN
thanks to Campbell Barton and Lukas Tönne for helping me get a better fix put together.
This matrix was used to store the space the object is in,
which then was accessed by snapping code. No reason to
keep it as a global variable (which isn't safe for threading,
unlikely it'll give issues now, but it's easy to avoid
issues early here).
Now made it so BKE_object_where_is_calc_ex will get an
optional parameter originmat and set this matrix in
solve_parent.
Original patch by self, minor changes by Campbell, thanks!
On file save the mesh gets loads from the editmesh but the derived mesh caches
wer not cleared. This usually happens through the depsgraph but it needs to be
done manually here. Most changes are some refactoring to deduplicate derived
mesh freeing code.
Shapekey drivers were executed for every call to derivedmesh, which shouldn't happen.
It now only runs on the object_update() function, once for every depsgraph change.
Error was found while testing preview render in viewport. On each render, the
animsys sent a 'changed data' because of the shapekey drivers being called,
causing eternal re-render loops (without showing anything).
This functios are declared in BKE_paint.h header and using
SculptSession structure which is also declared there.
Anyway, does not make sense such a splitting of header and
implementation files, better be consistent here.
Made it so dynamic topology will flush changes from
SculptSession->bm to Object->me.
Used the same approach as sculptsession_bm_to_me does,
but instead of using DAG_id_tag_update used in-place
DerivedMesh release. Otherwise this lead to some
update issues resulting in missed object after render.
Also fixed multires modifier not being applied for
render when rendering from dyntopo sculpt mode.
P.S. Apparently sculpsession_bm_to_me was declared
in BKE_paint.h but implemented in object.c.
Rather confusing and better make it so this
functions are declared and implemented in
consistent files. But will solve this in a
separate commit.
of editmode on the child object.
Problem was that the object custom data mask was not taken into account when
rebuilding the derivedmesh in some cases, which is needed for the derivedmesh
to contain the mapping back to the original vertices. Now this data mask is
used for any derivedmesh build that will be cached.
Also problematic was that the datamask for the active object was applied to
all objects in the scene, which caused the parent object to be recalculated
when it didn't need to be. Now this datamask is only used for the active object.
This means main database is no longer pollutes with
temporary scene and objects needed for freestyle
render.
Actually, there're few of separated temporary mains
now. Ideally it's better to use single one, but it's
not so much trivial to pass it to all classes. Not
so big deal actually.
Required some changes to blender kernel, to make it
possible to add object to a given main, also to
check on mesh materials for objects in given main.
This is all straightforward changes.
As an additional, solved issue with main database
being infinitely polluted with text blocks created
by create_lineset_handler function.
This fixes:
- #35003: Freestyle crashes if user expands objects in FRS1_Scene
- #35012: ctrl+f12 rendering crashes when using Freestyle
