| Age | Commit message (Collapse) | Author |
|---|
|
|
|
We had too many warnings lately... was awaiting that someone would kill them - didn't happen -> goes to my commit ratio! :P
|
|
|
|
|
|
'Resolution' and 'end' was not.
Trivial, we need totla_length in that case too.
Safe to be backported to 2.74.
|
|
also remove unused includes
|
|
|
|
This is an old option which wasn't working in over a year without complaint.
|
|
|
|
Vertex parent was using original non-modified nurbs list, simply because
it didn't have something else to operate with.
Now we've got deformed by pre-tessellation modifiers nurbs in the curve
cache which might be used y the vertex parent.
|
|
|
|
curve factor.
Root of the issue goes to the fact that bevel list calculation might drop some points
if they're at the same position. This made spline length calculation goes wrong.
Now the length of the bevel segments is stored in the bevel list, so values are
always reliable.
Initial patch by Lukas Treyer with some tweaks from me.
|
|
|
|
|
|
mballs, will never be used anyway!
|
|
|
|
also remove redundant check
|
|
Sorry, forgot to check other uses of BKE_nurb_makeCurve, NURBS surfaces were affected as well.
|
|
Error in rB4b4bb410e04e, BKE_nurb_makeCurve() requires its coord_array to be zero'ed,
hence we need calloc here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Initial patch by Lukas Treyer with own fixes added
|
|
|
|
buggy)
|
|
|
|
|
|
Patch from Lukas Treyer
|
|
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
|
|
|
|
was a (minor) bug).
|
|
|
|
Bevel Factor Mapping allows to control the relation between bevel factors
(number between 0 and 1) and the rendered start and end point of a beveled
spline.
There are three options: "Resolution", "Segments", "Spline". "Resolution"
option maps bevel factors as it was done < 2.71, "Spline" and "Segments"
are new.
* "Resolution“: Map the bevel factor to the number of subdivisions of a
spline (U resolution).
* "Segments“: Map the bevel factor to the length of a segment and to the
number of subdivisions of a segment.
* "Spline": Map the bevel factor to the length of a spline.
Reviewers: yakca, sergey, campbellbarton
CC: sanne
Differential Revision: https://developer.blender.org/D294
|
|
|
|
|
|
|
|
Issue was caused by curve orco calculation for rendering being freed
curve path and not calculating it back.
This left depsgraph in a state that it believed all the object data
is up to date but in fact some parts of data was freed by convert
blender.
Now made it so path is not being freed by render thread. This is
rather a workaround actually because ideally render thread need
to use copy-on-write here or at least use local cache here. But
current logic should be closer to what was happening in previous
release.
|
|
|
|
|
|
|
|
|
|
Support for tagging polygon numbers when adding scanfill data,
saves having to calculate connectivity afterwards (which can take approx half overall scanfill time for complex curves).
|
|
This solves threading conflict which happens when having
multiple objects using Curve Deform modifier with the same
curve datablock. This conflict was caused by the fact that
curve_deform_verts() used to temporary override curve's
flags to make it path is there.
Actually, it was setting CU_FOLLOW flag temporary which
was only used where_on_path() (only in terms that this
temporary assignment only affected this function) but it
is now commented out for a while, so no reason to set
this flag temporary, If it's ever to be done, we'll need
to pass flags as an additional function argument.
For the path creation i've extended DegNode structure
which now holds extra bits which indicates what additional
data depending on the graph topology is to be evaluated.
Currently this is only used to indicate that curve needs
path to be evaluated regardless to cu->flag state. This
is so Curve Deform modifier is always happy.
In the future this flag might also be used to indicate
whether bmesh verts are to update (see recent commit to
3-vertex parent crash fix) or to indicate that the object
is the motherball etc.
|
|
This goes back to ancient era again and such a call isn't
safe for threading and really DAG is to make it sure display
list for dependencies is always there.
|
