| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
|
|
Otherwise was impossible to have unfilled curves unless extrude was set
|
|
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
|
|
|
|
Summary:
Curve ORCO was not calculating properly for cyclic 2D curves.
- Needed to split vertices for blender internal renderer.
Otherwise it's not possible to map last face to a proper
texture location.
- Needed to tweak curve->mesh conversion to respect cyclic
flag along U direction.
- Removed check for orcodm in curve.c:add_orco_dm since
this code is only called if there're enabled constructive
modifiers on the curve.
Reviewers: brecht
Maniphest Tasks: T37225
Differential Revision: http://developer.blender.org/D45
|
|
a new one for every fill.
now use BLI_memarena and support passing the arena into the fill function, so the arena is re-used, when scanfill is called in a loop.
|
|
takes a key as an arg and isnt popping any element from the hash as you might expect).
add BLI_pophead/tail, since getting the first element from a list and removing it is a common task.
|
|
Otherwise changing font settings wouldn't apply instantly.
|
|
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.
|
|
It's a bit dumb to store render-time bevel list in
object's curve_cache, but that's how blender already
used to work for ages.
Proper fix is suspended for tomorrow :)
|
|
G.is_rendering
|
|
No need in special hacks for this now :)
|
|
Now modifier stack wouldn't modify original curve's nurbs
and will operate on a copy of nurbs.
This makes it possible to process curve object update with
shared curve datablocks from multiple threads. There's no
big overhead for creating a copy of nurbs comparing to old
behavior which was allocating original vertex array and
apply coordinates on curve after all modifier are applied.
The only remained issue with curves is curve's bounding box
and texture space. It's not thread-safe, but it wouldn't
lead to crashes -- it just could lead to either memory
leak or wrong texture coordinates due to difference in
modifiers stacks of objects which shares the same curve.
--
svn merge -r57959:57961 ^/branches/soc-2013-depsgraph_mt
|
|
So far it was harmless, but with upcoming changes having this
argument could be confusing from logic point of view
--
svn merge -r57958:57959 ^/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
|
|
This display list was only used for texture space calculation,
and even there this display list was only used for bounding
box calculation.
Since we already do have bounding box in a curve datablock
there's no reason to duplicate non-modified display list
just to calculate bounding box later, let's just calculate
bounding box at the first point.
This makes code a little be more thread-safe but curves are
still not safe for threads at all because of bevel list and
path. That would be solved later.
--
svn merge -r57939:57940 ^/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
|
|
Issue was caused by svn rev57566 which didn't take into
account the fact that curves could have dm of type CCGDM
and in this case CDDM_calc_normals_mapping_ex would fail
dramatically.
Added a check around normals update call bout whether
DM is CDDM or not. The same happens in mesh's modifier
stack.
|
|
|
|
caused by recent changes in normal calculation, however curves were not being very smart about calculating modifiers (calling unneeded re-tessellation for every modifier)
|
|
remove MEM_sys_types.h which was a duplicate.
|
|
material texture
|
|
A previous bugfix disabled the dynamic paint modifier for orco texture
coordinate evaluation of the modifier stack. However the MOD_APPLY_USECACHE
flag is not a good way to check if the modifier is evaluated for orcos.
Instead I've added a MOD_APPLY_ORCO flag. Also removed a bunch of
applyModifierEM callbacks, none of them served a purpose except for the
subsurf modifier.
|
|
tweaks.
|
|
previous commit was incorrect, the face flipping depended on the orientation of the curve.
fix by passing the bevel direction to the fill function so we can have a reliable front/back.
This also gives some speedup for all curve filling since we can avoid calculating the normal since its already known.
|
|
- (again)
also replace array copying with memcpy.
|
|
- Skip filling caps if spline is cyclic
- Use hard limit of 1024 for curve resolution
|
|
modifiers with text/curve/surface objects.
This is because the code here did not yet support the distinction between
generating the tesselated mesh at viewport/render resolution and generating a
separate displist/derivedmesh for render that is not stored in the object but
created and freed on the fly.
|
|
Simply extra normals flip happened.
|
|
also rename mesh_getVertexCos() --> BKE_mesh_vertexCos_get() to match curve function.
|
|
functions.
|
|
|
|
|
|
Issue was caused by storing BB calculated from final displist in
Curve datablock and not having Object's BB at all. This is not
clear at how could have been worked for so long.
Changed it so Curve's BB is calculated from non-deformed displist,
which matches BKE_object_min_max and BKE_curve_texspace_calc and
made it so Object's BB would be calculated from final displist.
|
|
Old fixes, since 2009 and before! Related to Curve object editmode:
- normals are not being drawn for hidden curves anymore
- even worse: Blender also didn't hide the extrusions or bevels for hidden curves
- outside edit mode, it shows all (as for all other modes)
- (de)select-all now works when 1st (or any) handle was hidden.
|
|
render engines). Replaced generating orco_index by filling the UV loop data
directly which is easier and all that needed to be done anyway.
|
|
|
|
|
|
speedup for BMesh ngons which never have holes and ensures predictable triangle count (totvert - 2), which is needed for pre-calculating array size.
|
|
from users who model for realtime/game-engine output,
the total number of faces wasn't so useful and could be especially misleading with ngons.
|
|
scanfill remove-doubles pass assumes ordered edges (as with curves), otherwise it can hang.
workaround this problem by skipping removing-doubles for mesh ngons, since this isnt such a common case as it is with curves and we can just not support it.
|
|
actually beveled part of curve (previously affect of taper would have
been clamped by start/end bevel factor)
Here's an illustration:
http://wiki.blender.org/uploads/5/5d/Blender2.65_CurveMapTaper.png
|
|
- minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
|
|
|
|
|
|
ideally these would be used as generated coordinates, but this is tricly because cycles calculates its own orco's and doesnt know about curve settings.
|
|
Refactored code a bit to make naming a bit more clear and added a
function to create mesh from given display list rather than from
object's displist.
Tested using plain curves (which doesn't imply using derived meshes)
and curves with constructive modifiers (which are using derived meshed).
|
|
use where possible.
|
