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 :)
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)
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.
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.
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.
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.
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.
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).
Need to also check for cu->editfont for text edit mode...
Also use modifier_isEnabled() to make general tests whether a modifier should be applied or skipped.
